Max Frequency Calculation: Setup, Hold and Board Timing Budgets

The maximum clock frequency of a synchronous path is set by its slowest register-to-register delay. In the simplest form, flip-flop FF1 launches data, it passes through combinational logic and is captured by FF2, so the minimum clock period is Tclk2q(FF1) + Tcomb + Tsu(FF2), plus any clock skew and jitter that eat into the cycle. Fmax is one over that period. Hold time is a separate check on the fastest path, and it does not improve when you slow the clock.

This post works through both checks, first inside a chip and then on a board, using a memory controller talking to a DDR SRAM, and shows why trace delay, skew and jitter can cap the frequency even when the silicon on both ends is fast.

Key takeaways

• Setup (maximum frequency): Tclk2q(max) + Tcomb(max) + Tsu + skew + jitter must fit in one clock period (half a period for a double-data-rate interface).
• Hold: Tclk2q(min) + Tcomb(min) must be longer than the hold time plus any skew that delays the capture clock. Hold is independent of frequency.
• The critical path decides Fmax. Good synthesis and STA constraints (clock period, uncertainty, input and output delays) are how you find and fix it.
• On a board, trace delay (roughly 140 to 180 ps per inch on FR4) is part of the budget. In the worked example it helps hold and hurts setup.
• Source-synchronous clocking, where the clock travels with the data, removes most of the trace delay and generator skew from the budget.

The simplest form: one register-to-register path

Physically the path looks like this for our purposes:

FF1 > combinational logic > FF2

FF1 launches new data on a clock edge. The data needs Tclk2q to appear at FF1's output, Tcomb to ripple through the logic, and must then arrive Tsu before the next clock edge at FF2. So:

Tmin = Tclk2q(FF1) + Tcomb + Tsu(FF2)
Fmax = 1 / Tmin

Fmax is mainly decided by the critical path, the slowest such path in the design, and you can do a good job of meeting it by defining proper timing constraints during synthesis.

Adding skew and jitter

Real clocks do not arrive at FF1 and FF2 at the same instant, and each edge wanders a little. Define skew as capture clock arrival minus launch clock arrival. Then the setup check becomes:

Tclk2q(max) + Tcomb(max) + Tsu <= Tperiod + skew - jitter

Positive skew (the capture clock arrives late) gives the data more time. Negative skew takes time away. Jitter always takes time away, because you have to assume the worst edge.

Worked example (illustrative numbers)

Parameter	Value
Tclk2q(max) of FF1	0.12 ns
Tcomb(max)	0.90 ns
Tsu of FF2	0.06 ns
Skew (capture minus launch)	-0.03 ns
Jitter allowance	0.05 ns

Tperiod >= 0.12 + 0.90 + 0.06 + 0.03 + 0.05 = 1.16 ns, so Fmax is about 862 MHz. Without skew and jitter the same path would appear to run at 926 MHz (1.08 ns). That 64 MHz gap is why STA tools carry clock uncertainty in the constraints from the start.

The hold check

Tclk2q(min) + Tcomb(min) >= Thold + skew

There is no period in this inequality. If a short path violates hold on silicon, slowing the clock does not help. The fix is added delay on the data path (buffers in physical design) or less skew.

In detail: the timing budget of a board-level interface

A timing budget is the account of timing requirements, or timing parameters, needed for a system to function properly. For synchronous systems to work, the timing requirements must fit within one clock cycle. A timing budget calculation involves many factors, including hold-time requirements and maximum operating frequency requirements. Working through one also shows the limits of conventional clocking.

Take a system with standard (common) clocking: a memory controller interfacing with an SRAM. Both the SRAM and the memory controller receive clocks from the same clock source, and the clock traces are designed so their delays match. The relevant timing parameters are:

Symbol	Meaning	Belongs to
tSU	Setup time	Memory controller
tH	Hold time	Memory controller
tPD	Propagation delay	Board trace
tCO	Clock to output delay	SRAM
tDOH	Output data hold time	SRAM
tSKEW	Clock skew	Clock generator
tJIT	Cycle-to-cycle jitter	Clock generator
tCYC	Cycle time	Clock generator

Maximum frequency (setup)

The maximum-frequency calculation gives the minimum cycle time of the system when the worst-case input setup time, clock to output time, propagation delay, clock skew and clock jitter are all considered. The condition is:

tCO(max, SRAM) + tPD(max) + tSU(max, CTRL) + tSKEW(max, CLK) + tJIT(max, CLK) < tCYC

and the maximum frequency is one over the smallest tCYC that satisfies it.

Minimum delay (hold)

The hold-time calculation checks that the system does not deliver data too fast and violate the input hold time of the receiving device. Here the worst case is data driven out at the earliest possible time:

tCO(min, SRAM) + tPD(min) - tSKEW(max, CLK) - tJIT(max, CLK) > tH(max, CTRL)

For an SRAM, the earliest moment its output can change is given by tDOH, so tDOH takes the place of tCO(min) in the numbers below. The original post wrote the skew and jitter terms in this formula as "min"; the hold check needs their worst (largest) values, which is what the worked numbers use.

Worked numbers for a DDR SRAM

Now assume the following values. This is a high-speed SRAM with a double-data-rate (DDR) interface, so the SRAM drives data on every rising and every falling clock edge.

Parameter	Value
tSU	0.5 ns
tH	0.4 ns
tCO	0.45 ns
tDOH	-0.45 ns
tSKEW	±0.2 ns
tJIT	±0.2 ns

A negative tDOH means the SRAM output can start to change up to 0.45 ns before the clock edge it is referenced to. That is common on fast DDR SRAMs, where the output valid window is specified as plus or minus a fraction of a nanosecond around the clock edge.

