DVD - Lecture 2d: Verilog FSM Implementation

[@AdiTeman]

@3:00 there is a small mistake. The signal "ovflw" should be defined as a "wire" (explicitly or implicitly), since it is driven by an assign statement. Thanks to @vevasam for pointing this out!

[@banban8481]

I am a student from Indonesia, and we do not have this kind of course in any Indonesian university. Thank you very much for your lectures!

[@AdiTeman]

You are more than welcome!

[@spicypepper5391]

I'm really enjoying these videos and they are done quite well. Thank you for putting in the effort!

[@AdiTeman]

Glad you enjoy it!

[@vevasam]

@13:13 When I tried to run the testbench on iverilog, I got simulation error saying 'ovrflw cannot be driven by primitives or continuous assignment'. Stackoverflow said that a 'reg' type variable cannot be driven by a 'assign' continuous assignemnt. Instead it has to be done using a prodecural block. Hence I changed this assignment statement to procedural block as below. always @ (*) begin ovrflw = (state == OVFLW) ? 1'b1: 1'b0; end

[@AdiTeman]

Good catch! Yes, as I explained in Lec 2c at around 10:30 (kzbin.info/www/bejne/pHqbpXmGncpjq80), a reg can only be driven (LHS) from an always block and an assign can only drive a wire. I guess I changed a few things around in the presentation along the way and created this syntax error (it's not a bug per-se as it doesn't pass compilation and all you need is to change it to a wire...). In the updated lecture version I use in class, it is correctly defined as a wire (actually, just defined as an output without the "reg" keyword). Alternatively, you could - as you did - move it into an always block. Thanks for finding this error - I will add it to the "pinned" comments of the video.

[@vevasam]

@@AdiTeman Prof. Teman, thank you so much for the clarification. I sincerely appreciate your time and effort in answering the questions with such details. I am basically from embedded software background and we got a need to synthesize our logic on an FPGA due to custom requirements from our project. As per the project toolchain dictation, I am using model based approach ( Xilinx System Generator toolbox in Matlab/Simulink) to synthesize our logic on the board. In order to clearly understand the underlying internals of logic sysnthesis I started to look for extra material online and I must say FPGA and ASIC world is incredibly interesting and fulfilling. Many things that were under the hood for a software guy, are slowly getting transparent. Coming to your lectures they are amazing and a treasure. Someone mentioned them in Mastodon and I am so glad that I came here. I really loved the way you explained FSM, especially the framework that you have laid to approach designing an FSM. Keeping the combinatorial part for state transitions and sequential part for state register. This clear disctinction makes the design easy to follow and to implement. Thank you once again for providing public access to your lectures. If you happen to hold the lectures online in the future, I would definitely like to participate. By the way I just simulated the design in iVerilog and saved the files here, just incase if any student want to try it out. Thank you. drive.google.com/drive/folders/1Ijr_HlH-41_MOiPY31ruab8-jckWBUdG?usp=sharing

[@AdiTeman]

@@vevasam So happy to hear. By the way, this "separation" is something I have a very hard time conveying to students who take my course, and especially if they have experience writing code for FPGAs. The FPGA toolchain is very "forgiving" and you can write "Bad RTL" with a result that "works" (or at least seems to). This is due to the fact that (a) many more people have access to FPGA design than ASIC design and the vendors want to make it easier to use and (b) if you make a mistake, you don't have to pay for another tapeout. That being said, the verification process of FPGA designers is often not done in a serious fashion and leaves a ton of bugs hanging. So these "experienced" designers think they are pros, but the minute they have to write ASIC-synthesizeable RTL - they are totally lost (and it's often hard to get rid of bad habits). I can tell you that the students in my course - every year in a very consistent fashion - refuse to follow the clearly set out instructions and find themselves having a design that doesn't synthesize, infers latches, or breaks at gate level. Methodology in ASIC design is critical!

[@vevasam]

@@AdiTeman I can't agree more. You exactly defined the position I am in. Due to lack to experience in the hardware side, I have written verilog HDL that worked. When I kept building on it the first thing I noticed was that I was not able to organize my design and follow along anymore. In fact what I had on paper could not be followed in HDL and I hated it myself. I guess people like me get saved in the software perhaps due to its sequential execution. I started to rewrite my modules in FSM as I find it very sensible approach to my requirement. Now my design kind of looks neat, bit easier to follow and professional. I hope I will continue building on this. Also I hope to keep the momentum and complete the course and learn good practices. Thanks again.

[@vevasam]

@15:48 Why do we have two 'initial' blocks in the test bench? Can't we club them into one? Does it serve any specific need? Thank you.

[@AdiTeman]

