Report Timing Deep Read: Worked Example

Worked example

Worked Example for Report Timing Deep Read focuses on incremental delay attribution accuracy, false debug rate. The goal is to connect the observable symptom to timing mechanism, ownership, and regression risk.

A signoff run shows incremental delay attribution accuracy, false debug rate. The first review mistake is to blame implementation without checking constraints. A better review starts by pinning one critical path, proving where slack was lost, and checking whether the SDC rule is correct for Report Timing Deep Read.

Sequence under inspection

TIMING PATH — Report Timing Deep Read

launch FF --logic stages--> capture FF
     |                           |
  launch clock                capture clock
     |                           |
  required: arrival < capture_edge - setup
  metric: incremental delay attribution accuracy, false debug rate

Critical path annotation

REPORT TIMING LINE (what to read)

 (rise) 0.12  U234/Z (AND2)     <- incremental delay
        0.45  net foo/bar       <- net delay + fanout
 (fall) 0.08  U567/D (DFF)      <- sense and edge matter
 clock: clk_main rise@500ps      <- launch/capture clocks

Read incremental delay, not just total slack.

1. Capture report_timing and the relevant SDC excerpt.

2. Tag corner, mode, view, and path group.

3. Find the first cell or net that dominates critical delay.

4. Compare against annotated timing report, path viewer screenshot, constraint trace.

5. Choose one reversible ECO and write the regression matrix before editing netlist or constraints.

Did the fix work?

BEFORE / AFTER ECO — Report Timing Deep Read

WNS (ps)
  0 |                    --- target
-50 |    ● regressed
-80 |         ● before ECO
-20 |              ● after ECO
    +-------------------------------> ECO iteration
Prove setup AND hold moved safely.

STA deep dive

Slack is a path story — read the graph, not just the number.

Concept diagram

TIMING GRAPH

FF --cell-- logic --net-- logic --cell-- FF
launch                              capture

Metric graph

SLACK TAIL

paths |    ***
      |  *******
      |*********  <- fix WNS first

Reports and artifacts

• WNS/TNS

• path slack histogram

• cell vs net %

• path group summary

Mini case study

WNS -90ps but 80% net delay on one congested route — PD route fix beat upsizing three cells.

Debug branches

• Cell-heavy -> sizing/VT

• Net-heavy -> route/layer

• Check launch/capture clocks

Senior review question

Ask: what corner/mode/view proves this topic is closed or failing?

Key takeaways

• State corner, mode, view, and database tag with every slack claim.

• Run setup and hold plus MMMC regression after every ECO.

Common pitfalls

• Comparing STA runs with different SPEF or SDC tags.

• Broad false_path to green-wash violations.

• Setup-only ECO without hold check.

Principal STA review addendum

Senior STA debug reads incremental delay, sense, edge, clock domain, and exception flags on the critical path — not just slack number.

Metric: incremental delay attribution accuracy, false debug rate