Engineering Lab

Debug real chip problems

Reading about timing closure is not the same as doing it. The Lab drops you into real violations — a failing setup path, hundreds of hold errors, a congestion hotspot, clock skew — with the actual tool reports. Diagnose the cause. Pick the fix. See what happens.

Setuppath that fails setup by 143 ps Hold326 hold violations appear after routing Routingrouter reports 18.4% overflow CTSCTS leaves 87 ps of clock skew

STA · Setup

A path that fails setup by 143 ps

First route is done. Timing signoff flags one critical path in the max (setup) group. Here is the report.

report_timing.rpt · primetime

Startpoint: u_alu/acc_reg[7]  (rising, clk)
Endpoint:   u_ctrl/state_reg[2] (rising, clk)
Path Group: clk    Path Type: max (setup)
 
  logic levels on path .............. 18
  data arrival time ............... 2.143
  clock period .................... 2.000
  clock uncertainty ............. − 0.050
  library setup time ............ − 0.060
  data required time .............. 1.890
  ────────────────────────────────────────
  slack (VIOLATED) .............. − 0.143

01The path misses setup by 143 ps. What is the dominant cause?

Show the analysis

Data arrives at 2.143 ns but only 1.890 ns is available, and the path is 18 logic levels deep. A large negative setup slack with normal skew and uncertainty is a long-path problem — the logic cone cannot settle inside one clock period.

02You need to claw back ~143 ps. What is the right first move?

Show the analysis

Setup is fixed by making data arrive earlier: reduce logic depth (retiming / restructuring), upsize the critical drivers, or borrow time with useful skew. Adding buffers adds delay and makes setup worse; loosening uncertainty just hides the violation instead of closing it.

✓After restructure + useful skewWNS − 0.143 ns → + 0.021 ns

TakeawaySetup = data arrives too late. Shorten the path — never add delay.Go deeper →

STA · Hold

326 hold violations appear after routing

Setup is clean, but the min (hold) group lights up with hundreds of failing endpoints across short paths.

report_timing -delay_type min · primetime

Path Group: clk    Path Type: min (hold)
 
  data required time .............. 0.270
  data arrival time ............... 0.212
  ────────────────────────────────────────
  slack (VIOLATED) .............. − 0.058
 
  failing endpoints ................... 326

01Hundreds of hold failures on short paths. What is happening?

Show the analysis

Hold is a min-delay (short-path) check: the new data must not reach the capture flop too early, before the previous value is safely latched. Here arrival (0.212) is earlier than required (0.270), so data races through — classic post-route hold, independent of clock period.

02What is the standard fix for a hold violation?

Show the analysis

Hold is fixed by adding delay to the data path — delay cells / buffers on the failing short paths, usually as an automated hold ECO. Watch that the added delay does not eat setup margin on the same path. Everything that fixes setup (going faster) makes hold worse, and vice-versa.

✓After hold-fix ECO (delay cells)326 failing → 0 failing, hold slack + 0.006 ns

TakeawayHold = data arrives too early. Add delay — the mirror image of setup.Go deeper →

PD · Routing

The router reports 18.4% overflow

Global route will not converge. One region of the core is drawing far more routing demand than the tracks can supply.

report_congestion · innovus

Global route: OVERFLOW
 
  total overflow .................. 18.4 %
  hotspot region ..... (240,180)-(310,240)
  layers over capacity ......... M3, M4
  cell density in region .......... 0.92

01M3/M4 demand exceeds capacity in one dense region. Root cause?

Show the analysis

Congestion is a placement problem that surfaces at routing. A local density of 0.92 means the region is nearly full of cells, so their pins and local nets demand more routing tracks than M3/M4 can provide. The fix belongs upstream, in placement — not in the router.

02How do you relieve the hotspot?

Show the analysis

Lower the local demand: add cell padding or a partial placement blockage over the hotspot, cap density with a screen, and re-place so the cells fan out. That trades a little area for a routable design. Timing and clocking knobs do nothing for a routing-supply problem.

✓After padding + density screen + re-placeoverflow 18.4 % → 0.7 %, route converges

TakeawayCongestion is a placement problem. Manage local density before you route.Go deeper →

PD · CTS

CTS leaves 87 ps of clock skew

The clock tree is built, but the clock reaches different flops at noticeably different times.

report_clock_timing -skew · icc2

Clock: clk
 
  global skew ..................... 87 ps
  longest insertion delay ........ 312 ps  (u_mem)
  shortest insertion delay ....... 225 ps  (u_alu)
  clock tree buffers ................. 214

01The report shows 87 ps of global skew. What does that mean?

Show the analysis

Skew is the difference in clock arrival between endpoints — here 312 ps to u_mem versus 225 ps to u_alu, an 87 ps spread. It comes from unequal insertion delay across the tree, and it eats directly into both setup and hold margins.

02How should CTS handle this?

Show the analysis

Balance the insertion delays so every sink sees the clock at nearly the same time (buffer sizing, level balancing, NDR on long branches). Skew is not purely an enemy: once balanced, you can push a little useful skew onto specific launch/capture pairs to buy setup or hold margin deliberately.

✓After CTS rebalanceglobal skew 87 ps → 11 ps

TakeawaySkew is tree imbalance. Balance it first — then exploit useful skew on purpose.Go deeper →

These are the questions interviews actually ask

Every case here is a scenario you will meet on the job and in interviews. Work through the full timing and physical-design paths to build the reasoning behind each fix.

Master STA 128 STA interview questions