Engineering Lab

Debug real chip problems

Real violations, real tool reports. Diagnose the cause, choose the fix, verify the result.

STA · SetupCase 01

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.

Observe · EDA 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

Diagnose

The 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.

Choose the fix

You 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.

Result · After restructure + useful skew
WNS − 0.143 ns → + 0.021 ns
TakeawaySetup = data arrives too late. Shorten the path — never add delay.Go deeper →
STA · HoldCase 02

326 hold violations appear after routing

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

Observe · EDA report

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

Diagnose

Hundreds 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.

Choose the fix

What 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.

Result · 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 · RoutingCase 03

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.

Observe · EDA report

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

Diagnose

M3/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.

Choose the fix

How 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.

Result · After padding + density screen + re-place
overflow 18.4 % → 0.7 %, route converges
TakeawayCongestion is a placement problem. Manage local density before you route.Go deeper →
PD · CTSCase 04

CTS leaves 87 ps of clock skew

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

Observe · EDA report

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

Diagnose

The 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.

Choose the fix

How 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.

Result · After CTS rebalance
global 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.