search

The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.53k stars 533 forks source link

Integrate repair_design and global_placement #5291

Open maliberty opened 3 months ago

maliberty commented 3 months ago

Description

Running repair_design after global_placement can lead to a placement density hotspots that deteriorate results.

Suggested Solution

Early in global placement the positions are subject to too much change to commit to the actual buffering/sizing of repair_design. As the placement overflow gets low enough and the placement is stabilizing it makes sense to switch to actually modifying the design so that the density can be seen.

This will require significant tuning to determine the right point at which to switch over and also to ensure that multiple calls to repair operate well.

@gadfort @QuantamHD @rovinski for any opinions. I want to align on the goal before we get too far into implementation.

Additional Context

No response

rovinski commented 3 months ago

None in particular, seems like a hard problem. I'm curious to how sensitive RePlAce results are based on when cells are inserted. There may need to be some kind of temporary bump in gradients to ensure that it converges quickly.

maliberty commented 3 months ago

@rovinski in at least some designs I've seen that the repairs are concentrated in local areas. I also considered doing some global adjustment for the amount of area predicted during virtual resizer but I'm concerned that it won't resolve local issues.

gudeh commented 3 months ago

Hi everyone. This is what happens on GPL timing-driven placement: during GPL, we call timing-driven based on a list of 6 fixed values of overflow, defined in src/gpl/src/replace.tcl: set overflow_list [list 79 64 49 29 21 15].

When a timing-driven iteration happens, the resizer does all its work and afterwards removes all the work done (we call it a virtual resizing), such as resizing, buffer insertion, and pin swapping (possibly more modifications, I am not sure yet). What is kept in GPL are only the slack weights calculated by the resizer's work and placement changes based on the slack weights only (due to timing-driven adjustments).

I tried a first experiment by keeping the work done by the resizer only on the last overflow value (15), meaning the last timing-driven iteration is not a virtual one, and we get a nice density correlation between steps 3_3_place_gp and 3_4_place_resized.

We currently have a mismatch between the same steps in master:

Since GPL goes only until overflow 0.10, keeping the work by the resizer on other iterations should be better. I will try that.