Static Timing Interview Questions

Setup says data launched at one edge must arrive a setup time before the next capture edge. So it compares the slowest path with the period. Hold says new data from the same edge must not race through and corrupt what the capture flop is sampling. So it compares the fastest path with the hold time. Both launch and capture happen on the same edge in the hold check, so the period cancels. Skew enters both, with opposite signs.

At one clock edge the launch flop sends new data and the capture flop samples old data. Hold asks whether the new data reaches the capture flop before its hold window around that same edge closes. Both events come from the same edge, so the period is not in the inequality at all. Setup is different: it compares this edge with the next one.

Yes, because hold does not depend on the period. A setup failure goes away at a lower frequency. A hold failure stays at any frequency. It needs a fix to the short path or the skew.

Positive skew, capture later than launch, gives setup that much more time and takes the same amount from hold. In lesson L2.4 each extra buffer in front of the capture flop's clock raised setup slack by about 0.073 ns. Hold slack fell by the same amount, until hold failed at the fifth buffer.

Setup is usually worst where cells are slowest: a slow process at low voltage. Hold is usually worst where they are fastest: a fast process at high voltage. In the lesson's small clock tree the fast cold corner had the smallest hold slack, 0.2397 ns, and the slow corners failed setup. Skew and wire delays do not scale like cell delays, so sign-off still runs both checks at every corner.

Start from the full matrix, and drop a view only with evidence that another view always dominates it. Get that evidence by running everything once on an early netlist, for example. Keep every view that is worst for some endpoint group in any check. Optimise on a small set of dominant views, but run the full set at sign-off and after every late change.

The bigger buffer drives its 17 loads faster, so the shortest path got shorter. The capture clock is still seven buffers late. Hold lost what setup gained. Fix hold by adding delay on the short path near the capture flop, or by reducing the skew. Never fix it by touching the period. Here a smaller buf_2 meets both checks, so pick the smallest drive that closes setup rather than the biggest.

Hold slack depends on the real launch and capture latencies, and before CTS the clock is ideal, with zero skew. Repairing earlier would add delay for skew that may never appear and miss the skew that does. In lesson L5.5 no endpoint failed hold with ideal clocks, while 45 failed after CTS.

A delay cell is built to be slow. In sky130, dlygate4sd3_1 gives about 0.53 ns for 10 µm², while buf_1 gives about 0.08 ns for 3.75 µm². So one delay cell replaces several buffers at far less area per nanosecond. Buffers suit small fixes and are easier to resize later.

Repair against all required corners at once. Then the tool sees the setup cost at the slow corner when it inserts delay at the fast one. Prefer delay on paths with setup slack to spare at every corner. Fix shared skew in the clock tree before adding cells. A repair that must break setup to fix hold shows the constraints or the clock tree need work, not more cells.

The shared net also feeds long paths, and they slow down by the same delay. With tight setup at the slow corner, those paths now fail. Put the delay near each failing D pin instead, where only the short path passes. Then check setup at every corner again.

Placement added wire capacitance, which the driving cells now charge, so the same cells got slower. Try the cheap moves first: timing-driven placement, resizing the drivers and swapping to faster input pins. Also buffer long or heavily loaded nets, and clone high-fanout drivers. In lesson L4.5 timing-driven placement alone turned -0.1371 ns into +0.2145 ns. A path that no tool can fix goes back to the RTL for retiming or pipelining.

The driving cell has to charge the wire's capacitance through its own output resistance, which is far larger than the wire's resistance. In lesson L4.5, 100 µm of met1 adds about 17 fF and 121 Ω, and an inv_1 driving it slows from 0.044 to 0.143 ns. The wire's own RC delay grows with length squared and only dominates on long nets.

Timing-driven placement re-weights the nets on critical paths while cells are still moving, so the fix costs little area. repair_timing works on fixed positions by resizing, buffering, swapping pins and cloning, which adds cells and needs another legalization. In lesson L4.5 the repair alone reached +0.056 ns while timing-driven placement reached +0.2145 ns on the same block.

