Cho Moon
Cho Moon
> @precisionmoon with #4459 and -obstruction_aware does the skew improve? Worst skew remains at 58.56 immediately after CTS with and without -obstruction_aware, even after #4459. Clock clock Latency CRPR Skew...
[test.tar.gz](https://github.com/The-OpenROAD-Project/OpenROAD/files/13610590/test.tar.gz) estimate.tcl reproduces the issue
One simple use model is to add an option to write_timing_model like -use_derate to honor STD. An info or warning message would be nice that explains that timing derates are...
It seems that the timing repair step is degrading the clock skew. Some of timing repair can be pulled into CTS to mitigate this issue. @oharboe, what's the needed timeline...
> I would guess it is repair_clock_nets rather than repair_timing that is the problem (the later shouldn't touch the clock tree). Correct.
> @precisionmoon, just a reminder all code related to our stuff is required to have a C++ unit test. Yes, I already added one new unit test for manual buffer...
The latest OR dashboard looks good except for gf180 jpeg. When I ran mine + Eder's fastrack.tcl PR https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2177, the final TNS became -0.68.
@maliberty this PR is ready for merge
Yes, the slack here seems to assume arrival of 0 at input. Slack penalty seems like a proxy for slew degradation with many buffers. A negative slack becomes more negative...
This may benefit from odb based save/restore. I will look into it.