[Arm-netbook] HDMI High-Frequency Layout: Recommendations

[Richard Wilbur]

> On Aug 9, 2017, at 03:34, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> 
> okaay, so this is what i've managed for the outgoing vias (layer 1),
> the two lengths are equal (to each other and including across all four
> pairs) and the relative positions of each via are identical.

Very nicely done--especially considering how tight that space is.  I like the way you snuck some extra length on the traces from the closer pins and with 45 degree bends no less.

> for layer 6.... faak it's tight on space down the bottom, so i simply
> can't get anything but "turns" in.   it'll have to go dead-straight
> until the other end of the board, after the PMIC, where i'll then be
> able to correct the length differences between the CLK pair and the
> other pairs.

Since the digital portion of the receivers is built to specifically correlate up to 5 (out of 10) bit times of inter-pair skew (arrival time difference between differential pairs) for every pixel clock, you could think of building in some inter-pair skew as similar to spread-spectrum techniques which have been employed in communications to drop the energy peak on the carrier frequency and more recently on motherboard chipsets.  The clock period for 340MHz is
T(Pixel) = 1/(pixel clock) = 1/(340MHz) = 2.94ns
wavelength = velocity * period = 150um/ps * 2940ps = 441mm = 17400mil
So half that period = 1470ps, which at the speed of propagation is ~ 220mm ~ 8700mil.  So there is our inter-pair skew budget for the whole path:  differential driver, IC lead wire, pin, PCB (the part we have design control of presently), connector, HDMI cable, connector, receiver PCB, pin, IC lead wire, receiver.  I believe that if we reserve one-tenth of that inter-pair skew for our transmitter PCB, we should not be unduly stressing the budget and that amounts to ~ 22mm ~ 870mils.  Interestingly this is Toradex' suggested limit for skew between clock and data.  The HDMI standard restricts transmitters to
T(inter-pair skew) = 0.2 * T(pixel) = 2 * T(bit) = 588ps
 => Δl < v * Δt = 88.2mm ~= 3470mil

> richard you said that the difference between all pairs should be no
> more than 100mil, right?  but that clock should be a leetle bit
> longer.

I did suggest we might work towards that as a goal based on Chrontel's recommendation, but now I'm giving the spread-spectrum idea more thought and thinking we might design some inter-pair skew into the system on purpose to reduce the amplitude of EM from the constructive interference of all those (painstakingly) phase-aligned transitions.  So here is one strategy to implement what I was thinking (predicated on the spread between shortest and longest data pairs being less than 0.5 * L(bit)):
1.  Shortest pair becomes our reference length.
2.  Other two data pairs are routed different fractions of T(bit) longer than the reference pair.
3.  Clock pair is routed a larger fraction of T(bit) longer.

Hence:
L(reference) = L(shortest data pair without inter-pair skew compensation)
T(bit) = 294ps
=> L(bit) = v * T(bit) = 150um/ps * 294ps = 44.1mm ~ 1740mil
Suppose we select fractions:  0.2, 0.3, 0.5(clock)
then we would make L(longer data pair) = L(reference) + 0.2 * L(bit)
L(longest data pair) = L(reference) + 0.3 * L(bit)
L(clock pair) = L(reference) + 0.5 * L(bit) = L(reference) + 22mm

I guess I should first ask what are the differential pair lengths before inter-pair skew corrections?

> CLK-pairs are 57.245 (i got them to within a thousandth of a mm!
> 57.245 and 57.24518 how jammy is that!!)

Now that is some great length matching!  And intra-pair where it looks like it matters the most!

> HX2N/P are 49.something - a hell of a big difference.  luckily that
> one's on the outside edge so i can "wiggle" it a lot :)

The clock data difference is  ~8mm ~ 310mil.

That's around an order of magnitude (factor of 10) smaller than the limit the HDMI standard imposes on transmitters and more than a factor of 2 smaller than Toradex' recommended limit.

> oh... i had another go at the USB pairs, after reading all that you
> recommended i wasn't happy that there was skew (which i never noticed
> before).  the USB lines worked but there would have been quite a bit
> of EM.

I must confess I hadn't looked at the USB traces but it sounds like a good thing.  Which level of support are you providing?