That is absolutely spot on. Perfect, short, crisp just like all your content. Thank you so much for all this content and keep this up, always looking forward to your content. All the best and thanks.
Just leaving a comment for extra oganic traffic under the video and to express gratitude. Thank you for this video, addressing the issue straightforward in beginner-friendly manner. Quality content!
I would have never thought that such a simple math problem would have caused that kind of trouble. The fix was easy and intuitive, when you think about it. I guess that is the thing though, you have to figure that out first. Thanks for the help. Nice to see some new content.
I recently did my first ever FPGA project targeting Kintex 7 where I of course encountered timing errors. In my case it started failing when trying to do 34-bit division @ 100 MHz. After seeing this wonderful video, I'm very surprised that I almost got away with comparatively much more complex operation. Was not aware that there's such difference between FPGA hardware! Maybe it came down to something else? Just for reference: I later learned about how expensive division is and reworked my code using different approach in combination with fixed point math where you multiply with "fractions" to divide.
This is a fantastic video. Thanks so much for putting this up. Simple concept, but immediately helped me work on timing closure of my complex design, which I was struggling with.
Just brilliant! You explained it in a very simplistic manner and that's what really needed. Thank you so much. Hope you also explain adding different timing constraints to the SDC file. :-)
thank you very much, I'm in the middle of my bachelor tesis programming an FPGA. I haven't met the timing contraints too serious yet, but I'm sure the time for it will come soon
@@messiweltmeista Yes lol, I have a big combinatorial circuit that perform encryption. But I think I will parallelize it now to make the critical path shorter. Where are you from and what do you study?
Very often you can do a much cruder version of pipelining. Just add a pipeline stage which does not do anything at all. The synthesis tool can see that the in-between data is not used and will move around the logic to get faster timing. No thinking required.
Thanks so much for this video. I've got an FPGA design I've built and have been selling to friends (basically for cost), and I've struggled with timing stuff because I didn't really understand how to set up the constraints file, or how to fix timing errors. My design has 3 clock domains and video lines for input. I could get it working on the bench, but then when it was in the field I'd get weird reports of the video flaking out. Eventually through trial and error I basically *accidentally* fixed most of it with pipelining (though I didn't understand why that fixed it). Now I have a better theoretical understanding. Is the syntax for the constraints file the same for all synthesis/dev tools? I use Quartus on my Cyclone IV board (when I'm not working on the Go board of course), and I've gotten really confused on the syntax for the SDA file. I did discover that there were some "derive" commands that I didn't really understand, but they cleared up a number of timing errors. Anyway, thanks for your videos. They are much appreciated. For whatever reason this kind of training (basic context setting stuff) is very difficult to find elsewhere. Everything wants to throw you into the deep end of the pool before you even understand what swimming is.
Thanks for the video, but I really hope you follow up with an example of the crossing clock domain timing errors you teased at the beginning. I have that problem, with a 60 and 50 MHz clock trying to pull from the same dp ram.
@@Nandland Thanks. I saw that video, and it's great. But there's a problem specific to timing analysis and clock domains I think, especially if the two frequencies are similar. Would the timing tools not give timing errors if you use stretching and the other techniques you use in that video?
I did and FPGA design on a xc7a100tcsg324-1 and got it to successfully pass timing in Vivado, then I took this same Vivado project and reassigned the chip to a xc7a100tftg256-1 and my design does not pass timing...... Why would cause this?
Hi Russell, My Go Board timing analysis has a "Target Frequency(MHZ)" of 111.36 - but the board should be 25MHZ. Do you know where I can change this in IceCube2? Thanks
Sounds like you need to add a .SDC file. Synthesis design constraint. ICEcube is a bit different, the clock gets set in the synthesis constraint file. Most other tools suggest doing it in the P&R constraint file.
This example is pretty bad because dividing by 3 takes 10x more LUTs than addition and multiplication by 5 (two additions only). So you don't gain anything particularly by splitting addition and multiplication by 5, you only waste FFs.
Glad to see a new video! I’ve been playing around the go board, and it’s a great dev board for a hobbyist like me!
That is absolutely spot on. Perfect, short, crisp just like all your content. Thank you so much for all this content and keep this up, always looking forward to your content. All the best and thanks.
Was worried because it's been 6 months since your last video. Good to see new video!
Just leaving a comment for extra oganic traffic under the video and to express gratitude. Thank you for this video, addressing the issue straightforward in beginner-friendly manner. Quality content!
Thanks for the video. It is always helpful to be able to glean insight from experience.
I would have never thought that such a simple math problem would have caused that kind of trouble. The fix was easy and intuitive, when you think about it. I guess that is the thing though, you have to figure that out first. Thanks for the help. Nice to see some new content.
I recently did my first ever FPGA project targeting Kintex 7 where I of course encountered timing errors. In my case it started failing when trying to do 34-bit division @ 100 MHz. After seeing this wonderful video, I'm very surprised that I almost got away with comparatively much more complex operation. Was not aware that there's such difference between FPGA hardware! Maybe it came down to something else?
Just for reference: I later learned about how expensive division is and reworked my code using different approach in combination with fixed point math where you multiply with "fractions" to divide.
Thanks for your video it really made me understand quickly the concept, much clearer than my course I followed during my studies!
This is a fantastic video. Thanks so much for putting this up. Simple concept, but immediately helped me work on timing closure of my complex design, which I was struggling with.
This problem really confused me for a long time! Very helpful video, thank you a lot !
Just brilliant! You explained it in a very simplistic manner and that's what really needed. Thank you so much. Hope you also explain adding different timing constraints to the SDC file. :-)
Thank you so much!!! Been looking for a video just like this one!
First comment.
Your explanations are easy to follow 👍👍
Bang on target. Great effort, practical demonstration. Truly appretiate it.
A good insight of Timing Analysis. Helpful!
Brilliantly explained !! I regularly learning from your videos.. Thanks.
Welcome back to TH-cam !
thank you very much, I'm in the middle of my bachelor tesis programming an FPGA. I haven't met the timing contraints too serious yet, but I'm sure the time for it will come soon
I am in the exact same situation. Working on my bachelor thesis, and trying to pipeline my design to reach 50 MHz.
@@ismailb4334 are you having issues already with 50Mhz?
@@messiweltmeista Yes lol, I have a big combinatorial circuit that perform encryption. But I think I will parallelize it now to make the critical path shorter.
Where are you from and what do you study?
@@ismailb4334 that's really interesting, yes parallelism always helps. I'm from Germany, currently studying electrical engineering
@@messiweltmeista Also Electrical Engineering here, in TU Delft, the Netherlands
this is the type of content i like, thanks
Excellent demo, love it.
Good to see you Russell
Very often you can do a much cruder version of pipelining. Just add a pipeline stage which does not do anything at all. The synthesis tool can see that the in-between data is not used and will move around the logic to get faster timing. No thinking required.
Kind of sad that you stopped making videos. Hope you are doing well!
Thanks so much for this video. I've got an FPGA design I've built and have been selling to friends (basically for cost), and I've struggled with timing stuff because I didn't really understand how to set up the constraints file, or how to fix timing errors. My design has 3 clock domains and video lines for input. I could get it working on the bench, but then when it was in the field I'd get weird reports of the video flaking out. Eventually through trial and error I basically *accidentally* fixed most of it with pipelining (though I didn't understand why that fixed it). Now I have a better theoretical understanding.
Is the syntax for the constraints file the same for all synthesis/dev tools? I use Quartus on my Cyclone IV board (when I'm not working on the Go board of course), and I've gotten really confused on the syntax for the SDA file. I did discover that there were some "derive" commands that I didn't really understand, but they cleared up a number of timing errors.
Anyway, thanks for your videos. They are much appreciated. For whatever reason this kind of training (basic context setting stuff) is very difficult to find elsewhere. Everything wants to throw you into the deep end of the pool before you even understand what swimming is.
Thanks a lot for the videos!
Thank you for another great video
Great video, thank you very much.
By the way, do you usually use the "`default_nettype =none" directive in your verilog/systemverilog designs?
Great video! Thanks very much
Thanks a lot man , I learned a lot from you 🖤🖤
Thanks for the video, but I really hope you follow up with an example of the crossing clock domain timing errors you teased at the beginning. I have that problem, with a 60 and 50 MHz clock trying to pull from the same dp ram.
th-cam.com/video/eyNU6mn_-7g/w-d-xo.html
@@Nandland Thanks. I saw that video, and it's great. But there's a problem specific to timing analysis and clock domains I think, especially if the two frequencies are similar. Would the timing tools not give timing errors if you use stretching and the other techniques you use in that video?
Do we always need to register the inputs ?
6:31 before it was using 34 FFlip flops now it is 39. So it did simplify the design?
What tool are you using to do the timing analysis?
I did and FPGA design on a xc7a100tcsg324-1 and got it to successfully pass timing in Vivado, then I took this same Vivado project and reassigned the chip to a xc7a100tftg256-1 and my design does not pass timing...... Why would cause this?
That the only way to slove this problem ?
How do you remove timing violation from a large register which is bitwise xored?
Example: reg [7196:0] data;
Always @(posedge clk)
Data_out
Why are you doing a 7000+ bit XOR? That's... large.
@@russellmerrick9761 it's a requirement of the algorithm.
Hi Russell,
My Go Board timing analysis has a "Target Frequency(MHZ)" of 111.36 - but the board should be 25MHZ.
Do you know where I can change this in IceCube2?
Thanks
Sounds like you need to add a .SDC file. Synthesis design constraint. ICEcube is a bit different, the clock gets set in the synthesis constraint file. Most other tools suggest doing it in the P&R constraint file.
Is there a way to place more pipeline stages between the LUT we get after synthesis?
You would have to break up the stages further. Here's one idea: shift left is the same as multiply by 2. Shift right one is the same as divide by 2.
This example is pretty bad because dividing by 3 takes 10x more LUTs than addition and multiplication by 5 (two additions only). So you don't gain anything particularly by splitting addition and multiplication by 5, you only waste FFs.