The Critical FPGA Basics: Always blocks, Inferred latches, and why the FPGA needs a clock, anyway?!

[@wolpumba4099]

*Summary* This video explains FPGA programming fundamentals, particularly for those with a software background, emphasizing that FPGAs describe circuits, not traditional programs. *Here are the key takeaways:* * *0:00** - Intro* * *0:38** - Always blocks:* * Have two main functions: defining signal behavior (logic) and registering the signal (clocking). * The clock in a synchronous always block helps create predictable timing and avoids signal propagation issues. * *8:27** - Clocks and Static Timing Analysis:* * FPGA signals have a propagation delay. Clocks create "safe zones" for signals to arrive and stabilize, enabling reliable signal processing. * Static timing analysis calculates these signal paths and timing to ensure stability. * *13:00** - Registers:* * Act like small memory units inside the FPGA, storing local copies of signals. * Used to manage signal propagation delays and provide predictable timing. * *16:00** - Synchronous vs. Asynchronous Logic:* * Synchronous: Uses a clock signal for predictable timing (always blocks with a clock). * Asynchronous: Doesn't use a clock, susceptible to signal timing issues (always blocks without a clock). * *18:40** - Inferred Latches & How to Avoid Them:* * Inferred latches are problematic, unintended memory elements caused by feedback loops in asynchronous logic. * They occur when: * A signal drives itself within an asynchronous always block. * Default cases or missing cases in case statements within asynchronous logic. * To avoid latches: * Use registers to introduce clocks in loopback paths. * Define all possible signal behavior conditions in asynchronous always blocks and case statements. * *27:05** - Summary* * *28:56** - Outro* The video concludes by emphasizing the importance of understanding these fundamentals for reliable and efficient FPGA design. i used gemini 1.5 pro

[@bigGuyubuntu]

Lovely video! you're the best when it comes to FPGAs! Can you make a video about Dynamic Function Exchange (Partial Reconfiguration) please?

[@10e999]

I didn't know about this new series ! As an embedded engineer (not fpga, more MCU, MPU) they get me a feel for the field! Thanks Stacey

[@aakarshithasuresh3096]

Loved this video stacey! Your way of looking at systemverilog and why we use certain constructs in certain way, is amazing, easy to understand and remember too. Thanks a ton....😇

[@heliumlabs]

Thanks Stacy! That is an extremely valuable, amazing, simplified yet explanatory video. Thanks so much for your time making these videos. Please keep them coming. I know these vids are'nt the best return of your valuable time so if you need assistance to offload some work, please let us know and we can contribute what we can to keep them coming. Have a blessed day

[@FPGAsforBeginners]

You are so welcome!

[@FPGAsforBeginners]

You are so welcome!

[@cccmmm1234]

Better than 99% of textbooks!

[@Arjun_Choudahry]

Absolutely great explanation👏👏

[@danielmagnus5239]

More like this! Thanks :-)

[@TahaAlars]

Missed your Videos a looooooot 🤗

[@ksbs2829]

Yay! Welcome back Stacy! ❤️

[@jaoblx6009]

Finallyyyyy!! I am happy to see you again here! Can you please do a video about PCIe with ultrascale+

[@KasenB100]

Your videos are awesome!

[@younessmaarouf5162]

Salam Stacey, welcome back!

[@leongsengcheong4194]

Thank you for posting a new video!!

[@Samedhi1]

Thank you, this really helps.

[@temptemp7037]

This is so much needed

[@anonymouscommentator]

loved the video, thank you very much 😊

[@emraldoddball1005]

Thanks for the video much needed!!

[@Jonathan-ru9zl]

You backk!

[@kortaffel]

Greetings mysterious woman. Long time no see!~ Welcome back

[@rainasajid8470]

subscribed! thank you!

[@hjvanderlinden]

Bedankt

[@saturdaysequalsyouth]

Please make more videos

[@stevenh7729]

