> On Aug 9, 2017, at 03:34, Luke Kenneth Casson Leighton <l...@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
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
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.
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@example.com
Send large attachments to arm-netb...@files.phcomp.co.uk