[Arm-netbook] HDMI High-Frequency Layout: Timing
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Aug 1 11:29:24 BST 2017
ok reading in full, cutting extraneous, answering only with confirmation.
On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur
<richard.wilbur at gmail.com> wrote:
> So, while we will try to match the impedance of our traces
> (transmission lines) as carefully as possible to the characteristic
> impedance specified for the cable, until we get to 4.3 inches from the
> signal source the line driver should be able to squash most
> reflections on the leading edges (first quarter wavelength).
actual distance is 55mm, under half the 4.3in.
> Inter-pair skew: (Requirements for HDMI v1.4)
> clock-data skew: Δt <150ps
> => Δl < v * Δt = 22mm ~= 870mil
> T(Pixel) = 1/(pixel clock) = 2.94ns
> Skew(Inter-Pair) < 0.20 * T(Pixel) = 588ps
> => Δl < v * Δt = 88.2mm ~= 3470mil
> Chrontel suggests matching between any two pairs be within 100mil.
> => Δl < 100mil => Δt < Δl / v = 2540um / (150um/ps) = 17ps
actual difference between CK and Tx2 is 55 - 48mm, or 7mm. so... 275
between CK and Tx2 is 55 - 52 = 3mm, so... 118 mil. again whoops.
> Of these design parameters Chrontel's 100mil recommendation seems to
> be the most restrictive, but still not out of the realm of possibility
> and probably a good precautionary limit. With only 17ps of inter-pair
> skew we meet even much tighter skew timings. Having non-vanishing
> inter-pair skew seems to actually be beneficial for reducing
> Electro-Magnetic Interference (EMI) by avoiding simultaneous
> transitions on multiple lines. Indeed the standard seems to be
> designed to recover up to 5 bits of worst-case inter-pair skew.
> (Half of the 10-bit pixel time.) A Texas Instruments (TI) employee
> specifically suggested to keep the clock pair longer than the data
sounds like a good idea... and has to happen anyway: the clock lines
have slightly further to go.
> Intra-pair skew: (Requirements for HDMI v1.4)
> Toradex: Δt < 5ps
> => Δl < v * Δt = 0.75mm ~= 30 mil
> Chrontel, Texas Instruments: T(bit) = 0.1 * T(Pixel) = 294ps
> Skew(Intra-Pair) = 0.15 * T(bit) = 44.1ps
> => Δl = v * Δt = 6.62mm ~= 261 mil
> (Chrontel suggests, without saying why, that matching between
> signals should be within 5mil. Given the context and calculations
> above suggesting 261 mil for total, this should probably be 5mil skew
> per segment.)
i try to meet that - 5 didn't know it was as little as 5mil though.
that's absolutely tiny!
> Chamferred Corners (or Trace Bend Geometry)
> I'm glad to see you are already using 45 degree bends instead of 90
> degree corners. This helps the corners maintain the proper impedance.
> When serpentine traces (meanders) are needed to attain certain lengths
> of a single-ended trace, make sure individual segment lengths are at
> least 1.5x the width of the trace. Also, the spacing between parallel
> segments of the same trace should be at least 4x the width of the
that's going to be very very hard to achieve: there is an extremely
limited amount of space.
> Length Matching
> Differential pair signals should not propagate asynchronously over a
> distance greater than 15mm = 590mil. Thus the compensation for
> length mis-matches should be placed as close to the mismatch as
> possible. Differential traces can be segmented by a connector, pad
> (component or IC), or via. "Each segment of a differential
> pair connection needs to be matched individually."
yeah i saw that in the toradex recommendations, otherwise there's
skew between traces.
> Ideal serpentine trace geometry for equalizing differential traces
> consists of the following proportions: the spacing between traces in
> the meanders should not exceed twice the normal spacing, and the
> length of more widely spaced traces should not exceed three times the
> normal trace width.[10, see Figure 23]
there's a lot of other stuff in here which is really good, such as
making sure that lengths on each *layer* are matched, and that even
when turning corners the lengths are matched. and matching just after
VIAs *not* before... damn
so thank you - much to correct and think about. really appreciated
you finding all this stuff richard.
More information about the arm-netbook