- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I designed a cordic block that has a fmax of 200 Mhz and I have a 18 bits counter that provides the angle for cordic block, this counter has a fmax of 210 Mhz. Here I don't have problems, but when I connect both the fmax is 40 Mhz and I need 150 Mhz !!!!
Do you have an idea to improve the fmax? Is it necessary to rebuild the blocks? Thanks.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I understand correctly, your system Fmax is now 200MHz, i.e. the slowest path in your system. (Your cordic probably has some paths that run much faster than 200MHz, but timing analysis is based on the slowest path, no matter how many paths there are.)
Also, if you're analyzing these two separately, don't just assume hooking them up will give the same results. Expect a little degradation as you fill up the device. (Or a lot, depending on how cautious you want to be, how much you plan on filling it up, and "how" your design fills up...)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
uhhmmmm...
fmax of cordic block = 200Mhz fmax of 18 bits counter = 210Mhz cordic + counter = 40 Mhz (when they are connected) and I need 150Mhz !!!! <--- This is the problem- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
:)
40MHz? From your analysis, is your failing path setup, hold, recovery or removal(I'll assume setup since you talk about Fmax, but Fmax is a limited term when it comes to static timing analysis.) That is based on the worst case path in your design. When you did an analysis of this path, were your launch and latch clocks the same? What's the setup requirement? What was the clock skew? What was the datapath, and if it's 25ns, how many levels of logic? What device and speed grade? If you provide that info, we might be able to diagnose the problem, or at least have enough info to ask more questions, but the information so far is too limited to really provide an answer.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jose. As Rysc is trying to indicate, you need to provide more information about the design. Did you synthesize and fit each of the blocks seperately to get the fmax results you're indicating? Where are you getting your numbers from?
Again, as Rysc has indicated, the overall fmax of the system depends not only on the fmax of the slowest block but how the blocks are connected together. What you need to do is focus on the combined system rather than the individual blocks. Look at the top failing paths for the system to determine what is failing. Why they are failing will probably be immediately obvious. Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try adding pipelining registers between the combinational blocks of the cordic processor. if you did not use them.
You should register all the inputs and outputs.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jose
I assume you run separate projects for your Counter and Cordic ? With the timing "Fmax" you only get the paths between the registers, but your designs has also paths from input pins to registers (tsu) and paths from register to output pins (tco). When you analyze your projects you have to keep in mind that some outputs will be connected to inputs of the other project. These pahts needs to be checked also.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, thanks to all......
I'm beginner, really I never think it all this parameters that you say, now I'm learning with your comments about the cautions with connection between blocks, paths, etc. The fmax is a data from Quartus II timing Analyser. Can you say me general "techniques" or "tricks" to improve the operation frequency or texts to red about it ? Thanks for your help.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you're using the Classic Timing Analyzer, go to the failing setup panel, right-click on the worst case path and do List Paths. The path details will be broken out below. Cut and paste this into a text file and then attach it. That will provide a lot more information we can help with. There are probably a hundred tips and tricks, if not more, most of which won't apply. Being able to analyze a single path and use that as a starting point toward the root cause is an invaluable skill.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you do a right-click on the first path and then a List Path. The path details will be broken out below(you can open and close them with the +/- buttons on the left). Then cut and paste all the information into a text file. This is just summary information and doesn't provide enough detail. (Although my original assumptions seem wrong, as I was expecting a clock path issue. You may have a really long datapath, although I can't know for sure without the details.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OKay. The counter is naturally no problem, as it's output is a register. Coming into the cordic(U2), there is a path that is 40 levels of logic. I think the only thing that will fix this is pipelining, i.e. adding registers along this path, which will increase your latency. Going down the path, you go through several hierarchies, u0, u1, u2, u4 and u6, so probably the most logical thing to do is add registers between these hierarchies. (If this is just dataflow, it's pretty straightforward. If any of these blocks loopback into the datapath, it gets much more complicated as you need to balance pipelining so all data lines up.)
The reason this never showed up in an Fmax report is that when compiled by itself, it came from an input pin and so wasn't analyzed as part of Fmax(which is generally considered register to register, and part of the reason Fmax is a limited picture). For higher speed designs, and 150MHz is getting up there, you need to consciously pipeline throughout your code. Finally, and I almost fear bringing it up, if you go to Tools -> Advisors -> Timing Optimization Advisors, there are some suggestions to help you move the levers/settings in Quartus to get better results. Bottom line is I don't think any of them will help you get the improvements you need, and I worry about relying on these too much(I assume you're early in the design, so as you add more logic it becomes more and more difficult), but they could be useful AFTER you modify the code and get it much closer, if you need to tweak out some more. It depends on the critical path, though.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
according this line
Info: - Longest register to register delay is 23.123 ns There is a combinational block that must be Checked . Look for this block and optimize it. (adder?). Add pipelining registers to improve the performance.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As Rysc and I said, you must pipeline the cordic processor.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page