ok reading in full, cutting extraneous, answering only with confirmation. On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur <[email protected]> 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[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 actual difference between CK and Tx2 is 55 - 48mm, or 7mm. so... 275 mil. whoops. 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.[6] > (Half of the 10-bit pixel time.) A Texas Instruments (TI) employee > specifically suggested to keep the clock pair longer than the data > pairs.[7] 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[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.) 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 > trace.[9] 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[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] 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. l. _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
