arm-netbook August 2017

arm-netbook@lists.phcomp.co.uk

23 participants
32 discussions

Side-Topic: Liberating PocketCHIP
by John Luke Gibson 08 Aug '17

08 Aug '17

Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling. Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath: > Date: Sat, 29 Oct 2016 20:13:10 +0200 > From: Parobalth <parobalth(a)gmail.com> > To: arm-netbook(a)lists.phcomp.co.uk > Subject: closed-source BootROM and RYF certification > User-Agent: Mutt/1.5.23 (2014-03-12) > > At the forum of NextThing Chip is a thread about Chip and a > possible RYF certification. I wrote there that I think that is unlikely > to happen and linked to https://www.crowdsupply.com/eoma68/micro-desktop/updates/fsf-ryf-background. > Then someone else mentioned that a closed-source BootROM is used for Chip. > Another guy with username "eaterjolly" wrote about this BootROM: "The same type of SOC is > used for the EOMA croud project which is vying for ryf-endorsement quite > openly [...]" > > You can find the forum thread here: > https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490 > > Because they use Discourse to power their forum which relies heavily on > JavaScript I also attach a Pdf version of the forum post. > > I wonder if the mentioned statements are correct and how it relates to > the RYF certification of the EOMA68-A20 Libre Tea card. > > kind regards > Paro Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman: https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob Particularly in files mentioning the devil: "# Entry-type module for Intel Chip Microcode binary blob" I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether. If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now. How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.

17 43

Injection Molding Cost
by Bill Kontos 05 Aug '17

05 Aug '17

Hi, I remember luke mentioning in the past that injection molding would be too expensive for such a low-volume project. However I found this project from crowd supply that is using molds for production on a total of ~3800 pledges https://www.crowdsupply.com/ugl/ultimate-hacking-keyboard/updates/2198 The numbers don't make any sense given the ~100k cost luke has mentioned in the past( the 2 keyboard halves have different designs). What am I getting wrong here ? The factory they will be using is located in Europe.

2 1

HDMI High-Frequency Layout: Impedance
by Richard Wilbur 04 Aug '17

