resizing introduces 600ps buffer for ASAP7 fakeram

[oharboe]

Describe the bug

Before resize.tcl:

>>> report_checks -from {u_sdq_17x64/rd_out[36]} -to {rd_out[36]}
Startpoint: u_sdq_17x64/rd_out[36] (internal pin)
Endpoint: rd_out[36] (output port)
Path Group: reg2out
Path Type: max

  Delay    Time   Description
---------------------------------------------------------
   0.00    0.00 ^ u_sdq_17x64/rd_out[36] (sdq_17x64)
   0.25    0.25 ^ rd_out[36] (out)
           0.25   data arrival time

  80.00   80.00   max_delay
   0.00   80.00   output external delay
          80.00   data required time
---------------------------------------------------------
          80.00   data required time
          -0.25   data arrival time
---------------------------------------------------------
          79.75   slack (MET)

after:

>>> report_checks -from {u_sdq_17x64/rd_out[36]} -to {rd_out[36]}
Startpoint: u_sdq_17x64/rd_out[36] (internal pin)
Endpoint: rd_out[36] (output port)
Path Group: reg2out
Path Type: max

  Delay    Time   Description
---------------------------------------------------------
   0.00    0.00 v u_sdq_17x64/rd_out[36] (sdq_17x64)
 638.57  638.57 v output101/Y (BUFx2_ASAP7_75t_R)
   0.01  638.58 v rd_out[36] (out)
         638.58   data arrival time

  80.00   80.00   max_delay
   0.00   80.00   output external delay
          80.00   data required time
---------------------------------------------------------
          80.00   data required time
        -638.58   data arrival time
---------------------------------------------------------
        -558.58   slack (VIOLATED)

To reproduce:

untar resize_top_asap7_fakeram_2024-09-20_19-30.tar.gz

./run-me-top-asap7-fakeram.sh

Expected Behavior

Improved timing after resize.tcl

Environment

v2.0-15789-gc38fd8ad1

To Reproduce

See above

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[oharboe]

@jeffng-or Another snag with fakeram... Not important to us right now, but I thought I would file this issue as the problem looks interesting on the surface and the test-case might be valuable.

[maliberty]

Using report_checks -from {u_sdq_17x64/rd_out[36]} -to {rd_out[36]} -fields {slew cap input nets fanout} -format full_clock_expanded you'll see beforehand:

Fanout     Cap    Slew   Delay    Time   Description
-----------------------------------------------------------------------------
     1    1.64 6536.31    0.00    0.00 ^ u_sdq_17x64/rd_out[36] (sdq_17x64)
                                         rd_out[36] (net)
               6536.31    0.25    0.25 ^ rd_out[36] (out)
                                  0.25   data arrival time

                         80.00   80.00   max_delay
                          0.00   80.00   output external delay
                                 80.00   data required time
-----------------------------------------------------------------------------
                                 80.00   data required time
                                 -0.25   data arrival time
-----------------------------------------------------------------------------
                                 79.75   slack (MET)

The 0 delay and huge slew tells you this is unrealistic and there is something wrong with the RAM model.

[oharboe]

so mystery solved? close?

I am not using fakeram and this is not an OpenROAD issue...

[maliberty]

It seems like you have a units issue