> On Aug 9, 2017, at 03:34, Luke Kenneth Casson Leighton <[email protected]> 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? _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
