Games / Command flash cards / Timing reports / Reading a report

Reading a report

Each card shows real tool output to read. A missed card returns later in the round and starts the schedule over. A card answered correctly moves up the schedule and next appears after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. A hint keeps the card where it is on the schedule. An ordering card is answered by clicking its items in order, and one wrong click ends it. Time values are in nanoseconds. Progress is stored in this browser.

SourceThese cards follow the reporting commands of OpenSTA, the open-source static timing analyzer used by OpenROAD, and each answer links to that command in the OpenSTA command reference. Report commands are not a standard: other timers name and format their reports differently. The report excerpts are real OpenSTA output from the gcd example design. Reference: OpenSTA command reference (OpenSTA on GitHub).

All 15 cards in this section, with answers

Which kind of check does this path report?

report excerpt

Startpoint: dpath.b_reg.out[4]$_DFFE_PP_
            (rising edge-triggered flip-flop clocked by core_clock)
Endpoint: dpath.b_reg.out[4]$_DFFE_PP_
          (rising edge-triggered flip-flop clocked by core_clock)
Path Group: core_clock
Path Type: min
   ...
   0.00    0.00   clock core_clock (rise edge)
   0.07    0.07   clock network delay (propagated)
   0.15    0.22   clock uncertainty
   0.00    0.22   clock reconvergence pessimism
           0.22 ^ dpath.b_reg.out[4]$_DFFE_PP_/CK (DFF_X1)
   0.00    0.22   library hold time
           0.22   data required time
---------------------------------------------------------
           0.22   data required time
          -0.19   data arrival time
---------------------------------------------------------
          -0.04   slack (VIOLATED)

A hold check: the path type is min, with a library hold time.

Hint: Look at the Path Type line, and at which library time the capture side uses.

Path Type: max is a setup check and Path Type: min a hold check. The capture side confirms it: a setup report subtracts library setup time, a hold report adds library hold time. A path from a register back to itself is common in hold reports. OpenSTA reference

How is the slack of -0.06 obtained?

report excerpt

   0.38    0.38   clock core_clock (rise edge)
   0.07    0.45   clock network delay (propagated)
   0.00    0.45   clock reconvergence pessimism
           0.45 ^ dpath.a_reg.out[9]$_DFFE_PP_/CK (DFF_X1)
  -0.03    0.42   library setup time
           0.42   data required time
---------------------------------------------------------
           0.42   data required time
          -0.48   data arrival time
---------------------------------------------------------
          -0.06   slack (VIOLATED)

The data required time, 0.42, minus the data arrival time, 0.48.

Hint: The two lines just above the final rule are the two numbers being compared.

Setup slack is required minus arrival: the data must arrive before the required time, so a later arrival gives a negative slack. For a hold check the order reverses, arrival minus required. OpenSTA reference

Why is the data required time 0.42 when the clock period is 0.38?
report excerpt
```
   0.38    0.38   clock core_clock (rise edge)
   0.07    0.45   clock network delay (propagated)
   0.00    0.45   clock reconvergence pessimism
           0.45 ^ dpath.a_reg.out[9]$_DFFE_PP_/CK (DFF_X1)
  -0.03    0.42   library setup time
           0.42   data required time
```
The capture clock reaches the register 0.07 late, and setup takes back 0.03.

Hint: Follow the capture side down: the edge time, then the clock tree, then the library time.

The capture edge occurs at 0.38 at the clock source, but it arrives at the register's clock pin through the clock tree, 0.07 later, at 0.45. The data must arrive the setup time before that: 0.45 minus 0.03 is 0.42. OpenSTA reference
Both clock edges show a clock network delay of 0.07. What does that mean for this path?
report excerpt
```
   0.00    0.00   clock core_clock (rise edge)
   0.07    0.07   clock network delay (propagated)
   0.00    0.07 ^ dpath.a_reg.out[2]$_DFFE_PP_/CK (DFF_X1)
   0.10    0.17 ^ dpath.a_reg.out[2]$_DFFE_PP_/Q (DFF_X1)
   ...
   0.38    0.38   clock core_clock (rise edge)
   0.07    0.45   clock network delay (propagated)
   0.00    0.45   clock reconvergence pessimism
           0.45 ^ dpath.a_reg.out[9]$_DFFE_PP_/CK (DFF_X1)
```
The clock reaches both registers equally late, so no skew.

