Timing closure of an IIR loop at 125 MHz
A DSP block in a 28 nm ASIC runs at 125 MHz, giving an 8 ns period. The critical path is the multiply-accumulate loop of a first-order IIR filter, y[n] = a·y[n−1] + b·x[n]. Static timing at the slow corner gives flip-flop clock-to-Q 0.40 ns, combinational delay 8.60 ns and setup time 0.25 ns; at the fast corner the same combinational path is 1.20 ns. The capture clock arrives 0.35 ns later than the launch clock at both corners, and peak clock jitter is 0.20 ns. Hold time is 0.15 ns. There are no spare pipeline registers in the loop, and the filter output feeds a real-time control loop that cannot tolerate more than one extra sample of latency. The team proposes either adding a pipeline register in the middle of the multiply-add tree or reducing the clock to 100 MHz.
1. Compute the setup slack at 125 MHz and state whether the design closes timing.
Read the worked answer
Setup slack expression Slack = T + t_skew − t_cq − t_comb − t_setup − t_jitter
Substitution
- T = 8.00 ns
- t_skew = +0.35 ns (capture clock arrives later, which helps setup)
- t_cq = 0.40 ns
- t_comb = 8.60 ns
- t_setup = 0.25 ns
- t_jitter = 0.20 ns
Slack = 8.00 + 0.35 − 0.40 − 8.60 − 0.25 − 0.20 = −1.10 ns.
Conclusion The path fails setup by 1.10 ns at the slow corner. At 100 MHz the period becomes 10 ns and the same calculation gives +0.90 ns, so a frequency reduction closes timing but costs 20% of throughput. Because the control loop permits at most one extra sample of latency, any fix must be evaluated against that limit, not just against the timing number.
2. Check the hold condition at the fast corner and explain how a pipeline register could change it.
Read the worked answer
Hold slack Slack_hold = t_cq + t_comb,min − t_hold − t_skew = 0.40 + 1.20 − 0.15 − 0.35 = 1.10 ns.
Positive skew makes hold harder because the capture clock edge moves later; the path still passes with 1.10 ns margin.
Effect of pipelining
- If the pipeline register splits the path so the short segment becomes 0.50 ns, the new hold slack is 0.40 + 0.50 − 0.15 − 0.35 = 0.40 ns, still positive but much smaller.
- If the split leaves only 0.10 ns in the short segment, hold slack becomes 0.00 ns and the path becomes marginal under on-chip variation.
- A hold fix would then require delay buffers on the short path or useful skew, which consumes area and routing resources. This is why a pipeline register placed purely by delay splitting must be checked at the fast corner, not only at the slow corner.
3. Recommend a fix that respects the one-sample latency limit, and explain why naive pipelining inside the recursion is not a simple throughput improvement.
Read the worked answer
Why naive pipelining fails The recursion y[n] = a·y[n−1] + b·x[n] requires y[n−1] in the same clock cycle. Inserting a register into the feedback path changes the implemented difference equation, for example to a two-step recursion involving a², and therefore changes the filter response and the state seen by the control loop. The design no longer computes the intended filter.
Viable options
- Retiming inside the multiplier: move registers into the Booth/Wallace tree so the loop contains only the final adder, reducing the loop delay without changing the transfer function.
- Use a faster final adder: carry-save or a parallel-prefix adder can remove 1–2 ns from the loop.
- Scattered look-ahead: rewrite as y[n] = a²·y[n−2] + a·b·x[n−1] + b·x[n]. This places one register in the loop while preserving the transfer function, at the cost of an extra multiply and different round-off noise.
- Drop to 100 MHz if the control-loop bandwidth allows; one extra sample at 100 MHz is 10 ns, which is within the stated latency budget.
Recommendation Retime the multiplier first because it preserves both the sample rate and the transfer function. If that still leaves negative slack, use scattered look-ahead and verify the coefficient quantization and noise gain. Reducing the clock is the fallback, not the first choice.