04 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Impedance Trace Impedance: 100 Ohm +/-15% differential[11][12], 55 Ohm +/-15% single-ended[3] (90 Ohm +/-15% differential, 50 Ohm +/-15% single-ended[3]) There seems to be some small disagreement between sources on the differential trace impedance for HDMI high-speed signals. Chrontel[11], Texas Instruments[12], and JAE[13] all quote 100 Ohm but with different tolerances--Chrontel +/-10%, Texas Instruments +/-15%, JAE +/-25% (in connector area[13])--while Toradex[3] quotes the goal as 90 Ohm +/-15%. These ranges overlap but the normal variation in manufacturing is more likely to exceed the limits of the acceptable range if we design to the wrong goal! 90 Ohm +/-15% = [76.5, 103.5] Ohm 100 Ohm +/-15% = [85, 115] Ohm It seems the consensus is on 100 Ohm +/-15% for the differential impedance. Toradex mentions something else which helps with the selection of design parameters: "The differential impedance is always smaller than twice the single-ended impedance" Z(differential) < 2 * Z(single-ended)[14] => Z(single-ended) > Z(differential) / 2 Thus, if we wish to have Z(differential) = 100 Ohm +/-15%, we should choose the single-ended impedance such that Z(single-ended) > (100 Ohm +/-15%) / 2 = 50 Ohm +/-7.5% Toradex suggests 55 Ohm single-ended impedance to coincide with 100 Ohm differential impedance.[15] In order to model and calculate expected impedance we need to describe the geometry of the arrangement of traces, reference planes, and dielectric layers in the PCB. PCB Dimensions (not drawn to scale or even to correct aspect ratio): ______ ^ T (thickness of copper in signal layer) v _______________________________ ^ H (thickness or height of insulator) v _______________________________ reference plane (GND or Power) _______________________________ The 6-layer FR-4 PCB chosen for EOMA68-A20 has the following characteristic dimensions: total thickness of PCB = 1.2mm ~= 47.3mil H(height of dielectric between outer copper layer and adjacent reference plane) = 6.4mil copper cladding = 1oz min{W(trace width)} = 5mil min{S(trace-to-trace space)} = 5mil min{diameter(plated through-hole vias)} = 6mil diameter(via surround/pad) = 12mil To calculate the thickness (T) of 1 ounce copper requires several conversion factors and the density of copper. "1 ounce copper" refers to the thickness of 1 ounce (avoirdupois versus troy) of copper spread over 1 square foot. There is at least one web site which purports to calculate the thickness in mils of a particular weight of copper cladding[16], but they use some pretty heavy approximations for otherwise well-known conversion factors and conclude that 1.37 mil = 1 oz Cu. I used the standard unit conversion factors as shown below: Given: Areal density = 1 oz Cu / ft^2 Exact conversion factors: 1 (avoirdupois) oz = 28.349523125g [17] 1 ft^2 = (1ft * 12in/1ft * 2.54cm/1in)^2 = (30.48cm)^2 Empirical value: Density (Cu pure) rho = 8.96 g / cm^3 [18][19: CRC, LNG] Calculation: T = areal density(given) * conversion(oz->g) / (volume density) / conversion(ft->cm)^2[16] T = 1 oz Cu / ft^2 * 28.349523125g / 1 oz * 1 cm^3 Cu / 8.96 g Cu * 1 ft^2 / (30.48cm)^2 = 0.003405711cm Cu = 0.03405711mm * 1in / 25.4mm * 1000mil / 1in = 1.34mil Cu (Using 8.92 gCu / cm^3 [19: WEL] => T = 1.35mil Cu) The most well-attested value for copper's density was 8.96 g/cm^3 yielding T = 1.34mil Cu. Illustrating the sensitivity of the calculation to variation of parameters, the minority density value of 8.92 g/cm^3 yielded T = 1.35mil Cu. Microstrip PCB Dimensions (not drawn to scale or even to correct aspect ratio): <-W-><--- S ---><-W-><----- D -----> __IIIII___________IIIII___________________IIIII Signal:+ - x W = design width of trace S = spacing between traces of differential pair (+,-) D = spacing to unrelated signal "x" (another pair, ground shield, etc.) Texas Instruments gives some equations to help calculate trace geometries for 100 Ohm differential impedance.[12] Z(differential) = 2 * Z(single-ended) * (1 - 0.48 * exp(-0.96 * S / H)) Z(single-ended) = 88.75/sqrt(relative permittivity + 1.47) * ln(5.97 * H / (0.8 * W + T)) Since the board material and manufacturing process specify the parameters: relative permittivity(FR-4) = 4.4[1] H = 6.4mil T = 1.34mil and the HDMI standard specifies: Z(differential) = 100 Ohm we have two equations in three unknowns: Z(single-ended), W, S Given the guidance that Z(single-ended) > 50 Ohm, we can solve the second equation for W(Z(single-ended)), W<mils> = 7.463 * H * exp(-Z(single-ended) * sqrt(relative permittivity + 1.47) / 88.75) -1.25 * T Then select a value for Z(single-ended), turn the crank and see what value of W we come up with. After looking at the result we may decide to select a different value for Z(single-ended) and calculate the concomitant W in order to find a routable trace width and a usable single-ended impedance. Let's try this for Z(single-ended) = 55 Ohm. W(Z(single-ended) = 55 Ohm) = 7.463 * 6.4mil * exp (-55 Ohm * sqrt(4.4 + 1.47)/88.75) - 1.25 * 1.34mil = 8.97mil Then we can solve the equation that gives differential impedance for S, plug in our values for single-ended and differential impedance and see what trace-spacing (S) we get. S = -H / 0.96 * ln((2 * Z(single-ended) - Z(differential)) / 0.96 / Z(single-ended)) S(Z(single-ended) = 55 Ohm) = -6.4mil / 0.96 * ln((2 * 55 Ohm - 100 Ohm) / 0.96 / 55 Ohm) = 11.1mil The distance, D, to adjacent signal pairs and shield traces is suggested to be, D >= 3 * S[12] with the caveat that running a ground shield trace on only one side can create an imbalance that increases EMI. "Ground trace shields should have a scattering of vias to the underlying ground plane."[12] Z(single-ended) W<mil> S<mil> min{D}<mil> <Ohm> 51 10.2 21.3 63.9 55 8.97 11.1 33.3 60.1 7.58 7.00 21.0 64.6 6.51 5.02 15.1 Table of single-ended impedances and associated trace width and spacing.[These numbers are based on formulas which are approximations with error bounds of +/-10%.][12] Here we can see the effect of changing the single-ended impedance on width and spacing of traces in a differential pair of given differential impedance. By raising the single-ended impedance we reduced both the width of the traces and also the spacing. The other outgrowth is that the common-mode rejection is improved by lowering the single-ended impedance of the traces. Common-mode signal stems from other signals (EMI) coupled into the traces, uncompensated intra-pair skew, and imperfect differential signal drivers at the source. Common-mode signal will radiate (EMI) from circuit board traces. So we have a trade-off to consider: 1. We can minimize common-mode signal by lowering single-ended impedance which increases the trace width and spacing for a given differential impedance. 2. This is limited by the fact that, for a microstrip differential pair, the single-ended impedance is greater than half the differential impedance. Looking at the single-ended impedance values, the difference between 51 Ohm and 64.6 Ohm is an increase of less than 30% and thus won't drastically change the common-mode performance, so my inclination if you're strapped for space would be to use the higher single-ended impedance with 6.5mil wide traces spaced apart 5mils and try for 15mils between pairs. Reviewing with reference to TI's "Routing Guidelines"[20]: i. Use the smallest trace spacing possible, which usually is specified by your PCB vendor: in our case 5 mils ii. Make sure the geometries obey: a. S < H; (S = 5mil) < (H = 6.4mil) b. S < W; (S = 5mil) < (W = 6.5mil) c. W < 2H; (W = 6.5mil) < (2H = 12.8mil) d. D > 2S = 10mil Looks like we abide by their guidelines if we use the 64.6 Ohm single-ended impedance values. It seems the distance, D, to the next trace is somewhat flexible because in this reference it is reduced from 3S to 2S. (I'm sure 3S is better than 2S, if you have the space.) Ground Planes under Pads Toradex mentions the lower impedance between wide traces and the reference plane causing impedance mismatch at large pads for components and connectors.[21] The width of the pads in the illustration are 5-6x the width of the traces connecting to them. On the micro-HDMI connector the width of the pads is around 0.2mm (JAE DC3R019JA7R1500 pad width = 0.23 +/-0.03 mm ~= 9.1 +/- 1.1 mil), where the smallest trace we can have is 5 mil thus our greatest proportion is 10.2 mil / 5 mil ~ 2. So this is probably less of a problem than if the pads were 5-6 times the width of our traces. In fact if we compare the dimensions of the connector pads and spacing (which is about the same as pad width) to those of the trace width and spacing for 55 Ohm single-ended impedance in the table above, they nearly match. Thus I don't think this will be a big issue for this board because while the pads are wider than our traces, they're spaced about as far apart as we would space traces that are that wide to still get 100 Ohm differential impedance. Via Impedance If and when we start supporting HDMI v2.0+ we will need to tune the impedance of our signal vias even more keenly as our signals will surpass the 10GHz barrier.[22] Presently we also have the happy situation that since our high-frequency signal vias always connect between top and bottom layers, our stub length is 0 on signal vias. Creating transparent (tuned) vias requires familiarity with a 3-D EM simulator and some time to set up, run, evaluate results of simulations, and then repeat in order to tune the impedance. (See section below "Libre Field Solvers".) We can still take some of the recommendations to heart: 1. Use minimal size vias for high-frequency traces to reduce parasitic capacitance.[23] 2. Place the two vias of the differential pair in close proximity to increase capacitive coupling between the signals.(smaller via pitch) 3. Instead of using two separate anti-pads on signal vias, combine them into oval shared antipads (on every layer) to reduce parasitic capacitance. 4. Place ground vias next to signal vias to provide ground-return paths.[22, Figure 2] References: [1] https://en.wikipedia.org/wiki/FR-4 [2] Toradex, page 21 [3] Toradex, page 38 [4] TI, page 4 [5] Chrontel, page 5 [6] https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter… [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_f… [9] Toradex, page 17, Figures 12 & 13 [10] Toradex, pages 22-23 [11] Chrontel, page 4 [12] TI, page 5 [13] JAE, page 1 [14] Toradex, page 12 [15] Toradex, page 13, Table 3 [16] http://referencedesigner.com/cal/cal_02.php [17] https://en.wikipedia.org/wiki/Ounce#International_avoirdupois_ounce [18] https://en.wikipedia.org/wiki/Copper [19] https://en.wikipedia.org/wiki/Densities_of_the_elements_(data_page) [20] TI, page 8 [21] Toradex, pages 18-19, Figure 16 [22] https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pair… [23] TI, page 9 Bibliography: Chrontel: Application Note AN-B026, "PCB Layout and Design Guide for CH7101A HDMI to VGA Converter", http://www.chrontel.com/media/Application%20Notes/AN-B026%20Rev0.2.pdf Japan Aviation Electronics Industry, Ltd. (JAE): "HDMI Standard Type D HDMI Micro Connector: DC3 Series", Connector MB-0233-2, May 2013, http://www.jae.com/z-en/pdf_download_exec.cfm?param=MB-0233-2E_DC3.pdf Texas Instruments (TI): "HDMI Design Guide", High-Speed Interface Products, June 2007, http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments… Toradex: "Layout Design Guide", v1.0, 14 April 2015, http://docs.toradex.com/102492-layout-design-guide.pdf