Hint: Compare the launch side and the capture side line by line.

The launch side adds 0.07 to the arrival and the capture side adds 0.07 to the required time, so the two cancel. (propagated) means the delay was computed through the built clock tree; an estimate would read (ideal). OpenSTA reference

Which logic gate, after the launching flip-flop, adds the most delay, and why?

report excerpt

Fanout     Cap    Slew   Delay    Time   Description
-----------------------------------------------------------------------------
                          0.00    0.00   clock core_clock (rise edge)
                          0.07    0.07   clock network delay (propagated)
                  0.01    0.00    0.07 ^ dpath.a_reg.out[2]$_DFFE_PP_/CK (DFF_X1)
     4    7.49    0.02    0.10    0.17 ^ dpath.a_reg.out[2]$_DFFE_PP_/Q (DFF_X1)
     3    6.51    0.02    0.03    0.20 v _520_/ZN (NAND2_X1)
     1    2.04    0.01    0.02    0.22 ^ _551_/ZN (NAND2_X1)
     2    3.48    0.01    0.02    0.24 v _553_/ZN (NAND2_X1)
     1    5.86    0.01    0.03    0.27 v place79/Z (BUF_X1)
     2    7.97    0.01    0.02    0.29 ^ _554_/ZN (NAND2_X4)
     1    5.90    0.01    0.01    0.30 v _722_/ZN (NAND2_X4)
     2    8.76    0.01    0.01    0.32 ^ _724_/ZN (NAND2_X4)
    14   35.04    0.02    0.03    0.34 v _755_/ZN (NAND2_X4)
    16   35.73    0.05    0.07    0.41 ^ _854_/ZN (AOI21_X4)
     1    2.51    0.02    0.03    0.44 v _891_/ZN (NAND2_X1)
     1    1.71    0.01    0.02    0.46 ^ _894_/ZN (NAND3_X1)
     1    1.72    0.01    0.01    0.47 v _896_/ZN (NAND2_X1)
     1    1.44    0.01    0.01    0.48 ^ _897_/ZN (INV_X1)
                  0.01    0.00    0.48 ^ dpath.a_reg.out[9]$_DFFE_PP_/D (DFF_X1)
                                  0.48   data arrival time

_854_, the AOI21_X4, at 0.07: it drives a fanout of 16 and 35.73 fF.

Hint: The Delay column is per stage, and the Cap and Fanout columns say why a stage is slow.

The Delay column shows each stage's contribution, and the Cap and Fanout columns explain it: _854_ drives the largest load in the path, and its output slew of 0.05 is also the slowest, which slows the next stage. Capacitance here is in femtofarads, the unit this library uses. OpenSTA reference

What makes this hold check fail?

report excerpt

   0.00    0.00   clock core_clock (rise edge)
   0.07    0.07   clock network delay (propagated)
   0.00    0.07 ^ dpath.b_reg.out[4]$_DFFE_PP_/CK (DFF_X1)
   0.09    0.16 v dpath.b_reg.out[4]$_DFFE_PP_/Q (DFF_X1)
   0.02    0.18 ^ _825_/ZN (INV_X1)
   0.01    0.19 v _826_/ZN (OAI21_X2)
   0.00    0.19 v dpath.b_reg.out[4]$_DFFE_PP_/D (DFF_X1)
           0.19   data arrival time

   0.00    0.00   clock core_clock (rise edge)
   0.07    0.07   clock network delay (propagated)
   0.15    0.22   clock uncertainty
   0.00    0.22   clock reconvergence pessimism
           0.22 ^ dpath.b_reg.out[4]$_DFFE_PP_/CK (DFF_X1)
   0.00    0.22   library hold time
           0.22   data required time