Yes, you could, indeed, combine them into one. I separate them to make a more clear and clean definition. The first is initialization - it clearly shows that each stimuli is initialized. The second shows the actual behavior after we already set their "reset" value. But this is not necessary.

[@vevasam]

A short question from the test bench @15:40. The delay time units specifed as #5, does it mean 5 time delay units from 0th timestamp and NOT from the previously defined time stamp?? Thank you.

[@AdiTeman]

Hi @vevasam The 5 time unit delay is inside an "always" block, so this is a recurrent process. In other words, every 5 time delays it will invert the clock, then wait 5 time delays and invert it again, and so on.

[@vevasam]

Its a very interesting story about Chip Hall of Fame at the end. @20:21 Its an incredibly beautiful picture of the 8088 die. Do you also have some suggestions about how to decap epoxy off the IC and expose the die? Did you directly take pictures from your microscope? I am now really interested to procure an 8088 (if at all it can still be procured) and see the Hebrew name of Mr. Rafi Retter. Someday :)

[@AdiTeman]

You don't know how happy I am to receive your comment. Along with my description of "Teman's Law" (See VLSI Lecture 5a at 14:50 kzbin.info/www/bejne/m5PFZZWEjNqgnLM), this is my favorite story to tell throughout my lectures. I was actually giving a ride to some of those original Intel Israel engineers on the way back from a small conference and they were discussing the early days and told me about Rafi's "signature". So I decided I had to put it in my lecture. I searched pictures of the 8088 I found on the web, but couldn't find the Hebrew writing. So the next time I saw Rafi, I asked him and he told me the picture was hanging on his wall and he would send me a photo of it. That's how I got this particular photo with the right focus to see the writing. Regarding decapping chips - that's not my expertise, but it's not a tough thing to do. I'm sure there are plenty of guides out there :)

[@vevasam]

@@AdiTeman The pleasure is completely mine. Thank you so much for sharing your story. And I am very much looking forward for the upcoming chapters in this lecture series. Have a nice day!

[@akpojotorprincewill4610]

Thank you for sharing this with us. @12:40 the ELSE IF within the ELSE structure of Counter Register has no ELSE ending the structure. Would this not be a problem since we need to have an ELSE for every IF?

[@AdiTeman]

No, this is not a problem, since this is a sequential always block. In other words, we WANT to infer a register. The problem with no else after an if is that we need to retain state (=memory). Since we are inferring a register, we are exactly retaining state. That being said, I wrote the RTL here a bit against my own methodology. I actually discuss this my "Harry Potter" video (kzbin.info/www/bejne/eHrUfZ5oaM14b5I). Specifically, see slide 14 at this 26:29 : kzbin.info/www/bejne/eHrUfZ5oaM14b5I?t=1586

[@venkateshiyer5073]

what a way to get your name in (at the end of the video), amazing info

[@AdiTeman]

And from personal acquaintance, I can tell you that Rafi is not only a great engineer, but also a great guy!

[@venkateshiyer5073]

@@AdiTeman i truly believe that sir

[@hiteshgehlot4232]

How it can be moore because in this it has 4 states while in moore there +1 states that would be 5

[@ahmadirtisam9593]

I have two questions: when is there a need for a finite state machine (FSM) in the design, and when is it unnecessary? Secondly, does a digital designer need to consider clocking while designing circuits? For example, when there are a certain number of registers in the design, how will they work together? On which clock tick will they provide the result, and on which tick will others be able to receive it? It creates a lot of confusion, and I find myself constantly pondering these matters while writing RTL codes. Unfortunately, it slows down my productivity

[@AdiTeman]

Hi Ahmad, To start with the second question - yes, I think that this is the primary consideration of an RTL designer. You are designing synchronous circuits that are carrying out operations according to a specific clock edge and so this is the major consideration you have to take into account. In fact, RTL is "register-transfer level" design, because you are exactly describing how flip flops pass signals to each other and in which clock cycle. That also basically answers the first question. It is either always or never necessary to build an FSM. What do I mean? I mean that an FSM is a representation that helps us understand what is supposed to happen during each and every clock cycle (every state of the synchronous circuit). Any time you are writing RTL, you are describing an FSM, since a synchronous system is just that - a circuit with state. However, you can often "do this in your head" without drawing all the signals and naming all the states. The FSM diagram is mainly a tool to visualize the synchronization and logic between the registers and help us write clean, bug free design. So I guess my recommendation is - if you can draw an FSM - do it. It will help you describe what you mean.

[@ahmadirtisam9593]

@@AdiTeman thanks for clearing it all. I find it very helpful :)

[@veliogut358]

could you share the codes in github?