floorplan can easily "run forever" for simple designs when REMOVE_ABC_BUFFERS=0

[oharboe]

Description

@jeffng-or @precisionmoon @maliberty I generally run with REMOVE_ABC_BUFFERS=1, because otherwise floorplan can easily be "stuck forever" on this step.

Here is one example today where I added REMOVE_ABC_BUFFERS=1.

untar floorplan_sdq_17x64_asap7_base_2024-09-15_18-17.tar.gz

$ ./run-me-sdq_17x64-asap7-base.sh 
OpenROAD v2.0-15616-ga487b9b68 
[deleted]
   Iter   | Removed | Resized | Inserted | Cloned |  Pin  |    WNS   |   TNS      |  Viol  | Worst
          | Buffers |  Gates  | Buffers  |  Gates | Swaps |          |            | Endpts | Endpt
---------------------------------------------------------------------------------------------------
        0 |       0 |       0 |        0 |      0 |     0 |  -74.530 |   -78521.3 |   1152 | mem\[10\]\[0\]$_DFFE_PP_/D
       10 |       0 |       9 |        0 |      0 |     0 |  -74.209 |   -78354.5 |   1152 | mem\[4\]\[0\]$_DFFE_PP_/D
[lots and lots of these warnings]
[WARNING RSZ-0075] makeBufferedNet failed for driver _6421_/Y
[runs for several minutes]

There's essentially no progress on WNS after a few iterations:

Very little is happening with TNS. I've always used slack histograms rather than TNS, so don't quite know what to make of TNS, but thought it might be useful to plot.

Something is happening here until about 2/3 of the iterations...

Suggested Solution

REMOVE_ABC_BUFFERS=1 is deprecated. Some alternative, probably enabled by default, that doesn't make ORFS "run forever" on simple designs. The use case/intent here is not to get the world's best PPA, but just to set up the flow and flush the pipe before examining where in the design the problems are.

Additional Context

No response

[maliberty]

If you try adding -repair_tns 0 to repair_timing, does that help?

[oharboe]

If you try adding -repair_tns 0 to repair_timing, does that help?

Still slow, still > thousand iterations, several minutes:

repair_timing -verbose -repair_tns 0
[WARNING RSZ-0021] no estimated parasitics. Using wire load models.
[INFO RSZ-0094] Found 1152 endpoints with setup violations.
[deleted]
    1191* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1192* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1193* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1194* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1195* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1196* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1197* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1198* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1199* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    1200* |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
    final |       0 |     276 |        0 |     10 |     8 |  -67.387 |   -73420.6 |   1152 | rd_out\[61\]$_DFF_P_/D
---------------------------------------------------------------------------------------------------
[INFO RSZ-0041] Resized 276 instances.

[oharboe]

A non-sequitor to this issue: the output from report_timing is enormously verbose. I think on the order of all the other .log output in some cases.