---------------------------------------------------------
           0.22   data required time
          -0.19   data arrival time
---------------------------------------------------------
          -0.04   slack (VIOLATED)

The 0.15 clock uncertainty pushes the required time past the 0.19 arrival.

Hint: Work out what the required time would be without the extra line in the middle.

For hold, the data must arrive after the required time. Without uncertainty the required time would be 0.07 and the check would pass; the 0.15 of hold uncertainty moves it to 0.22. A hold violation is fixed by adding delay to the data path, not by speeding it up. OpenSTA reference

What does the clock reconvergence pessimism line of 0.00 mean here?
report excerpt
```
   0.00    0.00   clock core_clock (rise edge)
   0.07    0.07   clock network delay (propagated)
   0.15    0.22   clock uncertainty
   0.00    0.22   clock reconvergence pessimism
           0.22 ^ dpath.b_reg.out[4]$_DFFE_PP_/CK (DFF_X1)
   0.00    0.22   library hold time
           0.22   data required time
```
There was no early and late difference on the shared clock path to remove.

Hint: CRPR (Clock Reconvergence Pessimism Removal) credits back pessimism on the shared clock path. Ask what would create pessimism in the first place.

CRPR (Clock Reconvergence Pessimism Removal) credits back the difference between late and early delay on the part of the clock tree that launch and capture share, since one buffer cannot be early and late at once. With no derating or variation in this run, early and late delays are equal and the credit is 0. OpenSTA reference

What does this report tell you about the number of failing endpoints?

report excerpt

% report_checks -format end -group_path_count 6
max_delay/setup group core_clock

                                     Required  Actual
Endpoint                               Delay   Delay   Slack
------------------------------------------------------------
dpath.a_reg.out[9]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)
dpath.a_reg.out[4]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)
dpath.a_reg.out[8]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)
dpath.a_reg.out[10]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)
dpath.a_reg.out[6]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)
dpath.a_reg.out[0]$_DFFE_PP_/D (DFF_X1)    0.42    0.48   -0.06 (VIOLATED)

max_delay/setup group vclk_core_clock

                                     Required  Actual
Endpoint                               Delay   Delay   Slack
------------------------------------------------------------
resp_msg[14] (output)                   0.36    0.42   -0.06 (VIOLATED)
resp_msg[13] (output)                   0.36    0.42   -0.06 (VIOLATED)
resp_msg[11] (output)                   0.36    0.42   -0.06 (VIOLATED)
resp_msg[12] (output)                   0.36    0.42   -0.06 (VIOLATED)
resp_msg[9] (output)                    0.36    0.41   -0.05 (VIOLATED)
resp_msg[15] (output)                   0.36    0.41   -0.05 (VIOLATED)

At least 6 fail in each group; the list stops at the count asked for.

Hint: Look at the command line at the top: something there limits how many rows appear.

-group_path_count 6 limits the list to 6 per group, so it cannot show how many fail in total. report_tns, or -slack_max 0 with a large count, answers that. OpenSTA reference

What do these two numbers tell you together?
report excerpt
```
% report_wns
wns max -0.06

% report_tns
tns max -2.18
```
The worst failure is small, but at least 37 endpoints fail.

Hint: One number is the worst single failure and the other is a sum. Divide one by the other.

