This series impressively well-conceived and well executed. I have found many gems and overall find the series to be genuinely practical and directly useful. Many thanks.
Can I ask if possible you make this a longer series and delve into the more complex areas of FPGAs and digital design. Your tutorials are very well made and very informative and you explain things in a very easy to understand way.
Another great entry to this series! You should also have probably mentioned that many of the bigger vendors have built-in FIFO logic with their block RAMs (i.e. Intel and Xilinx). You're always better off using the built-in logic (unless there is a special need to not use it - such as reducing delay). The downside though, is that those FIFOs are not inferable and instead need to be instantiated via macro. Often the solution to make a design cross-platform is to wrap the FIFO implementation in a generic module, and include the relevant implementation for the given target (even across Xilinx chips for example, there is a different macro for the 6 series, 7 series, and Ultrascale series). FIFOs can also be used to pass generic control signals other than pure data. One method is to do delta-compression, where only bit-vector updates are pushed to the FIFO (so you encode the signal bit-vector with XOR when you push, and decode it with XOR when you pull. If you didn't do that and instead pushed every clock pulse, then you could easily overrun the FIFO). If you need bi-directional signals, you can use two FIFOs in either direction. One easy example where this is very useful, is VGA timings. If you have a VGA output driver (with variable clock and timing for different monitor resolutions), and a set frequency image generator (like a bitmap BLITer), you can use a FIFO to send synchronization signals such as "Start_of_frame", and "new_scanline", to keep the image generator in sync with a scanline buffer (that allows you to use a scanline buffer instead of a full frame-buffer). The only times I have ever used a synchronizer, where cases where the update can be fuzzy (i.e. glitching is acceptable). And doing so requires specialized timing constraints to prevent the P&R tool from complaining about timing violations (usually I use a false-path constraint, which will stochastically add delay to the synchronizer making it completely impractical for general clock domain crossing). Anyway, looking forward to the next episode!
I am so eager to run through this series myself starting from the beginning tutorial however I can't start without a board. Sorry if you have already addressed this a hundred times but I am guessing that until the chip shortage is over (in 3 years :)) we will just have to hang tight.
This is a big issue with high precision sensors, because you don't want sensor modulation frequencies to be harmonically synchronous with your demodulation system. So you have to decouple the two systems, and pass data between them asynchronously.
Using an asynchronous reset is also discouraged. You should only have a single process that converts your asynchronous reset to synchronous. The rest of your logic should run on the synchronous reset.
Good point, thanks! I've seen some chips that are fine with asynchronous reset, but I do agree that it makes more sense to use synchronous resets where possible.
This series impressively well-conceived and well executed. I have found many gems and overall find the series to be genuinely practical and directly useful. Many thanks.
Can I ask if possible you make this a longer series and delve into the more complex areas of FPGAs and digital design. Your tutorials are very well made and very informative and you explain things in a very easy to understand way.
really amazing. very clear presentation. everyone who is starting out should watch this. even people who know HDL should give it a watch. thank you.
I'm having problem related to clock rn, you came just in time Shawn!
Great stuff. Really covering all the important topics. Keep going.
Great video - nice work Shawn!
Another great entry to this series!
You should also have probably mentioned that many of the bigger vendors have built-in FIFO logic with their block RAMs (i.e. Intel and Xilinx). You're always better off using the built-in logic (unless there is a special need to not use it - such as reducing delay). The downside though, is that those FIFOs are not inferable and instead need to be instantiated via macro. Often the solution to make a design cross-platform is to wrap the FIFO implementation in a generic module, and include the relevant implementation for the given target (even across Xilinx chips for example, there is a different macro for the 6 series, 7 series, and Ultrascale series).
FIFOs can also be used to pass generic control signals other than pure data. One method is to do delta-compression, where only bit-vector updates are pushed to the FIFO (so you encode the signal bit-vector with XOR when you push, and decode it with XOR when you pull. If you didn't do that and instead pushed every clock pulse, then you could easily overrun the FIFO). If you need bi-directional signals, you can use two FIFOs in either direction. One easy example where this is very useful, is VGA timings. If you have a VGA output driver (with variable clock and timing for different monitor resolutions), and a set frequency image generator (like a bitmap BLITer), you can use a FIFO to send synchronization signals such as "Start_of_frame", and "new_scanline", to keep the image generator in sync with a scanline buffer (that allows you to use a scanline buffer instead of a full frame-buffer).
The only times I have ever used a synchronizer, where cases where the update can be fuzzy (i.e. glitching is acceptable). And doing so requires specialized timing constraints to prevent the P&R tool from complaining about timing violations (usually I use a false-path constraint, which will stochastically add delay to the synchronizer making it completely impractical for general clock domain crossing).
Anyway, looking forward to the next episode!
I am so eager to run through this series myself starting from the beginning tutorial however I can't start without a board. Sorry if you have already addressed this a hundred times but I am guessing that until the chip shortage is over (in 3 years :)) we will just have to hang tight.
This is a big issue with high precision sensors, because you don't want sensor modulation frequencies to be harmonically synchronous with your demodulation system. So you have to decouple the two systems, and pass data between them asynchronously.
Thank you 👍
Using an asynchronous reset is also discouraged. You should only have a single process that converts your asynchronous reset to synchronous. The rest of your logic should run on the synchronous reset.
Good point, thanks! I've seen some chips that are fine with asynchronous reset, but I do agree that it makes more sense to use synchronous resets where possible.
@@ShawnHymel it helps most to assure that multiple circuits come out of reset at the same time.
❤
Everything good but you didn't explain how a synchronizer works. That's what I was searching for in the whole video but then it jumped to FIFO fsr.