Improve readability of report_clock_skew

[oharboe]

Description

Before running example, make sure this fix is in: #4886 (comment)

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

[maliberty]

Could report_clock_skew simply report the arguments with which to run

With which to run what?

[oharboe]

@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.

[oharboe]

@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?

[maliberty]

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.