The-OpenROAD-Project
Improve readability of report_clock_skew
Description
Before running example, make sure this fix is in: https://github.com/The-OpenROAD-Project/OpenROAD/issues/4886#issuecomment-2036039360
Output from report_clock_skew is a bit hard to read:
>>> report_clock_skew
Clock clock
337.78 source latency ces_4_7/clock ^
78.36 source clock tree delay
-359.04 target latency io_lsbs_39$_DFF_P_/CLK ^
-3.01 CRPR
--------------
54.09 setup skew
Clock clock_vir
No launch/capture paths found.
>>> report_checks -through {ces_4_7/clock} -to {io_lsbs_39$_DFF_P_}
Startpoint: ces_4_7 (rising edge-triggered flip-flop clocked by clock)
Endpoint: io_lsbs_39$_DFF_P_ (rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: max
Delay Time Description
---------------------------------------------------------
0.00 0.00 clock clock (rise edge)
337.78 337.78 clock network delay (propagated)
0.00 337.78 ^ ces_4_7/clock (Element)
152.65 490.43 ^ ces_4_7/io_lsbOuts_7 (Element)
0.03 490.47 ^ io_lsbs_39$_DFF_P_/D (DFFHQNx2_ASAP7_75t_R)
490.47 data arrival time
250.00 250.00 clock clock (rise edge)
359.04 609.04 clock network delay (propagated)
-10.00 599.04 clock uncertainty
3.01 602.05 clock reconvergence pessimism
602.05 ^ io_lsbs_39$_DFF_P_/CLK (DFFHQNx2_ASAP7_75t_R)
-4.63 597.42 library setup time
597.42 data required time
---------------------------------------------------------
597.42 data required time
-490.47 data arrival time
---------------------------------------------------------
106.95 slack (MET)
The test case was produced with make DESIGN_CONFIG=designs/asap7/mock-array/config.mk
To launch GUI:
untar gui.tar.gz
. vars-mock-array-asap7-base.sh
ODB_FILE=results/asap7/mock-array/base/5_route.odb ./run-me-mock-array-asap7-base.sh
OpenROAD v2.0-12845-gd71278409
[deleted]
Suggested Solution
- Could report_clock_skew simply report/make clear what arguments to pass to report_checks to examine a path with maximum skew? That way it wouldn't be necessary to repeat the output that report_checks gives in report_clock_skew and explain how report_clock_skew output correlates to report_checks output. report_checks should be more familiar than report_clock_skew as, I suppose, it is a command one learns before report_clock_skew.
- Correlation from report_clock_skew to report_checks should be immediately clear.
- There should be a way to figure out where "78.36 source clock tree delay" comes from. I can't find it in the report_checks output.
- Spell out "CRPR" so that it uses the same string as in report_checks.
Additional Context
No response
Could report_clock_skew simply report the arguments with which to run
With which to run what?
@maliberty Added
Could report_clock_skew simply report the arguments with which to run
With which to run what?
Updated example above: output from report_clock_skew is fed into a report_checks command.
@tspyrou What I'm really after is to examine the maximum useless skew, whereas report_clock_skew reports the maximum skew, which could be a useful skew...
How would I find the maximum useless skew?
Note that what is maximum for setup may not be for hold so you would have to have some option for that. I'll leave it to @tspyrou to decide what is practical here. I am fairly sure no other tool reports skew in this way.