Past the library's max transition or max capacitance, the delay tables are extrapolated. So the slack is a number the library never measured. Repair the design rules first, with buffer trees and stronger drivers, then trust the timing. In lesson L4.4 repair_design added six buffers and took 123 slew violations to zero.

Stop spending flow iterations on it. Take it to the RTL owner with the evidence: the path, its logic depth and the best slack each fix reached. The structural options are pipelining, retiming, or restructuring the logic, each with a cost in latency or verification. Agree on it early, because an RTL change late in the schedule restarts synthesis, equivalence and the flow.

Pipelining adds a register stage, so latency grows by a cycle. Every interface, model and test that counts cycles must change. Retiming moves existing registers and keeps the latency at the ports. But the internal flops no longer match the RTL, so equivalence needs a sequential check.

The launch half sums the clock edge, the launch clock latency and every cell and net delay to the data arrival, 0.3055 ns. The capture half starts at the next edge, 1.0 ns. It adds the capture clock's path through five buffers to reach 1.3818. Then it subtracts the library setup time, 0.1029, to give the required time 1.2789. Slack is required minus arrival: 0.9734 ns, met.

With on-chip-variation derates, the launch clock is timed late and the capture clock early. Where the two clock paths share buffers, one buffer cannot be both. So the tool credits back the difference on the shared part. With no derates and a single corner, late equals early and the credit is zero. In lesson L2.9, ±5 % derates gave a credit of 0.0138 ns.

WNS is the worst endpoint's slack and says how hard the hardest path is. TNS sums the negative slacks and the failing count says how widespread the problem is. A WNS of -50 ps on two endpoints is a local fix. The same WNS on two thousand endpoints is a floorplan or constraint problem.

No: nothing was timed. The clock was declared on a port called clock, which does not exist. So no flop is clocked and no path has a constraint. Read every warning after loading the SDC and run check_setup, which lists unclocked registers and unconstrained endpoints. With the port name corrected, the same netlist reports a real slack of 3.837 ns.

It lists what the constraints leave out: unclocked register pins, inputs without input delays and outputs without output delays. It also lists unconstrained endpoints and combinational loops. In lesson L2.5 a partial SDC left two inputs and all twenty outputs without delays, so twenty endpoints were never timed. Each item is either fixed or explained before any slack counts.

Every path from every input, including the clock-domain data inputs that really do need timing. In lesson L2.8 that line turned two flop data pins into unconstrained endpoints. A report through the data input then found no paths at all. Writing the exception on the one port, -from [get_ports cfg], left the other path timed with 0.5837 ns of slack.

Then the reset release has no recovery or removal check. A release near the clock edge can leave some flops in reset for one cycle longer than others. The design then starts in a mixed state. Time the release through its synchroniser, and keep recovery and removal checked.

Check coverage first: every register clocked, every port with a delay, zero unexplained unconstrained endpoints. Then review every exception against a written reason, since a false path or clock group trusted by STA removes checks for good. Compare the clock relationships with the design spec and the CDC report. Re-run the audit whenever the SDC or the netlist changes.

The hold check moved too. Hold is checked one edge before the setup capture edge. So moving setup to the second edge moves hold to the first, a full period later than intended. Now hold fails. Pair -setup 2 with -hold 1 to put hold back at the launch edge. Then prove in simulation that the data really is stable for two cycles, because STA trusts the exception.

The tool defines the hold check relative to the setup relationship. One capture edge earlier, it checks that the next launch does not overwrite what the setup capture edge should catch. Move setup to edge two and that earlier edge becomes edge one. -hold 1 pulls the hold check back by one cycle to the launch edge.

A false path removes paths from timing entirely. It is for signals that can never propagate in one cycle in practice, such as static configuration written before use. A multicycle path keeps the check but gives it N cycles, for data that is guaranteed stable for N cycles. A false path is the riskier promise, because a wrong one hides a real path forever; never false-path a reset release.

