Lab: Timing path lab
The idea
So far, we have assumed that the clock reaches every flop at the same instant. Real clocks don't, and this changes both timing checks.
Skew
Skew is the difference in arrival time between the launch flop and capture flop. Define it as capture arrival minus launch arrival.
Setup: Tclk + Tskew >= Tcq + Tcomb + TsetupHold: Tcq + Tcomb >= Thold + Tskew
Positive skew (capture clock arrives late) gives setup more time and makes hold harder. Negative skew does the opposite. It's the same number with opposite effects on the two checks.
Worked example
Using Tcq = 0.3, Tcomb = 2.2, Tsetup = 0.5, and Tclk = 2.9 ns, the setup is -0.1 ns. Add 0.2 ns of positive skew, and the slack becomes +0.1 ns. If Thold = 0.1 and the path has Tcomb = 0, hold slack goes from 0.3 - 0.1 = +0.2 ns to 0.3 - 0.1 - 0.2 = 0 ns. Some designers deliberately add delay this way, which is called useful skew. The next path, however, loses what this path gains.
Jitter
Jitter is variation in the clock edge timing from cycle to cycle, caused by things like PLL noise and supply noise. It can't be planned around, so we subtract it from setup margin. Since hold compares launch and capture at the same edge, cycle-to-cycle jitter has little effect there.
Uncertainty
Timing tools combine jitter and margin into one number, set by set_clock_uncertainty:
create_clock -name clk -period 2.0 [get_ports clk]
set_clock_uncertainty 0.1 [get_clocks clk]Where skew comes from
Clock tree synthesis balances wire and buffer delays across the chip, but it can never be perfect. Local variation means that two identical paths still differ. Tools account for this using on-chip variation margins.
Common mistake
Getting the sign wrong. Picture it rather than memorising it: the capture clock arriving later gives data more time to arrive (setup improves), and it also keeps the capture flop looking for longer, so new data can sneak in (hold gets worse).
Key ideas
- Useful skew helps setup on one path and hurts the next.
- Positive skew hurts hold.
- Jitter reduces setup margin.
Your exercise
Interview questions
corePositive skew's effect on setup and hold?
Setup gains margin, hold loses it (capture clock arrives later).
basicWhat is the difference between clock skew and clock jitter?
Skew is a difference in when the same clock edge arrives at two flops, caused mainly by different wire and buffer delays in the clock tree. It is largely fixed and can be analysed path by path. Jitter is variation in the timing of the edges themselves from cycle to cycle, caused by things like PLL noise and supply noise. It can't be planned around, so it is subtracted from the setup margin.
basicTclk = 2.0 ns, Tcq = 0.2 ns, Tcomb = 1.6 ns and Tsetup = 0.2 ns. What is the setup slack with no skew, and with 0.1 ns of positive skew (capture clock late)?
With no skew: 2.0 - (0.2 + 1.6 + 0.2) = 0 ns, which just passes. With +0.1 ns of skew, the capture edge comes later, so the budget is 2.0 + 0.1 = 2.1 ns, and the slack is +0.1 ns. Positive skew helps setup on this path.
coreTcq = 0.2 ns, Tcomb = 0.1 ns, Thold = 0.1 ns. What is the hold slack with no skew, and with 0.25 ns of positive skew?
Hold requires Tcq + Tcomb >= Thold + Tskew. With no skew: 0.3 - 0.1 = +0.2 ns. With +0.25 ns: 0.3 - 0.1 - 0.25 = -0.05 ns, a violation. The late capture clock keeps the capture flop sampling for longer, so the new data from the same edge can reach it too soon.
corePath A to B has -0.15 ns setup slack, and path B to C has +0.3 ns. How could useful skew fix this, and what do you have to recheck?
Delay the clock at flop B by 0.15 ns. Path A to B gains 0.15 ns, bringing its slack to 0. Path B to C loses 0.15 ns, because its launch is now later, leaving +0.15 ns. Then recheck hold: A to B has lost 0.15 ns of hold margin, while B to C has gained some. Useful skew only moves time between neighbouring paths, it never creates it.
coreWhy does cycle-to-cycle jitter reduce setup margin but hardly affect hold?
Setup compares two different edges, the launch edge and the next one, so if a cycle comes out shorter because of jitter, the data has less time. Hold compares the launch and capture at the same edge, so that edge's random offset affects both ends of the path alike and largely cancels out. That is why jitter, through clock uncertainty, is mainly charged against setup.
coreA 2.0 ns clock has 0.1 ns of clock uncertainty set in constraints. A path needs Tcq + Tcomb + Tsetup = 1.95 ns. Does it pass?
No. The uncertainty is taken from the setup budget: 2.0 - 0.1 = 1.9 ns available, against 1.95 ns needed, so the slack is -0.05 ns. Without the uncertainty it would pass with +0.05 ns. The uncertainty covers jitter and other margin that isn't modelled elsewhere.
advancedIn a long shift register with no logic between flops, the clock tree happens to deliver the clock later to each successive flop. Why is this risky?
Each hop has positive skew, since the capture flop is clocked later than the launch flop. With no logic between flops, the data path is only Tcq, so hold can fail once the skew exceeds Tcq - Thold. Setup, by contrast, has almost a full period of spare time. Shift registers and other short flop-to-flop paths are therefore typically hold-critical, and they often need hold buffers.
advancedFor a flop-to-flop path with no logic, Tcq = 0.12 ns and Thold = 0.05 ns. What is the largest positive skew the path can tolerate?
Hold requires Tcq + Tcomb >= Thold + Tskew. With Tcomb = 0, that is 0.12 >= 0.05 + Tskew, so Tskew must be at most 0.07 ns. Any more skew than that and the hold check fails at every frequency, so the fix is to add delay to the data path, not to slow the clock.