How to read a static timing analysis report

Almost every physical design interview gets to the same place: someone slides a timing report across the table and asks what it says. Candidates who have only read about static timing analysis freeze here, because a report is not a concept — it is a column of numbers that only makes sense once you know what each line is doing. This is how to read one.

What STA is actually checking

Static timing analysis asks one question for every path in the design: does the data arrive at the capture flop inside the window where that flop can reliably sample it? It answers without simulation, by walking the graph of cells and nets and adding up delays. Two checks fall out of that question.

• Setup — the data must arrive early enough, before the capture clock edge. Setup is a maximum-delay check.
• Hold — the data must stay stable long enough after the capture edge. Hold is a minimum-delay check.

Everything else in the report is bookkeeping in service of those two.

The anatomy of a path report

A path report has a header, a data arrival section, a data required section, and a slack line. Read it bottom-up the first time: find the slack, then work out how it was produced.

Startpoint: reg_a (rising edge-triggered flip-flop clocked by clk)
Endpoint:   reg_b (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type:  max

  Point                          Incr      Path
  --------------------------------------------------
  clock clk (rise edge)          0.000     0.000
  clock network delay            0.450     0.450
  reg_a/CK (DFF)                 0.000     0.450 r
  reg_a/Q (DFF)                  0.180     0.630 f
  U12/Z (BUF)                    0.090     0.720 f
  U19/Z (AND2)                   0.140     0.860 f
  reg_b/D (DFF)                  0.000     0.860 f
  data arrival time                        0.860

  clock clk (rise edge)          1.000     1.000
  clock network delay            0.470     1.470
  clock uncertainty             -0.050     1.420
  reg_b/CK (DFF)                 0.000     1.420
  library setup time            -0.090     1.330
  data required time                       1.330
  --------------------------------------------------
  data required time                       1.330
  data arrival time                       -0.860
  --------------------------------------------------
  slack (MET)                              0.470

The header

Startpoint is where the data is launched — a flop’s clock pin or an input port. Endpoint is where it is captured. Path Type: max tells you this is a setup check; min would be hold. Candidates often miss that one word and then argue the wrong fix.

Data arrival

The first block adds up the launch side. The clock takes 0.450 to reach the launching flop. The flop’s clock-to-Q costs 0.180. Then each cell and net in the combinational path adds its delay, ending at the capture flop’s D pin at 0.860. The r and f markers are the transition direction at that pin, which matters because cells have different rise and fall delays.

Data required

The second block builds the deadline. The capture edge is one clock period later (1.000). The clock takes 0.470 to reach the capture flop — note this is not the same as the launch clock delay, and that difference is your skew. Uncertainty is subtracted as a safety margin covering jitter and, pre-CTS, estimated skew. Finally the library setup time is subtracted, because the data has to be stable that long before the edge.

Slack

Slack is required minus arrival. Positive means the path passes with room to spare. Negative means a violation, and the magnitude tells you how much you need to claw back. Here, 0.470 of margin.

Reading a hold report

Hold reports look similar but invert the logic. The capture edge used is the same edge that launched the data, not the next one, so there is no clock period in the required calculation. The library hold time is added rather than subtracted, and slack is arrival minus required. The intuition: for hold, data arriving too fast is the problem.

This is why the two checks pull in opposite directions, and why you cannot fix one by blindly doing more of what fixed the other.

What to do about a violation

Setup violations

• Upsize cells on the critical path so they drive their loads faster
• Restructure the logic to remove levels — often the biggest single win
• Improve placement so the path’s cells sit closer together
• Apply useful skew: deliberately delay the capture clock to borrow time
• If nothing else works, pipeline the path — an RTL change, so raise it early

Hold violations

• Insert delay buffers on the data path — the standard fix, and cheap in area terms
• Downsize cells so they are slower
• Use higher-threshold-voltage cells on the path

Fix setup first, hold second. Hold fixes add delay, and if you fix hold before setup is stable you will redo the work.

The question behind the question

When an interviewer hands you a report they are rarely testing recall. They want to see whether you can locate the slack, trace where the time went, and propose a fix with a reason attached. Practise narrating a report out loud — “this path fails setup by 120 picoseconds, most of the delay is in these four logic levels, so I would restructure before I start upsizing” — and the question stops being frightening.