Then the false path is no longer true. The new value can reach a capture flop in any cycle, untimed. Some bits may then be caught a cycle late or go metastable. Either forbid writes while the block runs, and check that rule with an assertion. Or time the path for real.

STA still gives the path two cycles and reports it clean, while the silicon now captures every cycle and fails. The exception is a promise only the design can keep, so the check belongs in verification. The check is an assertion that the enable alternates and the source is stable at every capture edge. Rerunning that assertion after every ECO catches the broken promise.

set_clock_groups -asynchronous acts as false paths between the two clocks. In SDC precedence a false path outranks set_max_delay, so the pointer bound is dropped (confirmed on OpenSTA 3.1.0). So the Gray-pointer skew is never bounded. Use path-level exceptions instead: a false path on the data that is safe by protocol. Add a max delay, with clock latency ignored, on each pointer bit. Keep the synchroniser flops under normal same-clock timing.

Without an exception, STA treats the clocks as related. It finds the tightest launch-capture pair over their 70 ns common period. That is launch at 20 ns and capture at 21 ns, only 1 ns apart. The memory-to-read path cannot meet 1 ns, so it fails. Real asynchronous clocks have no fixed phase, so the check is meaningless and must be replaced by the right exceptions.

On-chip variation means two identical cells on one die are not equally fast. For setup, the tool slows the launch clock and data path and speeds up the capture clock. It does the reverse for hold. On the clock buffers both paths share, that would count one buffer as fast and slow at once. So CPPR credits the difference back. In lesson L2.9, ±5 % derates cost about 0.025 ns of setup and returned 0.0138 ns as CPPR.

A flat derate applies the same percentage to every cell. That is pessimistic on deep paths, where random variation partly cancels, and can be optimistic on short ones. Depth- and distance-aware tables scale the derate with the number of stages and the spread of the path. Statistical models carry a sigma per cell arc and combine them along the path. All of them need data from the library; the method is only as good as that data.

A corner is one process, voltage and temperature, with its own library. A mode is one set of constraints, such as functional or test. Sign-off times every required mode at every corner where some check could be worst: slow corners for setup, fast for hold. Both temperatures are needed, because which one is slower depends on the process. In the lesson the cold slow corner was worse than the hot one.

Temperature moves two things in opposite directions. Carrier mobility falls as it gets hotter, which slows cells. The threshold voltage also falls, which speeds them up. At low supply voltage, where the overdrive above threshold is small, the threshold effect can win, so cells are slower when cold. That is why the corner list includes both temperatures and the result is measured per library.

Declare the clock, then set_input_delay 4 -clock clk on the data inputs and set_output_delay 1 -clock clk on the outputs. Add a -min value for hold on each side. Add set_driving_cell on the inputs and set_load on the outputs, so the port nets have real delay and slew. Then run check_setup to see that no port is left untimed.

The output delay models the receiving flop outside the block. For hold, the receiver needs the data to stay stable for its hold time after the edge. That shows up as a negative minimum output delay. In lesson L2.7 a min output delay of -0.2 ns made the output hold check require 0.2 ns, met with 0.2121 ns of slack.

Declare it with create_generated_clock -source on the master clock pin and -divide_by 2 at the divider's output. Then the tool keeps its phase relation to the master. With only the master clock, check_setup reports the divided flops as unclocked. A plain create_clock on the divider output would lose the divider's latency, which the lesson measured as 0 instead of 0.3425 ns.

A virtual clock has no source pin in the block; it stands for the clock at the external device. Referenced to the real clock, I/O paths shift when CTS makes that clock propagated, by about the insertion delay. A virtual clock with an agreed source latency keeps the external timing fixed. So the I/O budget means the same before and after CTS.

After CTS the capture flop sees the clock later, by the insertion delay. The input delay is still counted from the edge at the clock port. So the data has extra time for setup, and hold gets harder by about the same amount. Outputs move the other way.