Length Matching in High-Speed PCB Design

I’m looking for clarification on the importance of length matching in high-speed PCB design, specifically regarding its relationship with parallel data lines and the clock signal. High-speed PCB design guidelines often recommend matching the lengths of data, address, and command lines to the clock trace length. Can someone explain why this is necessary? From my understanding, the clock signal is continuous and periodic, meaning there shouldn’t be any data loss. Data signals are synchronized with the clock’s positive or negative edge, which defines their timing in the waveform.

1 Like

In a situation where you have a parallel bus, clocked by a single clock signal, the data sheets for the sending and receiving nodes will specify such things as the maximum clock to output delay (ideally they will also give you the minimum delay too) and at the receiving end there will be setup and hold times given. The minimum period for the clock is determined by adding the clock to output maximum delay to the input setup time and now you have the figure from which the maximum clock frequency is derived. By rights there is also the hold time to consider, and if the opposite edge of the clock is used to capture the data, then there is the duty cycle of the clock to take into account as well. But the problem is that this is still a simplification of the requirements.

The assumption is that the timing relationships between the clock and the data signals will be just the same at the receiving node as they were at the sending node. On real PCBs this is almost never the case. But it can be if thought was given beforehand and the PCB layout allowed for this. Enter length matching.

The idea that matching the lengths of the signals will mean that the signal timings will all be equally affected is not true and the reason why will be explained later. For now, let’s assume that if the lengths are the same, then the time delays will be the same. It follows that if the data signals are longer than the clock, their timing will be late, and so the minimum clock period needs to be extended by this amount of time, so you have to reduce the clock frequency to compensate. But how much does this amount to?

We can make some approximations but note that these are very rough generalisations. On a typical FR4 PCB the signal propagation velocity for signals on the top or bottom layers is 20cm per nanosecond. So if you make the data signals 20cm longer than the clock, they will arrive late by 1ns, so the setup time will need increasing to allow for this delay. To increase the setup time you allow, the maximum frequency therefore gets reduced. This doesn’t affect low frequencies very much, but it does make a noticeable difference if you wanted to run a clock at 500 MHz, and found that adding in another 1ns meant it now runs at 333 MHz.

Now consider how things look when the board is one that has inner layers, does what has been said still hold true? In principle, yes; in practice no. The typical propagation velocity on an inner layer of an FR4 board usually works out somewhere near 15cm per nanosecond. So routing some of your data signals on an outer layer and the others on inner layers, and they’re all the same length guarantees that the outer layer signals arrive before the inner layer signals (and the via lengths getting to and from the inner layers also count).

As the real issue is satisfying timing relationships, the solution is only “length matching” if all the signals are on outer layers or all on inner layers. What you are actually trying to match is therefore the “flight-time” of the signals.

So far, only the data setup effects have been considered. It is just as important to give thought to the hold times. The principles are similar to the above, but this time you are most concerned about the signals that arrive at the receiving node earlier than the clock arrival time.

The question of how accurately it is necessary to match the signal lengths is first to say that at low frequencies (say 20 MHz and below) it usually doesn’t matter much because a 50ns period makes differences in the sub nanosecond range of little importance. But as frequencies increase the importance of flight-time matching also increases.

The question of whether a particular clock/data interfaces needs matching is answered by doing the maths. It’s always better to have considered it and chosen accordingly than to discover it when the boards don’t work.

Final remark; all the above is said in the context of a clock and data interface where all are single-ended signals. This does not apply to differential signals. In that situation there are additional rules relating to the two signals within each data pair. But that’s another subject.

2 Likes

In high-speed designs, data transmission timing relies on the clock signal. To ensure accurate data transmission, each data bit must be stable relative to the clock’s edge—meaning it needs to meet both setup and hold time requirements. If the clock trace is too long relative to the data traces, the clock signal could arrive too late, potentially missing the hold time requirement. Conversely, if data traces are longer than the clock trace, data could arrive too early, impacting the setup time. Matching trace lengths helps ensure that both setup and hold times are consistently met, maintaining signal integrity and timing accuracy.

1 Like

I think the key is in why you’re bothering to use a clock in the first place. You’re using it to tell the other end “Hey, look NOW!” (or maybe “send now”, but … you get the idea.)

We think of the speed of light as instant, but it does take some time – and the rest of the circuit is also moving at the same incredible speed. So if the clock and data aren’t matched well enough, the other end will look a little bit late (or a little bit too soon), and will sometimes see the wrong thing. The right thing got transmitted, but was already gone (or not there yet) when you looked at it.

In a slower analogy, this would be “check the oven to see if dinner is done”. Dinner will be properly cooked at the appropriate time, but if that isn’t the same time as when you check, the food you actually get out won’t be quite as good. The electronics are reacting so quickly that sending messages – even very fast ones – on different paths can get them out of sync.

1 Like