A board carries a processor and a memory-mapped peripheral chip, both clocked from one 200 MHz oscillator. It works. The next revision moves the peripheral to the far side of the board to make room for a connector, about 200 mm away. Nothing else changes, yet reads from the peripheral now fail at room temperature on some boards and at high temperature on all of them.

Both chips see the same clock. Why does moving one of them break the interface?

The obvious answer, and why it breaks

The obvious answer is that a shared clock settles the question of when data is valid: both sides tick together, the sender changes data on one edge and the receiver samples on the next. That is true only if the data gets there within one period. A signal on a board travels at a finite speed, and the sender also needs time to drive it and the receiver needs it to be stable for a while before the edge. Move the chips apart and the trip gets longer, while the clock period stays the same.

The idea: one clock, one period, one budget

In a common-clock (or system-synchronous) interface, the sender launches data on a clock edge and the receiver captures it on the next edge of the same clock. Everything between launch and capture must fit into one clock period:

• t_co, clock-to-output: how long after its clock edge the sender's output changes.

• t_flight: travel time along the wire, proportional to its length.

• t_setup: how long before the capturing edge the data must be stable at the receiver.

• t_skew: how much later (or earlier) the clock edge arrives at the receiver than at the sender, since the clock also travels on wires.

• t_margin: what you keep for jitter, temperature and process variation.

There is also a hold condition: data must stay stable for a short time after the edge, so a path that is too fast can fail too. Skew hurts both: the clock reaching the receiver late eats into hold, early eats into setup.

Build it: the budget, by distance

The model computes the shortest safe period, and so the fastest clock, for five trace lengths, with illustrative numbers for the fixed terms and for propagation along a board trace.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

"""Common-clock timing budget: how fast can two chips on one clock talk?

One clock period must cover the sender's clock-to-output delay, the flight time
along the board, the receiver's setup time, the clock skew between the two chips,
and a margin. Flight time grows with distance, so the clock must slow down.
All numbers are illustrative.
"""
T_CO, T_SETUP, T_SKEW, T_MARGIN = 1.0, 0.5, 0.3, 0.2   # ns
PS_PER_MM = 6.7                                         # board trace, illustrative

print("distance  flight   period   max clock")
rows = []
for mm in (25, 50, 100, 200, 400):
    flight = mm * PS_PER_MM / 1000                      # ns
    period = T_CO + flight + T_SETUP + T_SKEW + T_MARGIN
    rows.append((mm, period))
    print(f"{mm:5d} mm {flight:5.2f} ns {period:6.2f} ns {1000 / period:7.0f} MHz")

periods = [p for _, p in rows]
assert all(a < b for a, b in zip(periods, periods[1:]))  # longer wire, longer period
print("PASS: every extra millimetre lengthens the period; the fixed terms cap the clock even at zero distance")

It prints:

distance  flight   period   max clock
   25 mm  0.17 ns   2.17 ns     461 MHz
   50 mm  0.34 ns   2.33 ns     428 MHz
  100 mm  0.67 ns   2.67 ns     375 MHz
  200 mm  1.34 ns   3.34 ns     299 MHz
  400 mm  2.68 ns   4.68 ns     214 MHz
PASS: every extra millimetre lengthens the period; the fixed terms cap the clock even at zero distance

Two things stand out. First, distance alone lowers the ceiling for a one-way transfer from about 375 MHz at 100 mm to about 300 MHz at 200 mm, and the next section shows that reads are worse. Second, even at zero distance the fixed terms (2 ns here) cap the clock at about 500 MHz. Making wires shorter helps less and less; the scheme itself has a ceiling.

Worked numbers: the read is worse than the write

For a read, the data must make a round trip: the clock (or the request) goes out to the peripheral, and the data comes back. With the model's numbers at 200 mm, a write uses one flight time (1.34 ns), while a read uses the clock's trip out plus the data's trip back, 2.68 ns, the same as the 400 mm row: a 4.68 ns budget. The opening design runs at 200 MHz, a 5 ns period, so its reads keep only about 0.3 ns beyond the stated margin, and a hot board or slower silicon uses that up. That is why the opening failure hit reads first. Any common-clock or master-clocked interface where data flows against the clock pays this round trip.

The design space

How real protocols chose

What breaks

The opening failure, told as debug steps (illustrative numbers):

• Symptom: reads from the moved peripheral fail intermittently, worse when hot; writes are fine.

• Evidence: on a scope, read data reaches the processor's pins close to, and sometimes after, the capturing clock edge.

• Root cause: the read path pays a round trip of about 2.7 ns of flight time on top of the fixed terms; together with skew and margin the period is exceeded at temperature.

• Fix: slow the bus clock for that peripheral, or add a turnaround cycle so read data is captured one edge later. The lasting fix is to move the interface to a scheme whose budget does not include the round trip, such as source-synchronous capture.

Key takeaways

• In a common-clock interface, one period must cover clock-to-output, flight time, setup, skew and margin.

• Flight time grows with distance and reads pay a round trip, so common-clock links slow down as chips move apart.

• Faster schemes send timing information with the data so that wire delay drops out of the budget.

Related topics

• Part 1 overview: Timing and Clocking

• RTL course: Source-Synchronous Interfaces