4 14

Re: [Arm-netbook] bunnie about riscv - NSA in today's CPUs
by dumblob 04 Aug '17

04 Aug '17

https://brmlab.cz/user/jenda/intel One evil HW comparator and we're all screwed :-( 2017-06-11 17:07 GMT+02:00 Neil Jansen <njansen1(a)gmail.com>: > On Sat, Jun 10, 2017 at 11:54 AM, <ronwirring(a)safe-mail.net> wrote: > >> It was very informative. A lot of the technical matter I did not > understand. > > This was a GREAT talk. Thanks for the link. > >> Can you explain: >> 23.04 The 2 lowermost boxes? > > 1) PDK / Foundries. The factories in which the chips are made in. They're > not open. They're proprietary and there's a implication of trust. > 2) Equipment / Raw Materials. The equipment that makes the chips and the > raw materials that go into the chips. All a very cloudy and and murky area > that is not open, and very proprietary. > > He's basically saying that those that want *100%* open source hardware > would require infinite recursion down to the raw components, which is > impossible. That's the whole point of the talk. The 'impedance mismatch' > thing is a sort of metaphor to describe the unrealistic expectations of > those idealists that want 100% open source hardware. He's saying it cannot > happen today. And BTW I've met Bunnie on several occasions, he's legit, > and you can trust what he's saying to be technically correct. He's the > real deal. > >> What is a stepper? > > A stepper motor. That is, do you trust the motors that move the machines > that made the integrated circuits? > >> What is fuse? > > See this link: > https://electronics.stackexchange.com/questions/1262/what-are-atmel-fuses > > >> 25.15 The 4 lowermost boxes? > > * BIOS > * Firmware > * Hidden / fused silicon blocks - Blocks of silicon on the chip that aren't > usually turned on, but are there. Lots of big vendors are doing this now: > Intel, AMD, Nvidia, and it's anyone's guess as to what their real purpose > is. That leads to conspiracy theories, as Bunnie said. This is a problem > because if you put a chip like this into an open source laptop, it begs the > question of what would happen if something turned on that section and > started execution code from it? Nobody will know until (A) documentation > is leaked from the company or (B) someone reverse engineers it. Basically > if you use anything application processor chip made in the last 5-10 years, > you probably have some hidden / fused silicon blocks doing god knows what. > * Pre-boot microcode - Microcode (https://en.wikipedia.org/wiki/Microcode) > that executes BEFORE your computer boots. This is a big deal, because > everything that happens after this point can be considered suspect. > (similar to how a boot virus would spread because it executes first). > * IP industry practices - Intellectual property used by silicon > manufacturers that are not open. What he's saying is, say that you're a > silicon vendor and you just bought a intellectual property from ARM to make > an ARM chip. They're giving you HDL (hardware description language) and > netlists (a large list of the connections to be made in the die), and guess > what, they gave them to you encrypted so that their intellectual property > is safe. You (the guy that runs a third party chip factory) cannot review > or inspect the intellectual property that ARM gave you. The point here is > that unless you're using an open source (RISC-V, etc) core, then using an > ARM isn't really 100% open source hardware. > * Mask trojans & glitches - These are malicious things in the CPU die > itself, that even if you were looking at the silicon die under a microscope > and studying it, you'd still completely miss it. Very nasty but they > exist. Hackaday.com has a lot of interesting articles that break these > sort of things down in layman's terms. Very interesting. Basically > because these exist, there's no way to know that you are really executing > what you think you are executing unless you built the foundry and > supervised the chips being made, and analyzed everything that went into the > manufacture of them. It's a trust problem. > > These are all highly complex subjects that hardware engineers like Bunnie > deal with a lot, and other (I'll say idealist) software guys probably have > never thought of. They're important in that when you realize that they're > there, you will then understand how silly wanting 100% open hardware really > is. It's a huge problem that hardly anybody is trying to fix. > > > Recently the 6502 was completely dissected and recreated, so that's one of > the only fully documented (and I'd say fully trusted) cores out there > today. And that was made probably before I was born. Everything since > that should be assumed to be compromised and < 100% open. Oh, and even > then, the 6502 would have to hook up to OTHER chips like flash, RAM, and > whatever generates the video and handles the peripherals. Those have not > been completely dissected, and could be suspect. Do you see what Bunnie > means now? That's the impedance mismatch. > > > P.S. my apologies to LKCL and others, I don't have a plain text email > client. > _______________________________________________ > arm-netbook mailing list arm-netbook(a)lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook(a)files.phcomp.co.uk

