Interview Question · Debug
A Slow Reset Net After Placement
The Question
The interviewer asks
After placement, the design-rule report below flags the reset net. What is wrong, and how is it fixed without hurting the reset timing?
MAC, buf_1 driving every input but clk (lesson L4.4, measured)
rst_n -> RESET_B arrival 1.4789 ns slew 2.1688 ns (max_transition 1.5 ns)
after global placement: slew violations 123 cap violations 2
after repair_design: slew violations 0 cap violations 0 (6 buffers added)You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
One small driver feeds 52 reset pins plus the wire. So its edge is far slower than the library allows, and its delay is extrapolated. Repair the design rules first: a buffer tree splits the load and stronger drivers sharpen the edge. Reset is not a clock and needs no skew balancing. But its release is still timed by recovery and removal checks. So re-check those after the tree is built.
- The port sees two pins
The weak driver now loads only two buffer inputs and the wire to them.
- Each buffer sees its group
Each buffer sits near its flops, so its wire is short and its load is within its limit.
Read the diagram as text
- rst_n port: Driven by a weak cell
- Buffer: Near the first group
- Buffer: Near the second group
- Flops, group 1: RESET_B pins
- Flops, group 2: RESET_B pins
- rst_n port → Buffer
- rst_n port → Buffer
- Buffer → Flops, group 1
- Buffer → Flops, group 2
The shape only; repair_design chooses the number of buffers, their cells and their places.
buf_1.rst_n → _790_recovery check, latest arrival0 cells
- Clock latency
- Cell delay
- Recovery time
- A slow release
The
buf_1driving the port needs 1.4789 ns to move 188.864 fF of RESET_B pins. - The slew
The edge arrives with a 2.1688 ns slew. Every flop's recovery check reads its tables far outside their range.
- Slack met with extrapolated recovery
The recovery slack is 2.7670 ns, but it rests on extrapolated tables.
Read the path as a table
Launch: clk rise edge at 0.0000 ns, clock latency 0.0000 ns (ideal). Capture: clk rise edge at 4.6000 ns, latency 0.0000 ns, library recovery time −0.3541 ns.
Arrival 1.4789 ns, required 4.2459 ns, slack 2.7670 ns (met).
| Cell | Arc | Through | Edge | Delay (ns) | Time (ns) | Slew (ns) |
|---|---|---|---|---|---|---|
rst_n → _790_/RESET_B | wire rst_n | rise | 0.0000 | 1.4789 | 2.1688 |
The report
Startpoint: rst_n (input port clocked by clk)
Endpoint: _790_ (recovery check against rising-edge clock clk)
Path Group: asynchronous
Path Type: max
Fanout Cap Slew Delay Time Description
-------------------------------------------------------------------------------------
0.0000 0.0000 0.0000 clock clk (rise edge)
0.0000 0.0000 clock network delay (ideal)
0.0000 0.0000 ^ input external delay
52 0.1889 2.1688 1.4789 1.4789 ^ rst_n (in)
rst_n (net)
2.1688 0.0000 1.4789 ^ _790_/RESET_B (sky130_fd_sc_hd__dfrtp_1)
1.4789 data arrival time
0.0000 4.6000 4.6000 clock clk (rise edge)
0.0000 4.6000 clock network delay (ideal)
0.0000 4.6000 clock reconvergence pessimism
4.6000 ^ _790_/CLK (sky130_fd_sc_hd__dfrtp_1)
-0.3541 4.2459 library recovery time
4.2459 data required time
-------------------------------------------------------------------------------------
4.2459 data required time
-1.4789 data arrival time
-------------------------------------------------------------------------------------
2.7670 slack (MET)Lesson L4.4's MAC before repair: the reset release path from rst_n, timed with no wires yet.
Self-Check
Tick each key point you covered in your answer.
What Interviewers Listen For (Junior)
A good junior answer spots a max-transition violation, an edge slower than the library allows, on a net with a large fanout. It suggests a buffer tree as the fix.
What Interviewers Listen For (Senior)
A good senior answer explains why a delay beyond the library table cannot be trusted. It keeps the recovery and removal checks in view after the repair. It plans the reset and enable trees before placement.
Cross-Questions
Where the interviewer goes next. Open a node to practise that follow-up.
WhyWhat IfProve ItBreak ItCompare
- A Slow Reset Net After Placement
-
WhyDelays Past the End of the TableL1 JuniorL2 Mid-Level
Why can you not trust the delay of a cell driving beyond its maximum capacitance?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
The Liberty tables stop at the characterised loads and slews, and beyond them the timer extrapolates in a straight line. In lesson L2.2 an
inv_1at 0.25 pF, well past its 0.18 pF limit, still got a printed delay of 0.8558 ns, which nobody measured. The design-rule report is what flags it.Measured sweepinv_1 Falling Delay Against Load, One Curve per Input SlewEvery point is a delay OpenSTA reported. The load axis is logarithmic, like the table's own index. Whole plot- input slew 0.01 ns
- input slew 0.0388 ns
- input slew 0.28 ns
- input slew 1.5 ns
- Load 2.254 fFinput slew 0.01 ns = 20.7 ps · input slew 0.0388 ns = 30.3 ps · input slew 0.28 ns = 65.3 ps · input slew 1.5 ns = 83.7 ps
The worked lookup: 2.254 fF at a 0.0388 ns slew gives 0.0303 ns.
- Load 100 fFinput slew 0.01 ns = 346.4 ps · input slew 0.0388 ns = 357.2 ps · input slew 0.28 ns = 451.5 ps · input slew 1.5 ns = 853.2 ps
At 100 fF the fast input gives 0.3464 ns and the 1.5 ns input gives 0.8532 ns. The 1.5 ns input is slower than the 0.01 ns one at every load.
- Load 250 fFinput slew 0.01 ns = 845.4 ps · input slew 0.0388 ns = 855.8 ps · input slew 0.28 ns = 952.3 ps · input slew 1.5 ns = 1.496 ns
At 0.25 pF the load is past the table's last column, 0.1813 pF. The tool extrapolates the last two columns in a straight line: 0.8558 ns.
Read the plot as a table
Load input slew 0.01 ns input slew 0.0388 ns input slew 0.28 ns input slew 1.5 ns 1 fF 16.2 ps 24.9 ps 50.1 ps 48.1 ps 2.254 fF 20.7 ps 30.3 ps 65.3 ps 83.7 ps 10 fF 47.1 ps 57.7 ps 126.9 ps 233.4 ps 100 fF 346.4 ps 357.2 ps 451.5 ps 853.2 ps 250 fF 845.4 ps 855.8 ps 952.3 ps 1.496 ns Measured
inv_1delays. Past the max_capacitance mark, the timer only extends the last two table points in a straight line.Self-Check
Tick each key point you covered in your answer.
-
CompareBuffering vs Resizing a Weak DriverL1 JuniorL2 Mid-Level
Compare buffering a high-fanout net with resizing its driver.
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Resizing swaps in a stronger driver, which is cheap and keeps the topology. But it loads the cell in front of it and cannot help a net that is simply too long. Buffering splits the loads into a tree, so each driver sees a manageable load. The cost is extra cells and delay stages. Repair tools try both and use placement to estimate the wires.
Self-Check
Tick each key point you covered in your answer.
-
Prove ItSolve L4.4.1: Repair the Slow Reset TreeSimulator-graded
Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
-
Break ItA Removal Failure on a Reset ReleaseL1 JuniorL2 Mid-Level
Asked if they say reset timing does not matter
A reset synchroniser's output drives a flop's asynchronous reset. The removal check below fails by 10 ps. What does that mean, and how do you fix it?
log dfxtp_1 Q -> dfrtp_1 RESET_B, ideal 1 ns clock (lesson L2.1, measured) reset release arrives 0.3259 ns after the edge removal time 0.3364 ns removal slack -0.0105 ns (recovery slack 0.9202 ns)2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Removal is the hold check of a reset release. The release must not come too soon after the clock edge. Otherwise the flop sees reset and clock at nearly the same time. Here the release arrives 0.3259 ns after the edge but the flop needs 0.3364 ns, so it is 10 ps early. Slow the release path slightly, or reduce the skew between the synchroniser and the flop, exactly as for hold.
Timing pathA Reset Synchronizer That Fails RemovalFlop fr (dfxtp_1) releases the reset of flop ff (dfrtp_1) on the same clock. Whole pathfr → ffremoval check, earliest arrival1 cell
- Clock latency
- Cell delay
- Removal time
- The release
Flop fr's Q rises 0.3259 ns after the clock edge, releasing ff.
- The removal time
ff needs the release no sooner than 0.3364 ns after that same edge.
- Too soon
Removal slack -0.0105 ns: the flop may leave reset at this edge or the next.
Read the path as a table
Launch: clk rise edge at 0.0000 ns, clock latency 0.0000 ns (ideal). Capture: clk rise edge at 0.0000 ns, latency 0.0000 ns, library removal time 0.3364 ns.
Arrival 0.3259 ns, required 0.3364 ns, slack −0.0105 ns (violated).
Cell Arc Through Edge Delay (ns) Time (ns) Slew (ns) 1 fr/CLK→fr/Qdfxtp_1 rise 0.3259 0.3259 0.0492 fr/Q→ff/RESET_Bwire r1 rise 0.0000 0.3259 0.0492 The report
Startpoint: fr (rising edge-triggered flip-flop clocked by clk) Endpoint: ff (removal check against rising-edge clock clk) Path Group: asynchronous Path Type: min Fanout Cap Slew Delay Time Description ------------------------------------------------------------------------------------- 0.1000 0.0000 0.0000 clock clk (rise edge) 0.0000 0.0000 clock network delay (ideal) 0.1000 0.0000 0.0000 ^ fr/CLK (sky130_fd_sc_hd__dfxtp_1) 1 0.0036 0.0492 0.3259 0.3259 ^ fr/Q (sky130_fd_sc_hd__dfxtp_1) r1 (net) 0.0492 0.0000 0.3259 ^ ff/RESET_B (sky130_fd_sc_hd__dfrtp_1) 0.3259 data arrival time 0.1000 0.0000 0.0000 clock clk (rise edge) 0.0000 0.0000 clock network delay (ideal) 0.0000 0.0000 clock reconvergence pessimism 0.0000 ^ ff/CLK (sky130_fd_sc_hd__dfrtp_1) 0.3364 0.3364 library removal time 0.3364 data required time ------------------------------------------------------------------------------------- 0.3364 data required time -0.3259 data arrival time ------------------------------------------------------------------------------------- -0.0105 slack (VIOLATED)The removal check from this question, drawn as two lanes: the release arrives 10 ps too early.
Self-Check
Tick each key point you covered in your answer.
-
What IfRechecking Reset After BufferingL1 JuniorL2 Mid-Level
What if the reset net is buffered after the removal check was fixed?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
The buffer tree adds delay and skew on the release path at every flop. Removal may then pass with margin while recovery, the setup-like check, starts to fail. So re-run both checks after every reset repair, at all corners.
Self-Check
Tick each key point you covered in your answer.
Missed Corner
"Removal passed before buffering, so the reset is done."
Buffering changes the release arrival at every flop. Recovery and removal must be checked again on the repaired tree.
Source Lesson L4.4 key points
What People Get Wrong
Common wrong answers and why they fail.
Misconception
"Reset is asynchronous, so its timing does not matter."
Asserting reset is asynchronous, but releasing it near a clock edge can leave flops in different states. Recovery and removal checks time the release like setup and hold.
Source ASIC Point lesson L2.1 (recovery and removal arcs measured)
Wrong Altitude
"Build the reset tree with the clock tree tool so it is balanced."
Reset needs a timed release, not equal arrival everywhere. Balancing it wastes buffers and power; a design-rule buffer tree plus recovery and removal checks is enough.