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 536 forks source link

sta slow at reporting clock skew #4840

Open maliberty opened 6 months ago

maliberty commented 6 months ago

Describe the bug

In this test case report_checks takes ~2 minutes to run while report_clock_skew takes ~25 minutes. This seems surprisingly different.

This is extracted from https://github.com/The-OpenROAD-Project/OpenROAD/issues/4828 as a standalone sta test case.****

Expected Behavior

Faster report_clock_skew

Environment

Using the sta built from OR:

OpenSTA 2.5.0 073ff2e8c8

To Reproduce

Use https://drive.google.com/file/d/1xqfCArlnRCESUx0uDK77IpEoaadTB0mJ/view?usp=drive_link

% sta sta.tcl

Relevant log output

start report_checks Thu Mar 21 14:22:31 PDT 2024
...
start report_clock_skew Thu Mar 21 14:24:26 PDT 2024
...
done Thu Mar 21 14:50:14 PDT 2024

Screenshots

No response

Additional Context

No response

QuantamHD commented 6 months ago

Isn't this the thing Antmicro reported

maliberty commented 6 months ago

I recall them reporting an issue with threading, was there a similar performance issue reported? Is there an issue or PR?

QuantamHD commented 6 months ago

https://github.com/The-OpenROAD-Project/OpenSTA/pull/220

I think that one

maliberty commented 6 months ago

That represents a possible solution by threading. I'm still surprised that the single threaded time spread is so large. In any case it is a useful example.