2 1

HDMI High-Frequency Layout: Libre Field Solvers
by Richard Wilbur 04 Aug '17

04 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Libre Field Solvers[24] (Free Computational Electromagnetic Modeling Codes list at the Clemson University Vehicular Electronics Laboratory) Name License URL Angora GPL http://www.angorafdtd.org/ atlc - Arbitrary Transmission Line Calculator (for transmission lines and directional couplers) GPL http://atlc.sourceforge.net/ Elmer GPL/LGPL https://www.csc.fi/web/elmer EMAP BSD-esque? http://www.cvel.clemson.edu/modeling/EMAG/EMAP/emap5/ FastImp MIT http://www.rle.mit.edu/cpg/fastimp.htm GSVIT GPL http://gsvit.net/ MEEP GPL http://ab-initio.mit.edu/wiki/index.php/Meep MMTL - Multilayer Multiconductor Transmission Line GPL http://mmtl.sourceforge.net/ openEMS GPLv3+ http://openems.de/start/index.php OpenMaXwell GPLv3+ http://openmax.ethz.ch/ (runs on Linux under wine) pdnMesh GPLv2 http://pdnmesh.sourceforge.net/ Puma-EM GPLv2 https://sourceforge.net/projects/puma-em/ WOLFSIM GPLv2 https://sourceforge.net/projects/wolfsim/ xfemm - Cross-platform Finite Element Method Magnetics Aladdin Free Public License, Apache Licence v2.0 https://sourceforge.net/projects/xfemm/ These are the field solvers that had what I understood to be a libre license from Clemson's list. There are fourteen packages here that made the cut and align with the goals of this project. I have no familiarity nor expertise with any of them or I would be in a better position to make a recommendation. It would be useful to be able to model not only the differential microstrip structure with ground shield traces and vias, but also signal vias for tuning them to transparency. References: [24] http://www.cvel.clemson.edu/modeling/EMAG/free-codes.html

