Honored ContributorHello,
I try to implement my design on a Stratix 3 260 and my goal is to reach a 200MHz clock after place and route steps quartus shows me the critical paths, actually all my paths are made of 80% of IC and the component is used near of 50% Do you have some advices to improve the routing results as the problem seems to be due to routing congestion ?? thanks
Honored ContributorNormally the best thing to do to improve FMax is to increase the pipelining in the design. For max speed, you want no more than a single LUT between 1 register and the next.
Honored ContributorI have already optimized my design by adding registers to break the critical path between to registers , as a result of that, after placement step in quartus a message say me that :
Info: Estimated most critical path is memory to register delay of 5.293 ns Info: Total cell delay = 2.658 ns ( 50.22 % ) Info: Total interconnect delay = 2.635 ns ( 49.78 % ) which is near of my goal of 5ns (200MHZ) , so for me it's good BUT ! after the routing step the critical path is near of 6.3 ns and is made of 20% cell delay and 80% IC delay .... how can I avoid this ? thanksHonored ContributorYou are targetting Fmax of 200MHz and for your device you should get it readily unless your chip is really full. You can try the seed value if you don't want any redesign headaches.
Your thoughts about most critical path are not clear. The breakup into cell delay and interconnect delay doesn't help much in localising the problem. It may not be localised in the first place as floating timing violation may occur when chip reaches its limit. I am not sure what you mean by (after routing...) I thought the timing analyser reports on issues after routing anyway.Honored Contributorfor kaz,
I don't understand => "You can try the seed value if you don't want any redesign headaches". "I am not sure what you mean by (after routing...)" => during the fitter there are two main steps : the mapping (place) and routing (route) , at the end of the first one quartus informs me that the critical path takes 5.2ns, and after the routing the critical path takes 6.3ns (mainly due of interconnect delay).Honored ContributorIdeally if your problem is localised to part of design then you need to tackle it there. If however you reached the limit of your chip and the violation is random then the seed can help.
When the fitter starts it uses a default random seed value. You can change this seed and it will have up to 10% effect on timing. It is somewhere in the fitter settings. You can also run several seeds overnight or weekend using the Design space explorer(DSE) edit: Don't forget life is always random(Darwin knew that first, I wonder if nature used some tool like DSE and how long will it take it to end up as a butterfly cell nucleus)Honored Contributorok ,
I will try this thanksHonored ContributorHonored ContributorRouting is very, very seldom the problem. That doesn't mean it's not a large part, but the placement is usually the culprit. For obvious reasons, a spread out placement will cause long routes. (And to be honest, a spread placement is usually caused by a spread design, i.e. something like a mux that might feed multiple components in a device).
Can you list the path details of placement and routing(from TimeQuest, do report_timing with the -file "file.txt" option), or make your own if using TAN. Also, right-click on the path in TimeQuest, Locate -> Chip Planner, and then click the Expand button to see the actual routing. I'm curious if it's pretty much the Manhattan Distance, or pretty close. (Again, routing is almost always good, which is why this is strange). That's at least a good starting point...Honored Contributormy design uses a great amount of memory (M9K) close to 450 M9K, can it be the reason ?
Honored ContributorYes, but there are a ton of things that can cause the problem(it's seldom black-and-white). Using memories causes the routing congestion to go up, just like using any resource. One thing to look at in the fit report is routing utilization(average and peak). There's no perfect rule of thumb, but it would be worth posting. (If your path is using direct routes, then it's not a routing issue anyway).
If M9Ks are being used to build larger rams, then it can be a problem too. For example, if it was building an 18Kx72 RAM, for example, then your address bits would be fanning out to 144 M9Ks, and are naturally going to have long hops(unless logic is duplicated, either in the code, with directives or physical synthesis).
