OpenROAD
OpenROAD copied to clipboard
The-OpenROAD-Project
Global Placer Improvement Discussion Topics
It has been mentioned that the global placer is non-ideal. I want to create this meta-issue to track what improvements are needed to improve the quality of the results.
What tasks can we complete to improve the quality?
Open Questions/Tasks
- [ ] Does timing or routability driven routing improve QoR?
@ravi-varadarajan would you mention what improvements you have in progress.
@QuantamHD I've often wondered if the routability and time driven options help or not. Both are currently disabled by default in Openlane:
configuration/placement.tcl:set ::env(PL_ROUTABILITY_DRIVEN) 0
configuration/placement.tcl:set ::env(PL_TIME_DRIVEN) 0
Thanks @antonblanchard I'm going to spend the next quarter trying to improve the tools significantly so your feedback is very valuable.
Hi @antonblanchard and @QuantamHD - In our runs with ORFS we turn on both ROUTABILITY_DRIVEN and TIMING_DRIVEN as default and have observed overall better QoR with those options turned on.
Having said that I am currently tuning both those options in the global placement flow and will be updating master with changes after metrics validation over the next next few weeks and any feedback is appreciated.
@ravi-varadarajan Are there any algorithmic improvement we could make beyond just taking advantage of the parameters?
Support for placement fences is missing. It won't immediately help QOR but is needed for multiple power domain work. It can also help with QOR if users want to guide the placer.
I did incremental placement in a pretty quick pass. Further improvements would be helpful there. This is needed for restructuring where you have a new blob of elements to place into an existing design you don't want to perturb a lot.
Are these the placement fences you're talking about?
My understanding of the above is we want to tag a sub graph in the netlist, and make sure it sits only in some polygonal region. Is that correct?
Yes though fences can be hard or soft (see FENCE vs GUIDE on REGION in DEF).
yes -- fence, region, guide support is being planned -- We are currently looking at looking at those constraint sin DREAMPlace to see what is currently supported.
Apart from the region constraints, we are also experimenting with doing away with a uniform global GP_PADDING value that is applied to all instances and instead use the structural netlist analysis and also the incremental groute interface to dynamically determine the padding for cells.
Another potential idea - I wonder if the placer could do a better job on designs with lots of macros. When we were debugging some issues last year, it seems like global placement places instances over the macros and when complete we just move them to the nearest legal place.
RTL-MP is the replacement to the current macro placer. You can try it out in ORFS, see https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/designs/gf12/coyote/config_hier.mk for an example of the control variables needed. There is work underway to make it the default.
Though the instances on macros problem is unrelated to that change. RTL-MP is just about better macro placement.
@antonblanchard Please contact if you need help in setting up the flow. To use RTL-MP you will need Verilog hierarchy in the input netlist.
I'm still currently doing manual macro placement but will test the macro placer at some point.
The issue I was thinking of is how global placement interacts with lots of (or large) macros. The fact it places instances over the areas occupied by macros and then fixes it up afterwards makes me think the routability and timing optimisations aren't doing much.
I could see a case where we have a lot of instances inside a macro that have to be legalized, and they end up all around the macro. This could be a pretty terrible result for timing as wires have to circumnavigate the entire macro.
In the default flow, the global placement engine (in the presence of Macros and std cells) will create overlaps between macros and stdcells. The default macro placer in OpenROAD uses this placement as a seed and fixes the macro locations after which a second pass of global placement is done during which there are placement blockages over the fixed hardmacors and hence there are no overlaps between macros and std cells.
On Fri, Apr 8, 2022 at 5:04 AM Anton Blanchard @.***> wrote:
I'm still currently doing manual macro placement but will test the macro placer at some point.
The issue I was thinking of is how global placement interacts with lots of (or large) macros. The fact it places instances over the areas occupied by macros and then fixes it up afterwards makes me think the routability and timing optimisations aren't doing much.
I could see a case where we have a lot of instances inside a macro that have to be legalized, and they end up all around the macro. This could be a pretty terrible result for timing as wires have to circumnavigate the entire macro.
— Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_The-2DOpenROAD-2DProject_OpenROAD_issues_1756-23issuecomment-2D1092790222&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=4UECCA9H6iULgkYUXu8ssuVqluhQS00616uzvNONbnw&m=vLcwDGiy4Kq_eg65qiFMB10-8-o_QVy7TtsM2zO2XI5zcnKU8Ze4BSLrr3rmK73a&s=bDyBkOozPx_Xqu7Sa_dYPNKZPf1z_7E4hTL-dRGftnE&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARAYQZCJ3N4BSMWA437DQOLVEAOGRANCNFSM5SWSBAWQ&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=4UECCA9H6iULgkYUXu8ssuVqluhQS00616uzvNONbnw&m=vLcwDGiy4Kq_eg65qiFMB10-8-o_QVy7TtsM2zO2XI5zcnKU8Ze4BSLrr3rmK73a&s=88AwXwVK0rYE8k6iaL5ZjUcjzzc5Tw6Rjnqr_jt1cxw&e= . You are receiving this because you were mentioned.Message ID: @.***>
@ravi-varadarajan I'm talking about these sort of issues: https://github.com/The-OpenROAD-Project/OpenROAD/commit/16becc678531e7ea034fc18e8f41e2481b899966. Aren't we moving cells more or less randomly, without any thought to routability or timing?
It's not as bad as I thought, but you can see that many of the cells that overlap the macro end up just to the top left or top right of the macro. This is the result of global placement, then detailed placement:
@ravi-varadarajan gpl doesn't guarantee that it won't leave an instance inside a blockage, it just increases the cost of that location and therefore reduces the likelihood. dpl has code to deal with such cases somewhat crudely.
@maliberty Is another round of gpl run after the illegal instances are moved?
Maybe that would be something worth taking a look at? My thoughts are kind of can we try to find a minimizing location for the instances stuck on the macro.
So either trying to place it next to it's fan-in/out or putting it somewhere off the macro in a semi intelligent way, and then re-runing gpl?
Is min-displacement semi-intelligent? That's what we do now. I'm not sure this is really a big source of trouble in most cases.
That seems reasonable. It seemed like Anton was suggesting that the instances just got moved to some legal location, which I thought might lead to unreasonably long routes in some cases. If this isn't an issue then no need to attack that area.
Another interesting thing. This is the top left corner of the above design when I enabled antenna fixups:
Most of that is antenna diodes. I do wonder if they are in the best spot. FYI this is Microwatt, which is now in ORFS.
This might be a byproduct of the macro having a halo on the north edge that extends right out to the edge of the die. At one stage I was having trouble with islands of unpowered met1, but that should only happen on the east and west edges so we could open it up a bit on the north and south side.
On this issue - when placing met1 rails could we check to see if the area was unable to be powered (ie it doesn't intersect both power and ground met4 straps?) and leave it empty?
We remove rows that can't be powered so if you have sites you should be able to power them.
@antonblanchard which of the many OL antenna fixing strategies are you using? I think it best to take this discussion to a new issue with a test case.