Fanout cells inserted during global placement #6643
Comments
|
@kareefardi Recently we've enabled non-virtual runs of repair_design during global placement. It means that the modifications made during timing-driven global placement are preserved during the gpl flow, in order to achieve better correlation regarding placement density in the different stages. @gudeh can give more details of this new feature. |
|
Hi @kareefardi, indeed it is not gpl itself that modifies the design. What happens is that gpl makes calls to rsz repair_design if gpl timing_driven option is enabled (which is by default). On gpl initial iterations we do virtual calls to repair_design meaning we undo all of rsz modifications, and we maintain only some internal weights for gpl calculations. On later gpl iterations we maintain whatever changes rsz made, meaning we have new cells inserted in the middle of placement execution. Further info available here: #6165, on the PR where we added this feature. Prior to this change all timing-driven iterations by gpl were purely virtual, so there was no changes to the design. So in summary, gpl modifications to cells could seem unintentional, but they are because we make calls to rsz repair_design, which does modify the design with cell resizings and buffer insertions. I do not have a deep understanding of all the repair_design modifications, do you think any of its modifications are incorrect somehow? |
|
It is intentional to add optimization to gpl as it allows for the placer to account for the added area from optimization. If you really don't want it the -keep_resize_below_overflow would allow you to avoid it but you may get worse timing results in the total flow. |
|
Thanks for you replies. I don't believe the modification done are incorrect but it was surprising behavior to me at least. I think a proposed action here is to first add this to the documentation. I was also thinking global placement log should somehow be more verbose about this for example it might print the number of fanout violations it attempted to fix (similar to Finally, would using |
|
-keep_resize_below_overflow set to 0 would return to the old behavior, but IMO this generally improves the openroad placement result. I wouldn't disable it by default unless you see degradation in your flow, and is similar to the off the shelf tools you can buy. |
|
There is some explanation about timing-driven mode and the Currently gpl reports the change in area due to repair_design changes. |
|
Think of it as a fused placement + optimization approach. Over time I expect more of optimization will be fused (eg repair_timing as well as repair_design). |
|
Ok I understand the fused placement + optimization approach and setting
Side note: |
|
I believe the suggestion of reporting the cells added is pertinent. I tried doing that when the integration was implemented but the rsz repair_design API for gpl is a little awkward considering the way it counts inserted cells, I shall have a look at that again. |
|
I would second the reporting the changes, I think it would provide some useful feedback as well. |
|
The recently merged PR #6732 (comment) modifies RSZ verbose behavior and introduces more information to GPL repair design calls. We changed the RSZ default verbosity to false for repair design and timing in OR, it now always shows the first and last iterations for the progression messages. I am going to look into the specific requested print for fan out violations and other messages. |
Describe the bug
This is new behavior and there is nothing in the documentation which suggests that this is intentional. I also believe that global placement shouldn't manipulate the design at all.
Expected Behavior
Clarification if this is a bug or intentional.
Environment
To Reproduce
This is an openlane2 reproducible. If a simpler test case is needed please let me know. To run: extract and cd into the extracted directory and run
run.sh.reproducible.tar.gz
Relevant log output
Screenshots
No response
Additional Context
Using
report_cell_usagebefore and after global placement shows additionalTiming Repair BufferThe text was updated successfully, but these errors were encountered: