On Aug 9, 2017, at 03:34, Luke Kenneth Casson Leighton lkcl@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?