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

Richard Wilbur richard.wilbur at gmail.com
Tue Aug 1 10:57:59 BST 2017

HDMI Layout Notes
for EOMA68 Cards
by Richard Wilbur


Now that we have a speed of propagation, let's figure out the timing
constraints imposed by the HDMI standard to the level we plan to
support--v1.4.  The standard doesn't seem to be freely available so,
thankfully, several manufacturers mention various timing constraints
in their documentation.  The maximum pixel clock frequency is revealed
in Toradex' design guide.

Max Frequency:  (HDMI v1.0-1.2a) 825 MHz (165 MHz pixel clock)
        (HDMI v1.3-1.4) 1.65 GHz (340 MHz pixel clock)[3]

For a transmitter, many impedance improprieties (mismatches) can be
forgiven in the first quarter-wavelength of propagation.

T(Pixel) = 1/(pixel clock) = 1/(340MHz) = 2.94ns
wavelength = velocity * period = 150um/ps * 2940ps = 441mm = 17400mil
quarter wavelength = wavelength / 4 = 4350mil

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).
Impedance still matters for proper signal levels, but more in the bulk

The problem we will first turn our attention to, then, is that of skew
(differences in signal arrival time) usually most noticeably caused by
differences in trace length.  Several goals are outlined in the
literature I reviewed:  skew between the clock pair and any data pair,
skew between any two pairs (both of these fall under what I would call
"Inter-pair Skew"), and skew between the traces of a particular pair
("Intra-pair Skew").

Inter-pair skew:  (Requirements for HDMI v1.4)
    clock-data skew:  Δt <150ps[3]
     => Δl < v * Δt = 22mm ~= 870mil
    T(Pixel) = 1/(pixel clock) = 2.94ns
    Skew(Inter-Pair) < 0.20 * T(Pixel)[4][5] = 588ps
     => Δl < v * Δt = 88.2mm ~= 3470mil
    Chrontel suggests matching between any two pairs be within 100mil.[5]
    => Δl < 100mil => Δt < Δl / v = 2540um / (150um/ps) = 17ps

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.[6]
(Half of the 10-bit pixel time.)  A Texas Instruments (TI) employee
specifically suggested to keep the clock pair longer than the data

Intra-pair skew:  (Requirements for HDMI v1.4)
    Toradex:  Δt < 5ps[3]
     => Δl < v * Δt = 0.75mm ~= 30 mil
    Chrontel, Texas Instruments:  T(bit) = 0.1 * T(Pixel) = 294ps
    Skew(Intra-Pair) = 0.15 * T(bit)[4][5] = 44.1ps
     => Δl = v * Δt =  6.62mm ~= 261 mil
    (Chrontel suggests, without saying why, that matching between
signals should be within 5mil.[5]  Given the context and calculations
above suggesting 261 mil for total, this should probably be 5mil skew
per segment.)

Intra-pair skew causes EMI.[8]  One way to see this is to consider
what we're trying to do by routing the differential signal on a
differential pair of traces.  The goal is to make the distance between
the traces as small as possible and still maintain the differential
impedance needed to match the rest of the transmission line.  This
reduces the size of the effective antenna.  When the signals are
propagating in parallel down this pair of traces the length of the
effective dipole antenna is the distance between the two wavefronts.
If the traces are parallel and equidistant from the source, the
combined wavefront will be perpendicular to the traces and of minimal
effective size.  If a difference in distance from the source occurs
between the traces, the combined wavefront will no longer be
perpendicular to the traces and the effective size will be larger.

Toradex' "Layout Design Guide" has a great treatment of problems and
suggested solutions throughout section 6 "High-Speed Layout
Considerations".  Of particular interest here is section 6.7 "Length
Matching", pp. 21-25.  Section 6.8 "Signal Return Path", pp. 25-29, is
of considerable related interest.

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

Length Matching

Differential pair signals should not propagate asynchronously over a
distance greater than 15mm[10] = 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.[10][5]  "Each segment of a differential
pair connection needs to be matched individually."[10]

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]

[3]  Toradex, page 38
[4]  TI, page 4
[5]  Chrontel, page 5
[6]  https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter-pair-synchronization.75801/
[7]  https://e2e.ti.com/support/interface/high_speed_interface/f/138/t/267205
[8]  https://www.researchgate.net/publication/224650488_Effects_of_skew_on_EMI_for_HDMI_connectors_and_cables
[9]  Toradex, page 17, Figures 12 & 13
[10]  Toradex, pages 22-23


More information about the arm-netbook mailing list