Bad placement result from Quartus 13.1.0 and How to work around?

[Altera_Forum]

Hello All, 

 I am using Quartus 13.1.0 64-bit version. I think I got an example of bad placement result. And I want to know how I can resolve this (say, by using some kind of constraint)?  In my case, TimeQuest reported timing violations for a path, which is from logic to block memories. And when I examine the graphical data path, I see that Quartus has placed the memory too far away from the logic. (see my attached image 1).  This is confirmed when I examine delay of each stage of data path. I can see that the interconnect delay (IC) connecting the logic to the memory is 2.460 ns (too large!). (see my attached image 2)  So I would say this is probably a bad placement.  Then my question is: how can I resolve this (say, by using some kind of constraint)?  Thanks.  https://www.alteraforum.com/forum/attachment.php?attachmentid=9296  https://www.alteraforum.com/forum/attachment.php?attachmentid=9297

[Altera_Forum]

Its not always the fitter's fault. It may be being torn in two directions to meet timing, and ends up giving up. I cant see the ram usage, but if the usage is fairly high, it can start to struggle getting signals in and out of RAMs and DSPs. There are several things to have a play with: 

 1. Are the rams under heavy utilisation? Its often best to add an extra pipeline stage just to make life easier for the fitter to route into and out of the rams and DSP. Like i said, if it's struggling to meet timing in more than one place, it can sometimes get into a situation where you'll get the same failure coming over and over again because of this routing problem. 2. Try a set_max_delay constraint between the two problem registers , but you may then get a failure in the previous path (so your only option is the extra pipeline register) 3. Have you tried a different fit seed (this only applies if the source code and contraints remain identical). Or even try the design space explorer to try several seeds at the same time (requires multiple licences or a long wait).

[Altera_Forum]

PS. what are your clock constriants and resource usage?

[Altera_Forum]

Your clock constraints already tell the fitter what's important and I'm guessing it knows that it's not meeting timing but can't do anything. Does this specific path break every time or does it hop around to signals like it. Note that just moving the source LUT closer won't meet timing, it just pushes the long hop further back in the path. You have to move the entire path closer. But the LUTs have fanouts of 17, 53, 18, etc. Those often multiply up(i.e. the fanout 17 node drives 17 nodes, all with a fanout of ~50, etc.) So you may have hundreds or thousands of nodes that all need to move with it, or might have their timing break if you moved just this path. Run: 

report_timing -setup -npaths 500 -detail path_only -pairs_only -from "source_register" -panel_name "Critical Source's 500 fanouts" Just replace source_register with the source register in this path. After it lists the 500 nodes, highlight them all and right-click Locate in Chip Planner. (You'll have to double-click on the 500 paths in the Locate window there). You'll see where the top 500 paths go. Bottom line is that it's probably not a trivial problem that the fitter wasn't working on, but something that is very complex and that's the solution it came up with. As Tricky says, please run multiple seeds and analyze the results. See if it' the same path every time, or does it hop around to other things completely or similar paths? Does the slack get a lot better and this is an outlier, or do they always fail by this much. I often suggest manually duplicating logic, but the large fanout node is so far down the combinatorial logic it may be hard to do. If there's anything you can do in the code that would help, that's the first place to look. As for Quartus settings, try Tools -Advisors -> Timing Optimization Advisor and try the High Effort Fmax settings(basically these are the buttons you can push to help get better performance). It's seldom enough to shave 700ps off a design, but might be worth trying. Monitor if your compile time goes up though, since that's the main trade-off, and see if the trade-off is worth it.(If compile time goes up by 2 hours and you only get 100ps better performance, it may not be worth it. And remember that you need to run multiple seeds both before and after the changes to real gauge what they do...)