1 0

HDMI High-Frequency Layout: Goals
by Richard Wilbur 03 Aug '17

03 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Goals The portion of the HDMI transmission path contained on the PCB has several goals: 1. Support all operating modes of the HDMI v1.4 interface of which the A20 chip is capable (clock up to 340MHz, data up to 3.4GHz). 2. Match the characteristic impedance of the rest of the HDMI transmission path (connectors, cable, and receiver) to minimize reflections and deliver a recoverable/decodeable signal to the receiver. [low distortion, sufficient amplitude] 3. Minimize radiated Electro-Magnetic Interference which could adversely effect other circuits on the EOMA68-A20 or in its surroundings, or exceed regulatory limits of concerned agencies: FCC, CSA, etc. 4. Minimize sensitivity to EMI from other circuits on the EOMA68-A20 and its surroundings. Of these goals careful layout realizing a microstrip geometry helps with minimizing EMI radiation and sensitivity, while impedance matching both minimizes signal reflections which distort the transmitted signal and delivers the signal energy to the intended receiver.

1 0

Re: [Arm-netbook] HDMI High-Frequency Layout: Introduction
by Andrew Bolin 02 Aug '17

02 Aug '17

> > Date: Tue, 1 Aug 2017 03:45:19 -0600 > From: Richard Wilbur <richard.wilbur(a)gmail.com> > To: Eco-Conscious <arm-netbook(a)lists.phcomp.co.uk> > Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction > Message-ID: > <CAC4=CAENg63=p1CfYFE6QPVp+g1-SRnznHbXTsVcNkLXh=EY9A@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > This is a discussion of the considerations when designing and > executing a PCB layout containing high-frequency signal > traces--specifically in this case HDMI. It is being published to the > [arm-netbook] mailing list in several sections dealing with related > topics. The original was created in Open Document Text and I have > dumped it into Unicode Text in order to accommodate the mailing list. > Great collection of info Richard. I'd appreciate a copy of the original file to keep for my reference, if/when you have a chance to upload it somewhere (I'm guessing I'm not the only one?), or email it direct and I can find a place to share it.