WNS (Worst Negative Slack) is the deepest failure and TNS (Total Negative Slack) the sum over failing endpoints. No endpoint fails by more than 0.06, so a total of 2.18 needs at least 2.18 / 0.06, about 37, failing endpoints. Both lines say max, so these are setup numbers. OpenSTA reference
What does this output say must be fixed before the slack can be trusted?
report excerpt
```
% check_setup -verbose
Warning: There is 1 input port missing set_input_delay.
  req_msg[5]
Warning: There are 18 output ports missing set_output_delay.
  req_rdy
  resp_msg[0]
  resp_msg[10]
   ...
  resp_val
Warning: There are 18 unconstrained endpoints.
  req_rdy
  resp_msg[0]
```
An input delay on req_msg[5] and output delays on 18 ports are missing.

Hint: These are warnings about missing constraints, not about failing timing.

Ports with no input or output delay are not timed, so their paths never appear in slack reports; a clean report_wns can hide them. The 18 unconstrained endpoints are the same 18 output ports. OpenSTA reference
This first table lists each group twice. Which lines are hold and which are setup?
report excerpt
```
% report_check_types
Group                                  Slack
--------------------------------------------
core_clock                             -0.04
vclk_core_clock                         0.22
core_clock                             -0.06
vclk_core_clock                        -0.06
```
The first core_clock and vclk_core_clock lines are hold; the second pair is setup.

Hint: Compare the four slack values with the worst hold and worst setup slack from the path reports.

The table has no labels, so compare it with the path reports: -0.04 is the worst hold slack from report_checks -path_delay min, and -0.06 is the worst setup slack. Min (hold) is printed first, then max (setup). OpenSTA reference
What does this clock skew report show?
report excerpt
```
% report_clock_skew
Clock core_clock
   0.07 source latency dpath.a_reg.out[12]$_DFFE_PP_/CK ^
  -0.07 target latency dpath.b_reg.out[9]$_DFFE_PP_/CK ^
   0.00 CRPR
--------------
  -0.00 setup skew

Clock vclk_core_clock
No launch/capture paths found.
```
Both clock pins see the same 0.07 latency, so setup skew is 0.

Hint: Skew is a difference. Look at the two latency lines and at what sits between them.

Skew is the target latency minus the source latency, adjusted by CRPR (Clock Reconvergence Pessimism Removal). The virtual clock reaches no registers, so it has no register pairs to compare, which is normal. OpenSTA reference
The clock is defined with a 0.38 ns period. What does this report tell you?
report excerpt
```
% report_clock_min_period
core_clock period_min = 0.44 fmax = 2267.21
vclk_core_clock period_min = 0.00 fmax = inf
```
Its register paths need 0.44 ns, so 0.38 cannot be met yet.

Hint: Compare the period reported here with the 0.38 ns the clock was given.

The minimum period comes from the worst same-edge register-to-register paths. fmax is its inverse, in megahertz: 1 / 0.441 ns is about 2267 MHz (megahertz). The virtual clock has no register paths, so it shows 0 and infinity. OpenSTA reference
What does this output tell you about the parasitics that were read?
report excerpt
```
% report_parasitic_annotation
Found 22 unannotated drivers.
Found 0 partially unannotated drivers.
```
22 driver nets have no parasitics, so their wires are ignored.

Hint: Annotation comes from the parasitics file, so ask what those 22 drivers are missing.

These nets got nothing from the SPEF (Standard Parasitic Exchange Format) file. A net without parasitics is timed with pin capacitance only, which is optimistic. -report_unannotated lists the nets, so they can be checked before the timing is trusted. OpenSTA reference
report_slack on the D pin of dpath.a_reg.out[9] prints this. What is the setup slack for rising data on core_clock?
report excerpt
```
(core_clock ^) r 0.15:0.02 f 0.15:0.04
(vclk_core_clock ^) r 0.16:0.26 f 0.18:0.24
```
0.02: each pair is printed min:max, and max is the setup check.

Hint: Each pair is two numbers separated by a colon: min first, then max.

r and f are rising and falling data; each gives min:max slack. Min is the hold check and max the setup check, so rising data has 0.15 of hold slack and 0.02 of setup slack, matching the 0.02 in the path report for this endpoint. OpenSTA reference