Virtual Resizer running out of memory

[maliberty]

Describe the bug

From The-OpenROAD-Project/OpenROAD-flow-scripts#1296

This test case sees memory blow up. It happens during the call to the virtual resizer from the global placer. It seems to be stuck buffering a net forever.

Expected Behavior

Reasonable memory and runtime.

Environment

Head of master

To Reproduce

https://drive.google.com/file/d/1B--Yyo3EOvMHq2ySyXwNk24psujtZEoZ/view?usp=sharing

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[maliberty]

In your sdc

set_max_transition 0.5000 [current_design]

is a ridiculously small value (0.5 ps). This is unachievable and should be relaxed or removed.

@openroadie this has happened before. We should have some check for unrealistic values in rsz.

[openroadie]

How do we decide that ? Isn’t this similar to the other max fan out issue we had with pad cells in terms of input data being unreasonable in this one situation ?

…

On Thu, Aug 3, 2023 at 4:57 PM Matt Liberty ***@***.***> wrote: In your sdc set_max_transition 0.5000 [current_design] is a ridiculously small value (0.5 ps). This is unachievable and should be relaxed or removed. @openroadie <https://github.com/openroadie> this has happened before. We should have some check for unrealistic values in rsz. — Reply to this email directly, view it on GitHub <#3783 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3MSTI423D2LXUYU5I5SK7TXTQ3E5ANCNFSM6AAAAAA3DNBHCI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[maliberty]

For the driver I looked at first the .lib has

        rise_transition (delay_template_7x7_x1) {
          index_1 ("5, 10, 20, 40, 80, 160, 320");
          index_2 ("0.72, 1.44, 2.88, 5.76, 11.52, 23.04, 46.08");
          values ( \
            "10.1188, 14.0855, 22.2068, 38.5073, 71.1177, 136.355, 266.807", \
            "11.0499, 14.8335, 22.5676, 38.5701, 71.1242, 136.338, 266.807", \
            "13.6927, 17.1307, 24.4602, 39.7401, 71.4183, 136.305, 266.807", \
            "17.5019, 21.8414, 29.5364, 43.871, 74.1886, 137.172, 266.802", \
            "23.0783, 28.2967, 37.563, 53.7631, 82.5128, 143.084, 268.878", \
            "31.5913, 38.3363, 49.9273, 69.1968, 102.281, 160.275, 280.289", \
            "45.6565, 53.8354, 68.0495, 92.3316, 131.999, 200.256, 315.722" \
          );

its pretty clear 0.5 is never going to happen.

[maliberty]

The smallest I see for any cell in asap7 is around 8ps...

[openroadie]

Ok. So should the resizer analyze the libs or should this be a higher level functionality for sanity checking ?

…

On Thu, Aug 3, 2023 at 5:01 PM Matt Liberty ***@***.***> wrote: The smallest I see for any cell in asap7 is around 8ps... — Reply to this email directly, view it on GitHub <#3783 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3MSTI2YOESZ2Q3P44E45N3XTQ3W5ANCNFSM6AAAAAA3DNBHCI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[maliberty]

A sanity checker would be good as it could be extended for more checks.

[openroadie]

Ok. I will use this issue to address the infinite loop and we can start thinking about how/where/when for the sanity checker.