Thanks so much, this is excellent!!!! In a class on architecture design right now, and my method of prepping for exams and stuff is following along with the examples we discuss by implementing them in verilog. New to verilog, and these FSM example techniques were super helpful!
Thank you for this video. I see some similarities between you and me in how we create state machines in Verilog. I hope to continue to learn more from you.
Thanks a lot for your videos. Would love to see a similar video on SPI. understanding timing diagrams, spi mode and translating them into verilog code? Verilog newbie here 🙆♀
I was beginning to think FPGAs were not for me because I don't like dry, droning, monotone, overly complicated videos from 15 years ago that never get to the point. Or reading completely aimless documentation that is at once barely scratching the surface in providing the semblance of a tutorial as well as technical details about every single board the developer has ever produced and every possible minutiae of how they differ from each other. In a word: thanks, this is greatly appreciated! This cup is on me.
Thanks you for the excellent video. If there was a rx done for this, is it necessary to do a cdc, or will it be covered by sampling in the 3rd cycle after 1st change?
Hi. Do you have any Skillz for dark arts, like doing self-modifying designs through ICAP etc. ? BTW, is asynchronous designs in FPGAs possible or does everything have to be synchronized to a clock in physical reality ? Also, is there such thing like real tri-state or bidirectional in in FPGA ?
Almost universally tools are dependant on the clock for timing analysis. It is very very difficult to do completely async design without a clock. I'm sure it's been done by someone but it would be extremely difficult to produce a functional firmware. The FPGA has bidirectional buffers on the I/O pins, so for eg, an I2C bus pin can be tristate, but there aren't any buffers apart from the pin buffers that would be tristate inside the FPGA. Once a signal is in the FPGA it is purely single directional and binary.
Hi All! A kind user on reddit (u/PiasaChimera) pointed out to me that it's possible to just drive next_state with current_state at the top of the async always block, so all the else statements aren't necessary. They also linked this really useful guide (www.sunburst-design.com/papers/CummingsSNUG2019SV_FSM1.pdf ). This will reduce the amount of space the async block takes up. This makes it even more clear than what I showed here. It just shows, no matter what your level, there is always something new to learn! Also! u/Firadin on Reddit pointed out that my sync always block at 7:18 that registers the next_state signal into current_state is a blocking (=)assign. This should be non-blocking (
@@fpga-all-day In an asynchronus always block (one with an asterisk), it's really important to make sure that all possible cases are covered, This may be by using a default case, or an else, or having a statement at the top of your block that acts as the default assignment. If it doesn't make sense to have one of these, then you probably should be looking at using a synchronus always block. If you don't cover all the cases explicitly, then basically that is describing memory: the circuit must *remember* what the signal value was before in order to maintain it for the next clock cycle (since it isn't explicitly described). The only option the tool has for this is to infer a latch in the async case, which is a hacky memory element inside the FPGA. I really should make a video on this. If you're worried about inferred latches in your design, search through the synthesis warnings for "inferred latch". That will point you to any you may have.
@@FPGAsforBeginners Thank you, it finally clicked for me. It makes sense that this is for asynchronous blocks because something always needs to happen. I appreciate it!
I am glad I found your channel by accident. You content is very good. I am an "old'" FPGA designer and the nerd in me appreciates these videos.
Great video! I learned a ton, I always threw everything in my state machines into a single synchronous block
Thanks! I also did the single synchronous block for years! I think it's pretty ubiquitous!
@@FPGAsforBeginners Do you think there might be more timing issues with multiple block than a single synchronous block?
Thanks so much, this is excellent!!!! In a class on architecture design right now, and my method of prepping for exams and stuff is following along with the examples we discuss by implementing them in verilog. New to verilog, and these FSM example techniques were super helpful!
Thank you for this video. I see some similarities between you and me in how we create state machines in Verilog. I hope to continue to learn more from you.
Thank very nice explanation and useful tips for FSM design!
😀
Verilog doesn't come easy to me, but this guide is very helpful! I come from Reddit, btw.
Thanks a lot for your videos. Would love to see a similar video on SPI. understanding timing diagrams, spi mode and translating them into verilog code? Verilog newbie here 🙆♀
Will add to my to-do list. Thanks!
Great and clear explanation. Thank you !
Glad it was helpful!
I was beginning to think FPGAs were not for me because I don't like dry, droning, monotone, overly complicated videos from 15 years ago that never get to the point.
Or reading completely aimless documentation that is at once barely scratching the surface in providing the semblance of a tutorial as well as technical details about every single board the developer has ever produced and every possible minutiae of how they differ from each other.
In a word: thanks, this is greatly appreciated! This cup is on me.
Thanks a lot from Italy
Thank you!
LOVE IT NEED MOAAAAR
Thanks you for the excellent video. If there was a rx done for this, is it necessary to do a cdc, or will it be covered by sampling in the 3rd cycle after 1st change?
wow great, it's very useful to understand. can you please explain the recevier part?
Do you ever include data path considerations in your FSM design? It is very good for low occupancy designs
Hi. Do you have any Skillz for dark arts, like doing self-modifying designs through ICAP etc. ?
BTW, is asynchronous designs in FPGAs possible or does everything have to be synchronized to a clock in physical reality ?
Also, is there such thing like real tri-state or bidirectional in in FPGA ?
Almost universally tools are dependant on the clock for timing analysis. It is very very difficult to do completely async design without a clock. I'm sure it's been done by someone but it would be extremely difficult to produce a functional firmware.
The FPGA has bidirectional buffers on the I/O pins, so for eg, an I2C bus pin can be tristate, but there aren't any buffers apart from the pin buffers that would be tristate inside the FPGA. Once a signal is in the FPGA it is purely single directional and binary.
I have a better tip. Forget Verilog and learn Vivado HLS.
Haha! This reminds me: I should do a video on the pros and cons of HLS vs RTL Design!
Hi All! A kind user on reddit (u/PiasaChimera) pointed out to me that it's possible to just drive next_state with current_state at the top of the async always block, so all the else statements aren't necessary. They also linked this really useful guide (www.sunburst-design.com/papers/CummingsSNUG2019SV_FSM1.pdf ). This will reduce the amount of space the async block takes up. This makes it even more clear than what I showed here. It just shows, no matter what your level, there is always something new to learn!
Also! u/Firadin on Reddit pointed out that my sync always block at 7:18 that registers the next_state signal into current_state is a blocking (=)assign. This should be non-blocking (
Is it considered bad code to leave out default cases and else statements? What should I do if it doesn't make sense to have one of these?
@@fpga-all-day In an asynchronus always block (one with an asterisk), it's really important to make sure that all possible cases are covered, This may be by using a default case, or an else, or having a statement at the top of your block that acts as the default assignment. If it doesn't make sense to have one of these, then you probably should be looking at using a synchronus always block. If you don't cover all the cases explicitly, then basically that is describing memory: the circuit must *remember* what the signal value was before in order to maintain it for the next clock cycle (since it isn't explicitly described). The only option the tool has for this is to infer a latch in the async case, which is a hacky memory element inside the FPGA. I really should make a video on this.
If you're worried about inferred latches in your design, search through the synthesis warnings for "inferred latch". That will point you to any you may have.
@@FPGAsforBeginners Thank you, it finally clicked for me. It makes sense that this is for asynchronous blocks because something always needs to happen. I appreciate it!