Hold first. The minimum hold-time requirement is:

tDOH + tPD - tSKEW - tJIT > tH
-0.45 ns + tPD - 0.2 ns - 0.2 ns > 0.4 ns
-0.85 ns + tPD > 0.4 ns
tPD > 1.25 ns

Taking the delay of an FR4 board trace as about 160 ps per inch, the trace from SRAM to memory controller must be at least 1.25 / 0.160 = 7.81 inches long.

Then setup. Using tPD = 1.25 ns, and remembering that a DDR interface budgets against half a cycle:

tCO + tPD + tSU + tSKEW + tJIT < tCYC/2
0.45 + 1.25 + 0.5 + 0.2 + 0.2 < tCYC/2
2.6 ns < tCYC/2
5.2 ns < tCYC
fCYC < 192 MHz

With a 7.81 inch FR4 trace and these typical parameters, the budget is met up to 192 MHz. In systems with limited board space, a minimum trace length of almost 8 inches is a hard requirement to meet.

Where the 160 ps per inch comes from

Signal delay on a trace is the square root of the effective dielectric constant divided by the speed of light, which works out at about 85 ps per inch multiplied by the square root of that constant. FR4 has a dielectric constant of roughly 4 to 4.5. A stripline (buried between planes) sees all of it and runs at about 170 to 180 ps per inch; a microstrip on an outer layer sees partly air and runs nearer 140 to 150 ps per inch. 160 ps per inch is a reasonable middle value for a first budget. For sign-off, use the stack-up and the field solver numbers from your board vendor.

Fixing hold with a DLL or PLL phase shift

If adding trace delay is not possible, the memory controller can meet hold by using a delay-locked loop or phase-locked loop (DLL/PLL) to phase-shift its capture clock so that it captures data at an earlier time. The controller then has to resynchronise the captured data to the system clock. The phase shift and the extra jitter the DLL/PLL adds both come out of the setup budget, so this method lowers the maximum operating frequency. With the shift (tSHIFT) and the added jitter (tJIT_PLL), the two checks become:

Hold:  tDOH + tPD(trace) + tSHIFT - tSKEW - tJIT - tJIT_PLL > tH
Setup: tCO + tPD + tSU + tSKEW + tJIT + tJIT_PLL + tSHIFT < tCYC/2

The formulas in the original version of this post were partly lost to a formatting error; the pair above is the corrected form.

Illustrative example. Suppose the board allows only a short trace, tPD = 0.3 ns (under 2 inches), and the DLL adds 0.1 ns of jitter. Hold needs -0.45 + 0.3 + tSHIFT - 0.2 - 0.2 - 0.1 > 0.4, so tSHIFT > 1.05 ns. Setup then needs 0.45 + 0.3 + 0.5 + 0.2 + 0.2 + 0.1 + 1.05 = 2.8 ns < tCYC/2, so tCYC > 5.6 ns and Fmax falls to about 178 MHz. The board is smaller, but the interface is slower than the 192 MHz long-trace version.

Why conventional clocking runs out of room

Clock skew, clock jitter and trace propagation delay can significantly limit system performance, even with the fastest SRAMs and ASICs or FPGAs available. As noted above, trace delay is around 160 ps per inch on FR4. That is a large number when the data-valid window at high frequencies is 2 ns or less: a 250 MHz DDR device, for example, has a half cycle of exactly 2 ns. Skew between clock signals cuts the margin further.

Source-synchronous clocking

Source-synchronous interfaces significantly reduce the effect of propagation delay, skew and jitter, which makes timing closure much more attainable. The SRAM sends a clock (often called an echo clock, CQ, or a strobe, DQS, on DDR DRAM) alongside the data, on traces of matched length. The receiver captures data with that forwarded clock rather than its own copy of the system clock. As a result:

• tPD appears on both clock and data, so it largely cancels. Only the mismatch between the traces counts.
• Skew from the clock generator no longer matters for the capture, because the launch and capture clocks are the same signal.
• What remains is the data-to-clock skew at the driver, the trace mismatch, and the receiver's setup and hold window.

The cost is that the receiver must move the captured data into its own clock domain, usually through a small FIFO. That is a clock domain crossing and needs the usual care.

Common mistakes

• Using typical values instead of worst case. Setup uses maximum delays; hold uses minimum delays and maximum skew.
• Forgetting that DDR halves the budget. Each edge launches data, so setup and hold must fit in half a cycle.
• Trying to fix hold by lowering the frequency. Hold has no period term.
• Using one delay per inch for every layer. Outer and inner layers differ by 20 percent or more.
• Leaving clock uncertainty out of the synthesis constraints, then finding the shortfall at sign-off.

FAQ

What is the formula for maximum clock frequency?

Fmax = 1 / (Tclk2q + Tcomb + Tsu + uncertainty - skew), with skew taken as capture minus launch. Evaluate it on the critical path with worst-case (maximum) delays.

Does clock skew always reduce Fmax?

No. Skew that delays the capture clock gives setup extra time, which is the idea behind useful-skew optimisation. The same skew makes the hold check harder, so it is a trade, not free performance.

Why does a longer trace help hold but hurt setup?

Extra delay pushes the earliest data arrival past the hold window, which is good, but it also pushes the latest arrival closer to the next capture edge, which uses up setup margin.

Is jitter the same as skew?

No. Skew is a fixed, spatial difference in arrival time between two clock pins. Jitter is variation in time of one clock's edges from cycle to cycle. Both are carried as uncertainty in STA, but they come from different sources and are reduced in different ways.