3 2

HDMI High-Frequency Layout: Timing
by Richard Wilbur 01 Aug '17

01 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Timing 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 sense. 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 pairs.[7] 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 trace.[9] 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] References: [3] Toradex, page 38 [4] TI, page 4 [5] Chrontel, page 5 [6] https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter… [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_f… [9] Toradex, page 17, Figures 12 & 13 [10] Toradex, pages 22-23 Bibliography: http://www.chrontel.com/media/Application%20Notes/AN-B026%20Rev0.2.pdf http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments… http://docs.toradex.com/102492-layout-design-guide.pdf

3 8

HDMI High-Frequency Layout: Speed of Propagation
by Richard Wilbur 01 Aug '17

01 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Speed of Propagation First let's calculate the speed of electromagnetic wave propagation in a microstrip differential pair on our circuit board. Then we can use that speed to convert the timing tolerances of the HDMI standard into distance tolerances which will guide our priorities in routing the differential pairs. Electromagnetic waves travel at the speed of light. But since the electromagnetic fields of these signals extend between the conductors into both air and the FR-4 substrate of our printed circuit board (PCB), they will not travel at the same speed as if they were travelling through a vacuum. Speed of light in a vacuum: c = 3.00e8 m/s Speed of light in some other substance: v(wave travelling in substance) = c / sqrt(relative permittivity of substance) Since the electromagnetic waves in question propagate partly in air and partly in the PCB substrate (FR-4), we estimate their governing permittivity to be between that of air and FR-4. Speed of propagation for signals conducted in differential microstrip on the PCB: relative permittivity of FR-4 = 4.4 [1] relative permittivity of air = 1 v(in FR-4) = 3.00e8 / sqrt(4.4) = 1.43e8 m/s v(partly in FR-4, partly in air) ~= 3.00e8 / sqrt(4) = 1.5e8 m/s = 150um/ps[2] References: [1] https://en.wikipedia.org/wiki/FR-4 [2] Toradex, page 21 Bibliography: http://docs.toradex.com/102492-layout-design-guide.pdf

1 0

HDMI High-Frequency Layout: Introduction
by Richard Wilbur 01 Aug '17

01 Aug '17

This is a discussion of the considerations when designing and executing a PCB layout containing high-frequency signal traces--specifically in this case HDMI. It is being published to the [arm-netbook] mailing list in several sections dealing with related topics. The original was created in Open Document Text and I have dumped it into Unicode Text in order to accommodate the mailing list. Please let me know if you have any trouble reading the format and I will attempt to remedy the problem. I am releasing the first two sections before I sleep--the remainder after I sleep.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook August 2017