You may be interested in this video I made, it shows the pipeline diagram for this code, and also how I use _q to keep my signals straight: th-cam.com/video/sKQhUZ8dTjc/w-d-xo.html
@@FPGAsforBeginners I did see that video, though that wasn't quite what I was thinking about. However, you opted for the more DSP algorithm diagram which is probably a better method for this type of problem. I was thinking more of the traditional CPU pipeline diagrams which don't represent DSP algorithms quite as well. Also, funny enough, I do the inverse (but I have seen _q used more often). For me, non registered signals get _c. But your point about not mixing up the stage numbers and keeping them consistent was a great point to emphasize! Oh, and an alternative approach that I have found can be helpful in big pipelines, is to take advantage of the fact that verilog lets you define signals mid-file. So group each pipeline stage by a big comment block (to label the section), then have all of the signals, always blocks, assigns, and register blocks for that stage grouped under that section. That way you can scroll vertically through the file without jumping around to find the signal definitions or how the registers are assigned.
My understanding with Xilinx DSP48E1 or E2 is that they have at least 3 stages inside: add, multiply, and add again. Even if the adder features are not used, the signals still need to travel through those stages and incur all their delays. So what I do now is to write one additional pipeline registers after multiplications where DSPs will be inferred. If there are consecutive multiplications, add two stages between them and one after.
Another question about the clock cycles. Just curious why not to use a prescalear for this? Making a subclock (or pll) to squeeze into one circle and not to use more luts for temp registers? Maybe it’s obvious but i dont see it yet. Thanks.
Why use a valid signal when you could use a state machine? Does using a valid signal help parallelize the calculation? (I'm used to programming processors so I tend to want to use state machines for everything. haha)
The valid signal is just a tool to demonstrate when the signals become valid in the simulation. In this code it actually isn't necessary because all signals are valid all the time (after reset). In this video I go over this code in its final form, including the pipeline diagram: th-cam.com/video/sKQhUZ8dTjc/w-d-xo.html, which shows how the calculation is parallelised (or pipelined). I wouldn't use a state machine for this because usually a state machine remains in one state for several clock cycles, then switches to another. In this case I want all the calculations done all the time.
Channel is underrated. Great in depth video
really really good video. I can't stress that enough. I knew I had to pipeline my design but this explanation is beautiful. Thanks for sharing!
It also helps to draw pipeline diagrams / sequence diagrams to keep all of the delays straight (I always end up with a misalignment otherwise).
Totally! I'm planning on doing a proper pipelining video soon, diagrams and all!
You may be interested in this video I made, it shows the pipeline diagram for this code, and also how I use _q to keep my signals straight: th-cam.com/video/sKQhUZ8dTjc/w-d-xo.html
@@FPGAsforBeginners I did see that video, though that wasn't quite what I was thinking about. However, you opted for the more DSP algorithm diagram which is probably a better method for this type of problem.
I was thinking more of the traditional CPU pipeline diagrams which don't represent DSP algorithms quite as well.
Also, funny enough, I do the inverse (but I have seen _q used more often). For me, non registered signals get _c. But your point about not mixing up the stage numbers and keeping them consistent was a great point to emphasize! Oh, and an alternative approach that I have found can be helpful in big pipelines, is to take advantage of the fact that verilog lets you define signals mid-file. So group each pipeline stage by a big comment block (to label the section), then have all of the signals, always blocks, assigns, and register blocks for that stage grouped under that section. That way you can scroll vertically through the file without jumping around to find the signal definitions or how the registers are assigned.
Yay, the most important topic of all!
I Was just waiting..
As always concise
Thanks!!!
My understanding with Xilinx DSP48E1 or E2 is that they have at least 3 stages inside: add, multiply, and add again. Even if the adder features are not used, the signals still need to travel through those stages and incur all their delays. So what I do now is to write one additional pipeline registers after multiplications where DSPs will be inferred. If there are consecutive multiplications, add two stages between them and one after.
you are really really amazing , thank you sooo much, keep going
good video!
Another question about the clock cycles. Just curious why not to use a prescalear for this? Making a subclock (or pll) to squeeze into one circle and not to use more luts for temp registers? Maybe it’s obvious but i dont see it yet. Thanks.
Thank you for the helpful information. If the timing reports a negative blue number of the worst slack, is the design acceptable or not?
Why use a valid signal when you could use a state machine? Does using a valid signal help parallelize the calculation? (I'm used to programming processors so I tend to want to use state machines for everything. haha)
The valid signal is just a tool to demonstrate when the signals become valid in the simulation. In this code it actually isn't necessary because all signals are valid all the time (after reset). In this video I go over this code in its final form, including the pipeline diagram: th-cam.com/video/sKQhUZ8dTjc/w-d-xo.html, which shows how the calculation is parallelised (or pipelined).
I wouldn't use a state machine for this because usually a state machine remains in one state for several clock cycles, then switches to another. In this case I want all the calculations done all the time.