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

Richard Wilbur richard.wilbur at gmail.com
Thu Aug 17 00:01:39 BST 2017


On Aug 15, 2017, at 23:31, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> On Wed, Aug 16, 2017 at 6:11 AM, Richard Wilbur
> <richard.wilbur at gmail.com> wrote:
> 
>>> yehyeh.  i could then move them slightly away from the edge of the board.
>> 
>> I'm curious, what would you move?  The goal of this was to get >=
>> 15mil between any differential signal trace and any trace not
>> from the same differential pair.
> 
> ahhhh ok.  i'm glad you're paying attention :)

I'm trying ;>)

[…]
> if i just take *out* the ground intermediary traces that would do the
> trick of bringing the impedance back up, is that right?

Should be a major step in the right direction.

> what would you suggest, here - leave the intermediary GND traces in
> or take them out.

My suggestion here would be to remove the GND traces between differential pairs since we have established that we can't get 15mil clearance from the differential pair traces with the GND traces in place.  We don't have enough room for that.

I would also look carefully at the GND traces separating the differential pairs from board edge and other circuitry.  If we can't put 15mil between the differential pair traces and these GND traces, I would remove these GND traces as well.  If we have to remove the GND traces between differential pairs and other circuitry, this will at least have the happy effect of providing 15mil spacing between the differential pair and that other circuitry.

This is all based on the fact that we are using differential-mode transmission for the high-frequency HDMI signals.

> also, i think i "Get It" about the intermediary wiggles.  when the
> transmit end does automatic compensation that results in the signals
> coming out in such a way that, really, the inter-pair length-matching
> should be done from the *OPPOSITE* end i.e. from the CONNECTOR.

Maybe I misunderstood the standard because that wasn't my understanding.  (All I know is second-hand because there are no freely available copies.)  What I understood was:
1.  The receiver has the capability to recover up to 5 bit times of inter-pair skew, resynchronizing the bit streams without any loss.
2.  The standard takes this amount of time
   max{T(recoverable inter-pair skew)} = 5 bit times = 0.5 * T(pixel)
for highest pixel clock supported under HDMI v1.4
  max{f(pixel)} = 340MHz => T(pixel) = 2940ps
  max{T(recoverable inter-pair skew)} = 1470ps
and allocates fractions of it to maximum inter-pair skew tolerances for the implementation of the HDMI transmitter (source of HDMI signal such as DVD player, video game console, or computer such as the EOMA68-A20), the HDMI cable, and the implementation of the HDMI receiver (sink of HDMI signal such as monitor, an HDMI-switching A/V receiver, an HDMI to VGA convertor).

Thus, in order to make an HDMI v1.4 standard-compliant transmitter (which is my understanding of what we are trying to do with the EOMA68-A20) we must emit from our HDMI connector an HDMI signal which exhibits
  max{T(inter-pair skew)} <= 0.2 * T(pixel) = 588ps
This inter-pair skew can come from connector, the chip, and the PCB traces connecting them.  It seems likely that the connector and the chip will likely be very minimal sources of inter-pair skew, and thus most, if not all, of the transmitter allocation falls to the PCB designer to use (or squander--depending on how you view it) in connecting the chip to the HDMI cable connector.

At the speed of propagation of signals in our microstrip differential pairs this amounts to
  max{length(inter-pair skew)} = v(propagation) * max{T(inter-pair skew)}
  = 150um/ps * 588ps = 88.2mm
Toradex suggests we limit the inter-pair skew in the traces to 1/4 of that value or 0.5 * T(bit) which corresponds to a length of 22mm.

From what I've seen, even without inter-pair skew compensation in the layout the inter-pair skew you observed was ~8mm < 22mm.


> because the automatic compensation will result in the signals coming
> out with a small delay, which by the time they go round that big set
> of bends they *WILL BE IN SYNC*.
> 
> ok they'll be in sync as long as all pairs are exactly the same
> length from that point up until they meet the connector.
> 
> so the only bit that would be out-of-sync would be that huge set of
> bends just after the transition from CPU-layer-1 onto layer 6, where
> i've had to put in huge amounts of bend-compensation.
> 
> by adding in the down-stream inter-pair compensation just before the
> rclamp0524p's) that *entire straight section* is out of sync... and
> the set of bends is also out-of-sync so it's no improvement.

If this is indeed how it works then I'll need to rethink my recommendations.  (I outlined my understanding above.)

>> Are you talking about moving the differential pairs further
>> from the edge of the board?
> 
> yes. but from what you're saying it's not possible anyway.

How far are the differential traces from board edge at present?

[…]
> indeed.  however i don't want to change the BOM, apart from anything
> that's a TI part not a "Well Known Easily Sourceable Part In The Shenzhen
> Huaqiang Road Eco-System".
> 
> dual rclamp0524's, one each side, it is.

I understand about part availability.  For what it's worth, that document [SLLA324] concerns a TI part--TPD12S016 to be exact. It comes in both TSSOP and μQFN packages.  The board layout we have been discussing in which they use the micro (type "D") connector they pair it with the μQFN package ESD part.


More information about the arm-netbook mailing list