Thank you for your videos, which have been of great benefit to me (a master's student trying to learn FPGA and ASIC on my own). I would like to ask if I want to learn FPGA as a career choice. Do I need to learn ASIC-related subjects in advance as a foundation? (Such as understanding the underlying principles of pll and so on)

[@cccmmm1234]

Hi I will give a reply.... It always does help to understand what is going on under the hood, at least how it behaves, but unless you are designing the actual chip foundry processes you don't need a deep knowledge. I studied Computer science and programming in the age of Cobol, but I now mainly work in FPGA design. All self taught.

[@stevenh7729]

Thank you for your valuable advice. I am also a computer science graduate. Although I have experience in writing RTL (which is also a necessary ability for my research), the lack of EE electronic circuit related makes me confused about some nouns when reading many FPGA/ASIC tool documents such as pll / mmcm / ir-drop/ di/dt noise... etc. I would like to ask you what necessary subjects you have learned through self-study to enhance this knowledge?

[@cccmmm1234]

@@stevenh7729 I also have s9me experience with electronics which helps, but mainly just lots of experiments. Also consider doing some online courses.

[@vijay_4946]

1.When you have separated the original state_counter logic from the always block you said those are functionally equal .But this is not always correct .The key thing is you should not use reset signal for the combinational circuits .It will cause metastable issues during reset de-assertion case .It is also not a good coding practice. 2.There are three kinds of circuits in digital design combinational ,synchronous sequential and asynchronous sequential. once you have changed state_counter in the assign statement to state_counter_new, the assign statement logic circuit is no more asynchronous and it becomes combinational 3.The second image at 19:30 is not clear. You should have used arrow for the feedback path and reverse the latch element connections

[@FPGAsforBeginners]

Thanks vijay, I appreciate the feedback. This is a pretty complex topic and it was difficult to know how much to simplify. I realised after making the video that I probably should have called the state counter assignment combinational instead of asynchronus. It has always just been async/sync in my head. One of the reasons why I started making these videos is to improve my own skills and learn through explaining the concepts. I still have a lot to learn myself! I also realised i have the loopback FF backwards. Oh well! Im sure everyone knows what i mean :)

[@iluk9038]

@@FPGAsforBeginners I appreciate efforts you made to explain concepts with simplified way. Keep going Nancy!

[@cccmmm1234]

Great to see another one. If you are going to use a system Verilog types is there a reason you don't also use always_ff?

[@cccmmm1234]

Thanks for the clarification.

[@FPGAsforBeginners]

I do for the new code I write, there's usually a mix just because some of it is old verilog code I've adapted. I do prefer always_comb over always @(*) for my combinational always blocks because it's a lot more clear that it's intended to be combinational.

[@davidcache]

💪🏽💪🏽

[@olaoluwaraji2335]

Great video. Which software or tool did you use to draw your logic and timing diagrams? Thanks

[@FPGAsforBeginners]

Thanks! I used draw.io and wavedrom.com

[@bju295]

Hi... Can you made video on some algo implementation on vivado

[@cccmmm1234]

She has made many already. Have a look at her channel videos.

[@bju295]

@@cccmmm1234 can you send share link. I am interested in cryptographic algorithm.

[@bju295]

Share the link ​@@cccmmm1234

[@ivangecov2008]

Have you ever thought about being an analog engineer ? At some point is it boring being a digital designer/verificatio engineer ? You are doing the same thing over and over again ?

[@FPGAsforBeginners]

I've never found it to be boring, there is so much versatility in the field and I'm always being challenged and learning. I still find it to be a lot of fun.

[@chefjeff415]

No way digital would ever be boring haha. Think about a arbitrary wave form generator. That is easily achievable with a digital design and it may be more practical in some cases such as the RF domain where you need to modulate/demodulate quickly and process all that data (i.e. a radar board). DSP has so many more use cases I don’t not see how you can say “same thing over and over” haha