Reading a Pre-CTS Timing Report

Placement is done and legalised, and every cell in alu8 has a real location. Time to point OpenSTA at it and see what the design’s worst path looks like now that wire delay means something more than zero. This is a real milestone: the first timing report in this course that uses placement-derived parasitic estimates instead of synthesis-stage guesses.

alu8 runs at 50 MHz, a 20 ns period. Here is report_checks on the worst setup path, post-placement and pre-CTS:

Startpoint: op_reg[3] (rising edge-triggered flip-flop clocked by clk)
Endpoint: result_reg[3] (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max

  Delay    Time   Description
-----------------------------------------------
   0.00    0.00   clock clk (rise edge)
   0.00    0.00   clock network delay (ideal)
   0.00    0.00   clock uncertainty
   0.15    0.15   op_reg[3]/CLK (sky130_fd_sc_hd__dfxtp_2)
   0.42    0.57   op_reg[3]/Q (sky130_fd_sc_hd__dfxtp_2)
   0.31    0.88   net op_reg[3]_Q (placement-estimated parasitics)
   0.38    1.26   U84/Y (sky130_fd_sc_hd__xor2_2)
   0.22    1.48   net U84_Y (placement-estimated parasitics)
   0.54    2.02   U91/Y (sky130_fd_sc_hd__and2_4)
     ...     ...   (12 more cell/net segments through the carry chain)
   0.61   18.20   result_reg[3]/D (sky130_fd_sc_hd__dfxtp_2)
  18.20   18.20   data arrival time

  20.00   20.00   clock clk (rise edge)
   0.00   20.00   clock network delay (ideal)
   0.00   20.00   clock reconvergence pessimism
  -0.15   19.85   library setup time
          19.85   data required time
-----------------------------------------------
  19.85            data required time
 -18.20            data arrival time
-----------------------------------------------
   1.65            slack (MET)

The two halves

Every report_checks path is two independent calculations compared at the end. The top half is data arrival time: start from the launching clock edge at op_reg[3] and add up every cell delay and every net delay along the logic path, ending at 18.20 ns when the signal reaches the D input of result_reg[3]. The bottom half is data required time: start from the next clock edge at 20.00 ns and subtract the receiving flop’s library setup time of 0.15 ns to get 19.85 ns, the latest moment the data is allowed to arrive.

$$\text{slack} = \text{required} - \text{arrival} = 19.85 - 18.20 = 1.65 \text{ ns}$$

Positive slack means the path meets timing with 1.65 ns to spare. That is the number that ends the report, slack (MET).

The line that should catch your eye

Look again at clock network delay (ideal). It appears twice, once for the launch edge and once for capture, and it is 0.00 in both places. That is not a measurement. It is an assumption. No clock tree exists yet, since building one is Module 5’s entire job, so OpenSTA has nothing to model for clock insertion delay or skew and simply assumes the clock reaches every flop instantly and simultaneously.

This ideal-clock assumption is why the report can only speak meaningfully about setup, and even that with a caveat. Hold is almost always trivially met under an ideal, zero-skew clock, because there is no skew to eat into the hold margin. The moment a real clock tree exists with real, non-uniform insertion delays to each flop, that free pass disappears. The next article turns that into an explicit list.

So do not read “slack (MET)” here and consider timing closed. This is a checkpoint, not signoff. Every number in the report except the cell delays is either idealised (the clock) or estimated (parasitics from placement geometry rather than routed shapes). A pre-CTS MET means “no obvious placement disaster”, not “timing is done”.

Verifying the arithmetic

Using only the two numbers printed in the report, required time 19.85 ns and arrival time 18.20 ns, compute the slack by hand: 19.85 - 18.20 = 1.65 ns, which matches. It feels trivial, but the habit of checking a tool’s headline number against the two numbers that produced it is what catches misread reports, a wrong path group or a startpoint and endpoint that are not the ones you thought, before they cost an afternoon of debugging the wrong problem.

Practice Exercise

A second path on alu8, op_reg[7] to result_reg[7], reports a data arrival time of 19.40 ns against the same 20.00 ns clock edge, the same 0.15 ns setup time and the same ideal clock. Compute its slack and say whether it passes.

This report told you what is true about the design’s timing so far, and just as importantly what it cannot tell you yet. The next article makes that second list explicit and complete, as a direct bridge into Modules 5 and 7.