Forum Discussion
Quartus Router Congestion
Hello all,
I have a Cyclone V A9 device (300k LEs) and a big design that fit it 95% ALM 12% Memory bits 37% DSP. 14% of ALM are unavailable due to LAB input limits and wide-signals conflicts so real used space is 81% of ALM. Compilation fail due to Warning (16618): Fitter routing phase terminated due to routing congestion. Congestion details can be found in Chip Planner. Critical Warning (188026): The Fitter failed to successfully route the design. You may be able get this design to route by making design modifications, changing the fitter seed or by enabling the Fitter Aggressive Routability Optimizations logic option. etc.. Attached a Chip Planner blank and with congestion map. Threshold is at 99%, why in black area (= no my logic) there is a congestion? What is in that area (circled yellow into images)? I am trying to change some settings and floorplanning design but every compilation take 1+ hour (I use .vqm file generated by another tool so analysis and synthesis is fast, i do just routing) Image link: http://it.tinypic.com/r/2wecbdk/9 Thank you30 Replies
- Altera_Forum
Honored Contributor
I think that's the Hard PCIe block. Strange it shows up as routing congestion but not sure if I've looked at that or not. In the messages, where is the area of most congestion?
Besides Fitter Aggressive Routability, I would suggest turning up the Placement Effort to 8(More Fitter Settings) and create a quartus.ini with the following: vpr_placement_effort_targets_all_edges = on This will make your compile time go up, but basically makes the placer spend more timing making moves that make the design get better timing AND make it more routable(without the .ini it just does the former). This might work, but you may be too congested. To be honest, reducing the logic a bit is probably your best bet in that case. Unless there's something explicitly wrong with the floorplan the fitter chooses, manually floorplanning doesn't really help. I also find it strange that 14% of your ALMs are lost due to LAB input limits. I don't look at the number much but I believe it's because that line item is usually a really small percentage. That basically means your LABs have the maximum number of signals coming into them, which basically means they require the maximum amount of required routing to get to them, i.e. not only are you using a lot of resources, your design is naturally tough to route. (This is one of those things that doesn't jump out of the raw numbers. You could build a shift register that uses 100% of the ALMs and Quartus would have no problem routing it, but a cross-bar mux would be significantly more difficult.) One last thing to try, if you're using a more recent version of Quartus(I forget which, maybe Q15.0 and beyond), but try Fitter -> More Settings -> Advanced Physical Optimizations, which is a different algorithm that is supposed to improve routability. Good luck, as fixing no routes is not easy. - Altera_Forum
Honored Contributor
I don't use PCIe, only 4 pins with external worlds. Design use a lot of pipeline stages with a lot of logic (dividers, multipliers, etc..).
Routing failure is with Placement Effort = 8.0 and using Advanced Physical Optimization. I am using latest version of Quartus (15.1 update 1). I will try vpr_placement_effort_targets_all_edges in the next compilation. - Altera_Forum
Honored Contributor
Pipe stages on their own shouldnt kill the routing. Do you have a lot of high fan out regs? could you do some register duplication?
- Altera_Forum
Honored Contributor
Hello tricky,
This is my Quartus report: Maximum fan-out node pll:u_pll|pll_0002:pll_inst|altera_pll:altera_pll_i|outclk_wire[0] Maximum fan-out 68382 Total fan-out 910053 Average fan-out 3.92 I have enabled register duplication, now is compiling with three design partitions with logiclock regions with auto size and location. With custom logiclock regions (following altera guidelines) design failed into routing. Thanks - Altera_Forum
Honored Contributor
sometimes you just have to do manual register duplication in the HDL - its not too hard, but a little tedious.
Find some regs (a PLL is obviously going to have a high fanout) with a high fan out and use the maxfan attribute on them in the hdl, so that synthesis automatically duplicates a register when the fanout gets too high. Or you can manually duplicate the register and use the preserve synthesis attribute to prevent the two being merged. Then have separate parts of the design fed from the two separate (but identical) registers. - Altera_Forum
Honored Contributor
The PLL is on a global which has dedicated routing, so the fanout doesn't matter. Only 4 pins to the external world? That's impressive.
I think you've just hit a wall and will probably have to remove some logic, which admittedly is not easy. There's no guarantee that a device can be filled that full and always fit. (Although I have seen some impressive thing, like the largest Stratix V GX BB device filled to 99% Logic Utilization which I would have said would never fit.) Two designs of the same Logic Utilization can have significantly different routing requirements, or at least enough to have one always fit and one not fit at all. - Altera_Forum
Honored Contributor
What may also help is to partition the design into key blocks - ones where there are many internal routes, but a lower number of routes between that block and the rest of the design. What you can then do is add logiclock regions into the design to constrain partitions to certain areas. This can help timing in some cases (brings logic with critical paths closer together), but also can help with routing congestion by avoiding the logic being scattered around in a way which means there is lots of competition for resources.
On a design I'm working on, it is pretty much impossible to get it to route and meet timing without logiclock regions. - Altera_Forum
Honored Contributor
Yes, a simple UART to talk to external world.
I tried with max fanout limit of 90 but now I am out of LAB.. I am revisiting reset logic to reduce congestion.. Wow.. a 952K LEs full.. I hope compile times is good enought :) - Altera_Forum
Honored Contributor
If it's just a uart, then surely the data rate isnt very high? cant you just re-use some of the logic and process different stages at different times, so you dont use all the logic (and hence the routing) all up?
- Altera_Forum
Honored Contributor
Data is inserted into system at startup and then a very long algorithm is executed.. at the end data is retrieved to read result. No way to reuse some of the logic..