From richard.wilbur at gmail.com Tue Aug 1 05:53:51 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 31 Jul 2017 22:53:51 -0600 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels Message-ID: Luke, Have you considered using the Audio Return channel in HDMI v1.4 to send digital multi-channel sound back to the EOMA68-A20? How about the Ethernet channel (also in HDMI v1.4)? Does the processor support these? They are optional capabilities of HDMI v1.4 and I only ask because it would change the routing. Sincerely, Richard From lkcl at lkcl.net Tue Aug 1 06:13:13 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 06:13:13 +0100 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Aug 1, 2017 at 5:53 AM, Richard Wilbur wrote: > Luke, > > Have you considered using the Audio Return channel in HDMI v1.4 to > send digital multi-channel sound back to the EOMA68-A20? How about > the Ethernet channel (also in HDMI v1.4)? CEC etc i believe is supported i can't remember the details, it's covered by the processor and is somewhere in the datasheet. certainly i know there's an hdmi audio kernel module for sound playback in the sunxi-3.4 kernel. so *i'm* not quotes considering it quotes - if it's there and there's a linux kernel module it's there, people can compile it and use it. l. From richard.wilbur at gmail.com Tue Aug 1 06:21:07 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 31 Jul 2017 23:21:07 -0600 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: I forgot to cite some sources: Audio Return channel[1] Claims to be able to carry the signals normally routed over an S/PDIF cable from the video signal receiver (sink) back to the video signal transmitter (source). Ethernet channel[2] Offers up to 100Mb/s bandwidth networking. HDMI Specification Availability: "HDMI Specification Ver.1.4b and the Compliance Test Specification Ver.1.4b (CTS 1.4b), released on October 11, 2011, are available for download only by Licensed HDMI Adopters." [3] "The HDMI Specification Ver. 1.3a is available at no charge. To download this version of the HDMI specification, please complete the form that follows. The HDMI Specification Ver. 1.4a is available to HDMI Adopters via the Adopter extranet. Adopters can click here to log into the Adopter Extranet." Adopter Registration: "Licensing Option Please select which HDMI Adopter agreement is appropriate for your company. Manufacturers of End Products that will include HDMI: Ten thousand fixed annual licensing fee plus royalty Five thousand annual licensing fee plus $1.00 administration fee per licensed product plus royalty" I'd love to download the specification but they have it behind a signed agreement + steep pay wall. References: [1] http://www.hdmi.org/manufacturer/hdmi_1_4/arc.aspx [2] http://www.hdmi.org/manufacturer/hdmi_1_4/hec.aspx [3] http://www.hdmi.org/manufacturer/specification.aspx [4] http://www.hdmi.org/manufacturer/adopter_registration.aspx From lkcl at lkcl.net Tue Aug 1 06:29:52 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 06:29:52 +0100 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Aug 1, 2017 at 6:21 AM, Richard Wilbur wrote: > Audio Return channel[1] > Claims to be able to carry the signals normally routed over an S/PDIF > cable from the video signal receiver (sink) back to the video signal > transmitter (source). yes. there exists a kernel module. absolutely no information is available about how it works.... except as can be read in the source code. > I'd love to download the specification but they have it behind a > signed agreement + steep pay wall. yyeah.. not hugely gonna worry about it. if it works it works, if it doesn't it doesn't. l. From richard.wilbur at gmail.com Tue Aug 1 06:44:01 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 31 Jul 2017 23:44:01 -0600 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: On Mon, Jul 31, 2017 at 11:13 PM, Luke Kenneth Casson Leighton wrote: > CEC etc i believe is supported i can't remember the details, it's > covered by the processor and is somewhere in the datasheet. certainly > i know there's an hdmi audio kernel module for sound playback in the > sunxi-3.4 kernel. Sorry, I explain things well enough. Sound playback normally refers to sound output from the kernel to D/A, amplifier, and speakers. Same direction as video playback: from computer to monitor. CEC: Consumer Electronics Control Allows devices to pass control information around. Say you have a remote control for your television that has "Play" and "Pause" buttons on it, for instance. Through CEC the commands could be sent from your television to the EOMA68-A20 card via the HDMI cable and software there could respond appropriately to the events. ARC: Audio Return Channel The Audio Return Channel supports sending digital multi-channel sound upstream (for input to the computer). This would allow recording, mixing, special effects, etc. > so *i'm* not quotes considering it quotes - if it's there and there's > a linux kernel module it's there, people can compile it and use it. >From the sound of things, CEC was there from the beginning and ARC is new in v1.4 but doesn't require circuit changes on the HDMI transmitter PCB to accommodate. ARC does require support in the HDMI block/subsystem of the SoC. On the other hand, if we plan to support HEC (HDMI Ethernet Channel) it requires us to route one more pair of signals as a differential pair. From fivepointpalmexplodingheart at gmail.com Tue Aug 1 06:45:36 2017 From: fivepointpalmexplodingheart at gmail.com (Andrew Bolin) Date: Tue, 1 Aug 2017 15:45:36 +1000 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels Message-ID: > > so *i'm* not quotes considering it quotes - if it's there and there's > a linux kernel module it's there, people can compile it and use it. > > l. > Can't use it if the pin has no connection to the CPU! In the last screenshots I saw ( http://hands.com/~lkcl/eoma/a20_hdmi_review/scrn2.png ), pin 2 HEAC+ (ethernet/ARC) is not connected to anything. Pin 1 (HEAC- & HPD) does go somewhere, but it's of no use for these functions by itself. CEC does seem to be routed and is mentioned on the A20 info page. No SBC that I've seen actually uses these functions (unfortunately). - Andrew. From lkcl at lkcl.net Tue Aug 1 06:46:48 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 06:46:48 +0100 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 6:44 AM, Richard Wilbur wrote: > On the other hand, if we plan to support HEC (HDMI Ethernet Channel) > it requires us to route one more pair of signals as a differential > pair. the micro-hdmi connector's pins are entirely packed out. i know that there's no extra pins available (there's only 19, 1 of them unused), and there are definitely no extra pads coming out from the A20 which could be identified as HEC. l. From lkcl at lkcl.net Tue Aug 1 06:47:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 06:47:50 +0100 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 6:45 AM, Andrew Bolin wrote: >> >> so *i'm* not quotes considering it quotes - if it's there and there's >> a linux kernel module it's there, people can compile it and use it. >> >> l. >> > > Can't use it if the pin has no connection to the CPU! > > In the last screenshots I saw ( > http://hands.com/~lkcl/eoma/a20_hdmi_review/scrn2.png ), pin 2 HEAC+ > (ethernet/ARC) is not connected to anything. ... because the A20 doesn't have anything to connect it to. l. From richard.wilbur at gmail.com Tue Aug 1 06:57:54 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 31 Jul 2017 23:57:54 -0600 Subject: [Arm-netbook] HDMI v1.4 Audio Return and Ethernet channels In-Reply-To: References: Message-ID: On Mon, Jul 31, 2017 at 11:45 PM, Andrew Bolin wrote: > Can't use it if the pin has no connection to the CPU! > > In the last screenshots I saw ( > http://hands.com/~lkcl/eoma/a20_hdmi_review/scrn2.png ), pin 2 HEAC+ > (ethernet/ARC) is not connected to anything. Pin 1 (HEAC- & HPD) does go > somewhere, but it's of no use for these functions by itself. I agree, sounds like HEAC (HDMI Ethernet/Audio Return Channel) won't work as we don't have the pair connected to the CPU and that signal is HEC -- differential, ARC -- single-ended. On the other hand HPD (Hot-Plug Detect) should work. > CEC does seem to be routed and is mentioned on the A20 info page. > > No SBC that I've seen actually uses these functions (unfortunately). We'll have to see if we can make it work. From richard.wilbur at gmail.com Tue Aug 1 10:45:19 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 03:45:19 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction Message-ID: 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. From lkcl at lkcl.net Tue Aug 1 10:47:24 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 10:47:24 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 10:45 AM, Richard Wilbur wrote: > This is a discussion of the considerations when designing and > executing a PCB layout containing high-frequency signal > traces--specifically in this case HDMI. thanks richard. From richard.wilbur at gmail.com Tue Aug 1 10:51:53 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 03:51:53 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction In-Reply-To: References: Message-ID: 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 From richard.wilbur at gmail.com Tue Aug 1 10:53:34 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 03:53:34 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Speed of Propagation Message-ID: 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 From richard.wilbur at gmail.com Tue Aug 1 10:57:59 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 03:57:59 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing Message-ID: 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-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 Bibliography: http://www.chrontel.com/media/Application%20Notes/AN-B026%20Rev0.2.pdf http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-138-01-00-00-10-65-80/Texas-Instruments-HDMI-Design-Guide.pdf http://docs.toradex.com/102492-layout-design-guide.pdf From lkcl at lkcl.net Tue Aug 1 11:29:24 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 11:29:24 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: ok reading in full, cutting extraneous, answering only with confirmation. On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur 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. From mike.valk at gmail.com Tue Aug 1 14:51:01 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Tue, 1 Aug 2017 15:51:01 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: 2017-08-01 12:29 GMT+02:00 Luke Kenneth Casson Leighton : > ok reading in full, cutting extraneous, answering only with confirmation. > > On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur > 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 Between via's the length should be matched right? Length mismatch should be solved as soon as possible to accommodate eddy-currents right? Found a nice post from TI https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias > > so thank you - much to correct and think about. really appreciated > you finding all this stuff richard. > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Tue Aug 1 15:11:21 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 1 Aug 2017 15:11:21 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 2:51 PM, mike.valk at gmail.com wrote: [trimming a huge amount of unnecessary context on your behalf, mike... hint, hint....] >> 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 > > Between via's the length should be matched right? Length mismatch > should be solved as soon as possible to accommodate eddy-currents > right? yes. the toradex article explains it very well, also mentions the importance of symmetry (as does the TI post). > Found a nice post from TI > https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias nice! dang, above 10ghz the thickness of the via starts to matter and needs to be drilled out, post-production. dang. *sigh* unfortunately symmetry is not completely achievable with the drastically-reduced amount of space available. the HDMI signals come out right at the bottom of the board. l. > >> >> so thank you - much to correct and think about. really appreciated >> you finding all this stuff richard. >> >> l. >> >> _______________________________________________ >> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >> Send large attachments to arm-netbook at files.phcomp.co.uk > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From mike.valk at gmail.com Tue Aug 1 15:25:13 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Tue, 1 Aug 2017 16:25:13 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: 2017-08-01 16:11 GMT+02:00 Luke Kenneth Casson Leighton : > On Tue, Aug 1, 2017 at 2:51 PM, mike.valk at gmail.com wrote: > > [trimming a huge amount of unnecessary context on your behalf, mike... > hint, hint....] My apologies to all. > >>> 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 >> >> Between via's the length should be matched right? Length mismatch >> should be solved as soon as possible to accommodate eddy-currents >> right? > > yes. the toradex article explains it very well, also mentions the > importance of symmetry (as does the TI post). > >> Found a nice post from TI >> https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias > > nice! dang, above 10ghz the thickness of the via starts to matter > and needs to be drilled out, post-production. dang. > > *sigh* unfortunately symmetry is not completely achievable with the > drastically-reduced amount of space available. the HDMI signals come > out right at the bottom of the board. That might not be to problematic. I've search to the net for talk about running tracks on top of each other. It keeps hunting me. And found a knowledable awnser. http://www.sigcon.com/Pubs/news/2_30.htm On of the things mentioned is that the differential signals might not be quite aligned to begin with. So achieving symmetry might look nice on but can only give limited help in minimizing emission and pickup. > > l. From doark at mail.com Tue Aug 1 19:59:10 2017 From: doark at mail.com (David Niklas) Date: Tue, 1 Aug 2017 14:59:10 -0400 Subject: [Arm-netbook] DIY laptop part 2: camera Message-ID: <20170801145910.6f6e5520@ulgy_thing> Hello, I wanted to add a camera onto my laptop. I located two suppliers: blisscomputers.net e-consystems.com My problem is a lack of experience. I know how many MP and where the camera should start focusing at (focal length at 30CM). I don't know how long a reasonable MIPI-CSI cable can be and I found out from one of the people that a length of 50CM (my original plan). Was too long so now I have to devise a solution... My other problem is that I don't know what the f-number aught to be. My original idea for using the camera is this: lid | Lens Camera | lid | screen screen screen ~~~~~~ screen screen screen Hinge-casing-casing~~~~~~casing Then I would simple flip the camera over the top and then I could have it face me and do video conferencing or whatever. Anyone have experience with this? Thanks, David From tzafrir at cohens.org.il Tue Aug 1 20:14:11 2017 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Tue, 1 Aug 2017 21:14:11 +0200 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170728103722.65a5d2c3@ulgy_thing> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> Message-ID: <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark at mail.com wrote: > And there were times when those on the Devuan mailing list would seem to > head towards the "I hate Poettering" side, but we would all engage them > (except, maybe me because I would miss most of the discussion), to > thinking about the enemy we were fighting, which was systemd, not > Poettering, and it would work 100% of the time, at least as far as I > remember. I thought you were out to write a good system, and not up against another software. -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From richard.wilbur at gmail.com Tue Aug 1 20:31:01 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 13:31:01 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 4:29 AM, Luke Kenneth Casson Leighton wrote: > ok reading in full, cutting extraneous, answering only with confirmation. Great plan! > On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur > wrote: > >> [...] 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. I figured this wasn't going to be a problem and so I mentioned it to ease the tenor of the discussion. >> 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. I wouldn't sweat too much breaking the 100mil target by hitting 275mil. I didn't quite organize that very well. Here's what it should look like. Notice that requirements for the standard (HDMI v1.4, attested by both Chrontel and TI) are first and suggestions are specifically introduced with the verb, "suggests": Inter-pair skew: (Requirements for HDMI v1.4) Chrontel, TI: T(Pixel) = 1/(pixel clock) = 2.94ns Skew(Inter-Pair) < 0.20 * T(Pixel)[4][5] = 588ps => Δl < v * Δt = 88.2mm ~= 3470mil Toradex suggests clock-data skew: Δt <150ps[3] => Δl < v * Δt = 22mm ~= 870mil Chrontel suggests matching between any two pairs be within 100mil.[5] => Δl < 100mil => Δt < Δl / v = 2540um / (150um/ps) = 17ps Intra-pair skew: (Requirements for HDMI v1.4) Chrontel, TI: 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 Toradex suggests: Δt < 5ps[3] => Δl < v * Δt = 0.75mm ~= 30 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.) >> 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. Happy coincidence! >> Intra-pair skew: (Requirements for HDMI v1.4) [...] >> (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! I'm going to guess that is probably due to the geometry of the differential traces where if the spacing is 5mil then a 5mil intra-pair skew lengthens the wavefront by sqrt(2) and it is now turned 45 degrees from the intended direction of propagation. >> 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. This section is mostly here to talk about the 45 degree versus 90 degree bends which is important for any high-frequency trace, be it single-ended or differential. The last part about proportions for meanders concerns single-ended traces (like if you needed it for CEC or some other *non-differential* signal). The proportions for differential meanders are down in the next section. >> 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 I'm glad you're seeing good things. Matching should happen on the same side of the via (same segment) as the skew happens. > so thank you - much to correct and think about. really appreciated > you finding all this stuff richard. I wanted to present the parameters and principles so that you can make more well-informed choices. You don't have errors to correct but better information on which to base your choices. From richard.wilbur at gmail.com Tue Aug 1 20:49:21 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 13:49:21 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 7:51 AM, mike.valk at gmail.com wrote: > 2017-08-01 12:29 GMT+02:00 Luke Kenneth Casson Leighton : >> 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 > > Between via's the length should be matched right? Length mismatch > should be solved as soon as possible to accommodate eddy-currents > right? Correct on both counts. > Found a nice post from TI > https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias Thanks for the link to an interesting article. Thankfully we are well below 10GHz on this interface and have 0 stub length as our signals traverse the via all the way from top to bottom or vice versa. We do have the option to specifically adjust the antipad or keepout sizes around our vias. More discussion of this topic in the upcoming section on impedance. From richard.wilbur at gmail.com Tue Aug 1 20:58:43 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 13:58:43 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 8:11 AM, Luke Kenneth Casson Leighton wrote: > On Tue, Aug 1, 2017 at 2:51 PM, mike.valk at gmail.com wrote: >> Found a nice post from TI >> https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias > > nice! dang, above 10ghz the thickness of the via starts to matter > and needs to be drilled out, post-production. dang. Since we're not trying to support HDMI post v1.4 we don't have signals above 10GHz on this interface at least. Thankfully none of the signal trace vias need to be drilled out since our signals always traverse the whole via. > *sigh* unfortunately symmetry is not completely achievable with the > drastically-reduced amount of space available. the HDMI signals come > out right at the bottom of the board. Hopefully most of what we can't accomplish with symmetry we can remedy with creativity. From richard.wilbur at gmail.com Tue Aug 1 21:58:24 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 14:58:24 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Timing In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 8:25 AM, mike.valk at gmail.com wrote: > 2017-08-01 16:11 GMT+02:00 Luke Kenneth Casson Leighton : >> *sigh* unfortunately symmetry is not completely achievable with the >> drastically-reduced amount of space available. the HDMI signals come >> out right at the bottom of the board. > > That might not be to problematic. I've search to the net for talk > about running tracks on top of each other. It keeps hunting me. And > found a knowledable awnser. > > http://www.sigcon.com/Pubs/news/2_30.htm Thanks for the interesting read. It is an intriguing geometry and looks like it uses vertical space more than horizontal. I suppose we could make use of a 2-D EM field solver to figure out design parameters such as trace width, which layers to use (how much dielectric thickness between traces), and horizontal offset from other traces. > On of the things mentioned is that the differential signals might not > be quite aligned to begin with. So achieving symmetry might look nice > on but can only give limited help in minimizing emission and pickup. I guess to get better than that we would have to characterize the differential signal sources and, if they have a repeatable output skew, then design the traces with that initial skew from the source. I have a suspicion that the important goals for this project include: 1. operational HDMI v1.4 interface supporting all operating modes of which the A20 chip is capable (clock up to 340MHz, data up to 3.4GHz) 2. EMI radiation below regulatory limits for all concerned agencies: FCC, CSA, EU, etc. 3. EMI sensitivity small enough to avoid disrupting proper operation of all systems of the EOMA68-A20. Hopefully the drivers on the chip are aligned well enough to fit into the skew budget for HDMI operation and we are able to execute a PCB trace geometry to support all three goals. (I'm willing to bet on it!) From njansen1 at gmail.com Tue Aug 1 22:14:02 2017 From: njansen1 at gmail.com (Neil Jansen) Date: Tue, 1 Aug 2017 17:14:02 -0400 Subject: [Arm-netbook] DIY laptop part 2: camera In-Reply-To: <20170801145910.6f6e5520@ulgy_thing> References: <20170801145910.6f6e5520@ulgy_thing> Message-ID: On Tue, Aug 1, 2017 at 2:59 PM, David Niklas wrote: > > I don't know how long a reasonable MIPI-CSI cable can be I have some experience with this. We were able to do over 1 meter via an HDMI cable and some adapter boards. The actual distance will depend on a few things. Ideally you want to run the wires as twisted differential pairs, ideally shielded at one end. A ribbon cable isn't perfect but may work. Even if it works, you may be spewing EMI around like crazy. Anecdotally, that happened to the Raspberry Pi Foundation, their MIPI-CSI cable for their camera could only be 50mm or so long; any longer and they wouldn't have been able to pass whatever EMI tests they had to pass. > My other problem is that I don't know what the f-number aught to be. > My original idea for using the camera is this: That completely depends on the size of the sensor, and what you want in the field of view. If you have room for a camera with an M12 lens mount, you can buy a few different focal lengths for cheap and swap them out as you'd like, until you find something that works. If it does not have an M12 lens mount, then you're stuck with whatever choices they have. If you're buying a lens-and-sensor module, then they'll give you the field of view in degrees; in this case, don't even worry about the focal length. The FOV is probably what you're after anyhow, and they should give you this. From hendrik at topoi.pooq.com Tue Aug 1 23:40:36 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 1 Aug 2017 18:40:36 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> Message-ID: <20170801224036.GA15975@topoi.pooq.com> On Tue, Aug 01, 2017 at 09:14:11PM +0200, Tzafrir Cohen wrote: > On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark at mail.com wrote: > > > And there were times when those on the Devuan mailing list would seem to > > head towards the "I hate Poettering" side, but we would all engage them > > (except, maybe me because I would miss most of the discussion), to > > thinking about the enemy we were fighting, which was systemd, not > > Poettering, and it would work 100% of the time, at least as far as I > > remember. > > I thought you were out to write a good system, and not up against > another software. The other software was the immediate reason the system wasn't good. -- hendrik From fivepointpalmexplodingheart at gmail.com Wed Aug 2 00:38:20 2017 From: fivepointpalmexplodingheart at gmail.com (Andrew Bolin) Date: Wed, 2 Aug 2017 09:38:20 +1000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction Message-ID: > > Date: Tue, 1 Aug 2017 03:45:19 -0600 > From: Richard Wilbur > To: Eco-Conscious > Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction > Message-ID: > 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. From richard.wilbur at gmail.com Wed Aug 2 02:21:05 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 1 Aug 2017 19:21:05 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 5:38 PM, Andrew Bolin wrote: > 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. I'm glad you find it useful! I'm noticing things to fix as I try to clarify points I neglected to explain sufficiently so it is a work in progress at the moment. I am keeping the source material and trying to update it as I answer questions so I would be happy to share it at some point. Still have a few more sections to publish. Thank you for the suggestion. From auerswal at unix-ag.uni-kl.de Wed Aug 2 08:59:44 2017 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 2 Aug 2017 09:59:44 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction In-Reply-To: References: Message-ID: <20170802075944.GA418@unix-ag.uni-kl.de> Hi, On Tue, Aug 01, 2017 at 07:21:05PM -0600, Richard Wilbur wrote: > On Tue, Aug 1, 2017 at 5:38 PM, Andrew Bolin > wrote: > > 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. > > I'm glad you find it useful! I'm noticing things to fix as I try to > clarify points I neglected to explain sufficiently so it is a work in > progress at the moment. I am keeping the source material and trying > to update it as I answer questions so I would be happy to share it at > some point. Still have a few more sections to publish. Thank you for > the suggestion. Just a suggestion, the Rhombus Tech Wiki (http://rhombus-tech.net/) might be a good place for publishing this. Thanks, Erik -- In the beginning, there was static routing. -- RFC 1118 From richard.wilbur at gmail.com Thu Aug 3 09:50:57 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 02:50:57 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Goals Message-ID: 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. From richard.wilbur at gmail.com Thu Aug 3 12:37:21 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 05:37:21 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance Message-ID: 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 = 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 S min{D} 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-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 [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-pairs-four-things-you-need-to-know-about-vias [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/00-138-01-00-00-10-65-80/Texas-Instruments-HDMI-Design-Guide.pdf Toradex: "Layout Design Guide", v1.0, 14 April 2015, http://docs.toradex.com/102492-layout-design-guide.pdf From lkcl at lkcl.net Thu Aug 3 14:11:18 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 3 Aug 2017 14:11:18 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 12:37 PM, Richard Wilbur wrote: > 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. i know from DDR3 that they can change (dynamically) the end-impedance both on the SoC and in the DDR3 RAM ICs. it means you can stick with a particular track width and spacing then have the SoC and DDR3 ICs adjust each end to suit. > Toradex mentions the lower impedance between wide traces and the > reference plane causing impedance mismatch at large pads for > components and connectors.[21] yehyeh. fortunately the ones on the DC3 connector are tiny. i think you're saying we're ok here with 5mil track, 5mil spacing, and lots and lots of ground vias. i can't get them in between the diff-pairs though. l. From richard.wilbur at gmail.com Thu Aug 3 14:59:15 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 07:59:15 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 7:11 AM, Luke Kenneth Casson Leighton wrote: > On Thu, Aug 3, 2017 at 12:37 PM, Richard Wilbur > wrote: >> 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. > > i know from DDR3 that they can change (dynamically) the end-impedance > both on the SoC and in the DDR3 RAM ICs. it means you can stick with > a particular track width and spacing then have the SoC and DDR3 ICs > adjust each end to suit. Interesting trick with the SoC and DDR3 RAM ICs. What I was talking about is how we can change the single-ended impedance of our design while holding the differential impedance at 100 Ohm and what effect that has on trace width and spacing. If we reduce the trace width and spacing but maintain 100 Ohm differential impedance, our single-ended impedance goes up! It's not exactly rocket science. When we narrow the traces we have less capacitive coupling to ground so you might expect our single-ended impedance would rise. >> Toradex mentions the lower impedance between wide traces and the >> reference plane causing impedance mismatch at large pads for >> components and connectors.[21] > > yehyeh. fortunately the ones on the DC3 connector are tiny. > > i think you're saying we're ok here with 5mil track, 5mil spacing, > and lots and lots of ground vias. i can't get them in between the > diff-pairs though. Close. What I am saying is that the DC3 connector pads and spacing actually look pretty close to row 2 of the table (55 Ohm single-ended impedance) for 100 Ohm differential trace geometries. So I don't think the DC3 lands will cause a large impedance discontinuity. In other words no need to obstruct the ground reference plane from under the DC3 lands. What I said earlier is that I would recommend the following geometry for the transmission lines: trace width = 6.5mil trace spacing = 5mil offset from other copper in the same layer >= 10mil (ground shield trace, other differential pair, etc.) We'll primarily need ground vias where the signal changes layers and thus the return current needs to change from one ground reference layer to the other. If we do a pretty decent job of squashing the skew and the differential drivers on the chip give us a signal with little common-mode energy to start with, we won't need much of any shielding between pairs. Since the ground shield will be asymmetric (only on one side of a pair) I would recommend keeping it as far away as possible so it will have less asymmetric effect on the impedance. I have two more sections in mind: Libre Field Solvers and Recommendations (Specific to this Layout). The first is more than half researched and written. I think it can be finished in another couple hours. The second is a little more fluid as I plan to make some recommendations/suggestions and ask some questions which will allow me to refine those recommendations or suggestions. From lkcl at lkcl.net Thu Aug 3 16:28:29 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 3 Aug 2017 16:28:29 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 3, 2017 at 2:59 PM, Richard Wilbur wrote: > What I said earlier is that I would recommend the following geometry > for the transmission lines: > trace width = 6.5mil there's not enough space. when i said "there's not enough space" i *really meant*, "there's not enough space". it *might* be possible to increase to 5.1 mil but i think you'd agree it would not be worth it. the reason that there's not enough space is because: the processor is only about 4.5mm away from the edge of the board. this used to be only 3.5mm. there is no way to further increase the width of the board. there is no way that i am moving the processor. or the DDR3 RAM ICs. the 24mhz XTAL is *right* next to the damn HDMI signals. as it's that close, it blocks layer 1. moving the XTAL to layer 6 is a bad idea (vias) but even if you did that it *still* would not help... because the PMIC components are in the way on layer 1 further down the board. the space that would normally be used to drop the HDMI signals onto layer 6 immediately they come out the vias is not available because there are tracks on both layer 3 and layer 6 which are in the way (and cannot be routed anywhere else) ok i did a video explaining: https://youtu.be/vFbzAmLSHPY l. From vincent.legoll at gmail.com Thu Aug 3 16:59:25 2017 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Thu, 3 Aug 2017 17:59:25 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: Hello, does all that means HDMI output will be flakey ? -- Vincent Legoll From richard.wilbur at gmail.com Thu Aug 3 20:04:18 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 13:04:18 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 9:28 AM, Luke Kenneth Casson Leighton wrote: > On Thu, Aug 3, 2017 at 2:59 PM, Richard Wilbur wrote: > >> What I said earlier is that I would recommend the following geometry >> for the transmission lines: >> trace width = 6.5mil > > there's not enough space. when i said "there's not enough space" i > *really meant*, "there's not enough space". it *might* be possible to > increase to 5.1 mil but i think you'd agree it would not be worth it. > > the reason that there's not enough space is because: [...] Thanks for the explanation. Sorry, I didn't remember how tight things were. I was thinking about how we now have more space--just not that much more space. So, I ran some numbers the other direction through the equations to see what impedance we can expect from the connector lands and smaller trace sizes without smaller trace separation: The good news is it looks like we are still within the +/-15% of 100 Ohm. I'll explain more later. > ok i did a video explaining: https://youtu.be/vFbzAmLSHPY Thanks for the video, I watched the first 55s and thus this reply. I'll finish watching and then tie up loose ends. From dumblob at gmail.com Thu Aug 3 20:40:05 2017 From: dumblob at gmail.com (dumblob) Date: Thu, 3 Aug 2017 21:40:05 +0200 Subject: [Arm-netbook] bunnie about riscv - NSA in today's CPUs Message-ID: 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 : > On Sat, Jun 10, 2017 at 11:54 AM, 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 at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From pablo at parobalth.org Thu Aug 3 21:38:02 2017 From: pablo at parobalth.org (Pablo Rath) Date: Thu, 3 Aug 2017 22:38:02 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170728110816.03497692@ulgy_thing> References: <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> Message-ID: <20170803203802.GA5217@pabbook> On Fri, Jul 28, 2017 at 11:08:16AM -0400, doark at mail.com wrote: > On Tue, 11 Jul 2017 12:10:21 +0200 > Pablo Rath wrote: > > On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote: > > > On Thu, 6 Jul 2017 13:21:56 +0200 > > > > > > Actually, my PC has a kernel fault ... > > > (It's a long story of ntc's evil > > > doing), > > > > Why do you believe that ntc is evil? > > When you boot a normal Linux computer you are presented with a plymouth > boot screen and can hit escape to exit and see the boot messages. > I pocketchip's case you are presented (serendipity), with a boot screen > that somehow references a file listed in /home/chip (I forget the > exact name, it starts with a period), that invokes feh on pocketchip's > logo boot screen from which there is no escape. If you uninstall plymouth > and delete the file that invokes feh in /home/chip you are just presented > with a black screen. > Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch > tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any > reason you are stuck with never being able to fix or diagnose it (though > you might get the last few messages of some error, which you might have > read in full if the screen was not black). > I asked in to forums about how to solve this and it's been weeks without > any answer (I only ever got one, and that user told me not to side load > software (which I explained that I never did or even thought of)). I still don't get why you believe that ntc is evil. In my opinion they are not evil just because the configured PocketChip like you described. Boot messages are small and scroll fast anyway so they would probably don't help you much. ... > > > I've found two faults that cannot be traced without a postmortem and > > > I'm really sick of accidentally causing this thing to manifest said > > > problems and then loosing all the work that I did in between my > > > backup periods. > > > > How can you be sure it is a kernel bug and not another problem? > > Can't, that's why I'm in this predicament. All I know is the last few > messages that say that the kernel is not syncing with the rootfs (and I > have not touched the partition table, or init, or those scripts and files > (like fstab), which would alter the mounting process). > > > Can you > > give us some details. Did you ask on ntc's user forum or did you file a > > bug report > 2. Asked on the forum (I was a bit exasperated at the time since FLOSS > software is no good to me if I can't debug it). I know it sucks to have an obscure computer problem you can not immediately solve but you should not put the blame on FLOSS. It can be a bug, a wrong config, something you did... > Here are the post (hmm, seems that email notification of new replies is > not working: > https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643 > https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525 > User "zwack" gave you good advice to use UART-serial connection. Basically you connect your PocketChip with another computer and can read boot messages there. You will even be able to interact with U-Boot before booting. ... > > > I'm in need of a way to boot PC without flashing the NAND I there a > > > way to do this? So far my search results have been unsuccessful. > > > > 1. Well, you can take your Chip out of the housing and install the > > distro of you choice on a USB-stick and use it as a regular Chip. > > I thought chip could not boot via usb? It is possible altough currently a bit quirky. Have you read my previous email on this list and the linked thread on debian-arm mailing list? > > > 2. Can you get PocketChip into fel-mode without taking it out of the > > enclosure? Ntc's documentation claims it is not possible but there is a > > forum thread about a reboot option into fel-mode. I have no PoketChip > > and leave it up to you to research the answers to this questions. > > I think I could but then what? I know repetitively little about FEL mode > (though I'm willing to learn). > Please read my previous email on this list. Basically you put PocketChip into fel-mode and connect it with another computer. You can then use a "special" version of U-Boot via fel and boot an OS on USB or Debian Installer on USB. > > Another point is if the distro of you choice on a USB-stick will support > > PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you > > have a serial-to-usb-cable to interact with PocketChip? > > I don't think so. But it's confusing when people write things like that > because USB stands for Universal *Serial* Bus (so USB is a serial > cable and no conversion is needed!). > I meant a USB TTL Serial cable (USB to serial converter cables) providing a connection between USB and serial UART interfaces. You should get one as it seems necessary to debug your problems. kind regards Pablo From richard.wilbur at gmail.com Thu Aug 3 23:19:54 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 16:19:54 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 9:59 AM, Vincent Legoll wrote: > does all that means HDMI output will be flakey ? Not if we creatively approach the problems at hand. In other words we are not quitting, and neither are we finished yet. From richard.wilbur at gmail.com Thu Aug 3 23:53:59 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 16:53:59 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 9:28 AM, Luke Kenneth Casson Leighton wrote: > On Thu, Aug 3, 2017 at 2:59 PM, Richard Wilbur wrote: >> What I said earlier is that I would recommend the following geometry >> for the transmission lines: >> trace width = 6.5mil > > there's not enough space. when i said "there's not enough space" i > *really meant*, "there's not enough space". it *might* be possible to > increase to 5.1 mil but i think you'd agree it would not be worth it. > Below find the revised treatment of the latter part of the discussion in light of the facts you enumerated. """ Turns out there isn't enough room to route 6.5mil traces. W S Z(single-ended) Z(differential) 5 5 72.1 111 5.1 5 71.5 111 5.2 5 71.0 110 *Table* of single-ended and differential impedances for geometries constrained by lack of board space. These impedances fall in the +/-15% margin of the nominal 100 Ohm differential impedance [85,115]Ohm. 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 = 5.1mil) c. W < 2H; (W = 5.1mil) < (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. Likewise, we can still meet all the margins if we use 5.1mil trace width and 5mil spacing. 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.2 mil), and the pads are lined up on 0.4mm centers. This implies that the spacing is 0.4mm - (0.23 +/-0.03mm) = 0.17 -/+0.03mm ~= 6.7 +/-1.2mil W S Z(single-ended) Z(differential) 7.9 5.5 58.9 93.0 [DC3 lands, w-tol, s-tol] 7.9 7.9 58.9 100 [DC3 lands, w-tol, s+tol] 9.1 6.7 54.5 89.9 [DC3 lands, nominal] 10.3 5.5 50.7 80.0 [DC3 lands, w+tol, s-tol] 10.3 7.9 50.7 86.5 [DC3 lands, w+tol, s+tol] *Table* of single-ended and differential impedances for geometries constrained by micro HDMI connector lands. These differential impedances are all within JAE's 100 Ohm +/-25% = [75,125] Ohm. The best thing to do here would most likely be to ease the transition from the main trace impedance to the connector impedance over a distance. Where they are close to a via, we could ease up to the via width from the normal trace width over a few mil. 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 an oval shared antipad (on every layer) to reduce parasitic capacitance. 4. Place ground vias next to signal vias to provide low-impedance ground-return paths.[22, Figure 2] """ From richard.wilbur at gmail.com Fri Aug 4 01:24:39 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 18:24:39 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Libre Field Solvers Message-ID: 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 From richard.wilbur at gmail.com Fri Aug 4 03:24:09 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 3 Aug 2017 20:24:09 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations Message-ID: HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Thu 3 Aug 2017 Recommendations for this Layout Source (processor) end: Could we shrink the via pitch between constituents of a differential pair (bring the vias of a differential pair closer to each other) and combine the anti-pads into an oval shape on each layer? This reduces fringing fields and thus parasitic capacitance. I like the ground vias close to the signal vias between differential pairs. It would be lovely to get a ground via close to the via on HTX2P and possibly move the one between HTX2N and HTX1P closer to the signal vias (if the signal vias of pairs can be moved closer with combining the anti-pads). What is the intra-pair skew from the processor lands to the first signal vias? I wonder if we could move the vias on the short lines a little further from the processor and make up some of the skew in that segment before we leave it? Sink (connector) end: Same thing for differential pair vias--HTX0 and HTX2--it would be lovely to shrink the via pitch and combine anti-pads (if possible). Again, I like the ground vias close to the signal vias HTX2P, HTX2N, and HTX0P. It would be lovely to be able to either put a new ground via closer to the signal via on HTX0N or move the one on the ground shield trace closer. I like what you were showing on the video with the signal vias at the connector lands: putting a neck on the trace between the via and the land should dampen the spirits of the solder but not the signals. If we could reduce the signal via pitch by combining anti-pads at the connector, we might be able to move the HTX1P and HTXCN signal vias to the other side of the lands next to the other side of the differential pair, thus equalizing the skew on the segment between the ESD chip pads and the connector pads. If that worked the final touch might be to add a ground via between DC3 pin 10 (GND) and the board edge for return current paths. Other than that, I would try and move as much of the skew compensation close to the source of the skew as possible. I'm not sure what I'm looking at as you mentioned the ground reference planes were solid under the HDMI differential pairs, but it looks like they have voids under the signals in the pictures. Am I seeing a negative, that there are only little strips of conductor in the ground reference plane directly under the high-frequency lines? Neither of these interpretations is very satisfactory, nor do they seem to represent reality. Please let me know what can and can't be done and I will adjust recommendations accordingly. From lkcl at lkcl.net Fri Aug 4 06:25:20 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 06:25:20 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Thu, Aug 3, 2017 at 8:04 PM, Richard Wilbur wrote: > The good news is it looks like we are still within the +/-15% of 100 > Ohm. I'll explain more later. ok :) >> ok i did a video explaining: https://youtu.be/vFbzAmLSHPY > > Thanks for the video, I watched the first 55s and thus this reply. > I'll finish watching and then tie up loose ends. the one thing to remember is, with this track size and separation there _have_ been successful boards... just with different connectors that are no longer available. most of the video is explaining how it's not possible to move things about. but towards the end (last couple of mins) i focus on the connector, explaining how the vias come up around the diamond-shaped pads. l. From lkcl at lkcl.net Fri Aug 4 06:26:03 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 06:26:03 +0100 Subject: [Arm-netbook] bunnie about riscv - NSA in today's CPUs In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 3, 2017 at 8:40 PM, dumblob wrote: > https://brmlab.cz/user/jenda/intel > > One evil HW comparator and we're all screwed :-( thank you for the link, blob - please don't top-post without cutting context. l. From lkcl at lkcl.net Fri Aug 4 07:17:22 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 07:17:22 +0100 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170803203802.GA5217@pabbook> References: <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 3, 2017 at 9:38 PM, Pablo Rath wrote: > On Fri, Jul 28, 2017 at 11:08:16AM -0400, doark at mail.com wrote: >> I asked in to forums about how to solve this and it's been weeks without >> any answer (I only ever got one, and that user told me not to side load >> software (which I explained that I never did or even thought of)). > > I still don't get why you believe that ntc is evil. In my opinion they > are not evil just because the configured PocketChip like you described. i concur. they're a group of enterprising people who have utilised one of the lowest-cost china SoCs with an extremely high libre reputation, thanks to the sunxi community's work about five years ago. > Please read my previous email on this list. > Basically you put PocketChip into fel-mode and connect it with another > computer. You can then use a "special" version of U-Boot via fel and > boot an OS on USB or Debian Installer on USB. i've done this a lot. it's my primary method of development and debugging. i upload the FEL sub-16k loader to initialise the SoC's DDR3 RAM, then upload u-boot directly into the DDR3 RAM, then ask FEL to *execute* u-boot directly in RAM. in the past i've even loaded an entire kernel *and initrd* into memory over FEL - that takes a while but it can take less time than having to insert and remove micro-sd cards (and rewrite them, and mount them, and blah blah). you cannot expect companies to drop everything and help just you. you're just one person: you're expected to work these things out for yourself. now, if you were placing an order for ten THOUSAND *then* they might be interested. l. From lkcl at lkcl.net Fri Aug 4 08:19:05 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 08:19:05 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 3, 2017 at 11:53 PM, Richard Wilbur wrote: > We can still take some of the recommendations to heart: > 1. Use minimal size vias for high-frequency traces to reduce > parasitic capacitance.[23] yep. 0402 all the way round. can't go smaller as it risks the drill hitting the edge of the ring. > 2. Place the two vias of the differential pair in close proximity to > increase capacitive coupling between the signals.(smaller via pitch) yep. doing that. > 3. Instead of using two separate anti-pads on signal vias, combine > them into an oval shared antipad (on every layer) to reduce parasitic > capacitance. oo. never heard of this practice. never heard of "anti-pads" either! so sorry, if you put some references i missed them. > 4. Place ground vias next to signal vias to provide low-impedance > ground-return paths.[22, Figure 2] yep doing that. l. From mike.valk at gmail.com Fri Aug 4 08:41:44 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Fri, 4 Aug 2017 09:41:44 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: 2017-08-03 17:28 GMT+02:00 Luke Kenneth Casson Leighton : > ok i did a video explaining: https://youtu.be/vFbzAmLSHPY Informative. Might I suggest a screen recorder? Although that might be a bit more work in post editing, it might be more clear and . The middle GND traces could use a bit more riveting(via's). There's space in the corners. The outer HDMI GND trace, on the inner side of the board, might benefit from some riveting like to one on the outer side. From mike.valk at gmail.com Fri Aug 4 08:51:24 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Fri, 4 Aug 2017 09:51:24 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: 2017-08-04 9:19 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 3, 2017 at 11:53 PM, Richard Wilbur > wrote: > >> 3. Instead of using two separate anti-pads on signal vias, combine >> them into an oval shared antipad (on every layer) to reduce parasitic >> capacitance. > > oo. never heard of this practice. never heard of "anti-pads" > either! so sorry, if you put some references i missed them. > https://e2e.ti.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-25/3124.Fig1.jpg From https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias Basically a barrier between a via and a passing layer. Something default to prevent shorting. With differentals have them combined so there is nothing in between them in a horizontal line/z axis as well. From lkcl at lkcl.net Fri Aug 4 09:16:42 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 09:16:42 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 4, 2017 at 3:24 AM, Richard Wilbur wrote: > HDMI Layout Notes > for EOMA68 Cards > by Richard Wilbur > Thu 3 Aug 2017 > > Recommendations for this Layout > > Source (processor) end: > > Could we shrink the via pitch between constituents of a differential > pair (bring the vias of a differential pair closer to each other) maaayyybeee? PADS does the distances automatically, so it would involve manual editing (and second-guessing of the automated rules / best-practices for diff-pair routing in PADS) > and > combine the anti-pads into an oval shape on each layer? This reduces > fringing fields and thus parasitic capacitance. https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias ok found it... hmmmm yeah i can see how that would work. ok see attached little image: turns out that the GND copper flood-fill clearance is enough to *automatically* create the equivalent of what you're referring to. > I like the ground vias close to the signal vias between differential > pairs. It would be lovely to get a ground via close to the via on > HTX2P and possibly move the one between HTX2N and HTX1P closer to the > signal vias (if the signal vias of pairs can be moved closer with > combining the anti-pads). yeah i think i can do the one on HTX2P... but it involves: *deep breath* moving HSCL and all those other signals further over inverting the XTAL-IN and XTAL-OUT signals so that one of them goes the *other* side of its BGA pad moving and re-routing the PWM and EINT-0 signals (which are too close anyway) with those vias, to the XTAL signals possibly routing HSDA round the *back*... no that takes it past the diffpairs... HHPD routing *right* instead of down... that would be okay.... it would go past the USB diff-pairs though.... i think i can tolerate that.. > What is the intra-pair skew from the processor lands to the first > signal vias? I wonder if we could move the vias on the short lines a > little further from the processor and make up some of the skew in that > segment before we leave it? yes i was considering that - maybe just staggering the vias so for example HXTX1N and P are inverted as to how they really should be. > Sink (connector) end: > > Same thing for differential pair vias--HTX0 and HTX2--it would be > lovely to shrink the via pitch and combine anti-pads (if possible). > Again, I like the ground vias close to the signal vias HTX2P, HTX2N, > and HTX0P. It would be lovely to be able to either put a new ground > via closer to the signal via on HTX0N or move the one on the ground > shield trace closer. it's virtually impossible to get anything in there, because of the three Rclamp0524p components (anti-static protection). i'm going to move one of the rclamp0524p's so that it's directly above the other, and it *might* then be possible to fit some GND vias in there. also i realised that the path is shorter to the DC3 connector because of the via staggering, so i will have to put a small "wiggle" into the shorter path right at that point. why? because the signals should be properly matched right up to that point. > I like what you were showing on the video with the signal vias at the > connector lands: putting a neck on the trace between the via and the > land should dampen the spirits of the solder but not the signals. yehyeh. > If we could reduce the signal via pitch by combining anti-pads at the > connector, we might be able to move the HTX1P and HTXCN signal vias to > the other side of the lands next to the other side of the differential > pair, thus equalizing the skew on the segment between the ESD chip > pads and the connector pads. yehyeh i get it. nomnomnom.... it might just be doable. i'd have to shrink the size of the two GND pads, 16 and 4, then the vias for 14 and 6 could be moved to the other side then *diagonal* (right).... shrinking the size of 10 as well would allow the existing vias to the right of 8 and 12 to *also* be moved diagonally to the right... changing them to 0302s would give some extra clearance, it's risky but what about this isn't... > If that worked the final touch might be > to add a ground via between DC3 pin 10 (GND) and the board edge for > return current paths. > > Other than that, I would try and move as much of the skew compensation > close to the source of the skew as possible. yehyeh *sigh* i missed that. frack. gonna have to redo the whole frackin lot, one path at a time, so i can make sure each segment is matched. frack!! > I'm not sure what I'm looking at as you mentioned the ground reference > planes were solid under the HDMI differential pairs, yes. > but it looks like > they have voids under the signals in the pictures. no, > Am I seeing a negative, you're seeing the board pre-flood. when flooding is done it f***s things up in PADS, causes it to be very unstable (especially if you switch it to "invisible" with SPO and PO / PD keystroke commands). also massively increases the file size. also gets in the way as you can't see a damn thing. also if it was a real-time feature the entire system would grind to a halt as it takes about ten SECONDS to recalculate the flood-fill. and yes layers 2 and 5 are solid GND planes. > that there are only little strips of conductor in the ground > reference plane directly under the high-frequency lines? Neither of > these interpretations is very satisfactory, nor do they seem to > represent reality. you may be referring to the little ground tracks i added. these are there because the copper-to-everything-else clearance i set to around.... i think... 7 or perhaps 10mil, so that it doesn't get absolutely everywhere. however i *want* the GND plane (on 1) to go into nooks and crannies.... reach the parts that other beers can't reach... only way to do that is manually. > Please let me know what can and can't be done and I will adjust > recommendations accordingly. appreciated. well, let me try the DC3 experiment of moving the VIAs to the other side. that i feel is really important. l. From mike.valk at gmail.com Fri Aug 4 09:17:22 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Fri, 4 Aug 2017 10:17:22 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> Message-ID: 2017-08-04 8:17 GMT+02:00 Luke Kenneth Casson Leighton : > --- > > you cannot expect companies to drop everything and help just you. > you're just one person: you're expected to work these things out for > yourself. > > now, if you were placing an order for ten THOUSAND *then* they might > be interested. Well they've announced the CHIP to be more open and supported than actually delivered. Now that is unfortunately common practice. And due to experiences in the past, Poulsbo, Andriod, I already knew that they would not be able to deliver that, especially at that price point. Hey they even promised opensource 3d graphics if the crowdfunding was successful enough, if I recall correctly. But that is just us. That might not, and probably is, be true for a lot of their customers, like David. That's we're the evil lies I think. Announcing a "libre" computer but fail to follow it through. Yes there is open source software for you to use, yes there schematics. But from what I've learned, a lot of it here on the list and from you Luke. That's not enough. There needs to be a reproducible process and clearly state what is open and what is not. > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Fri Aug 4 09:46:26 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 09:46:26 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: it works! signals on layer 6 (blue) can be made properly diff-paired. only concern: both vias are now right hard-up against the board edge. but... again, their pins are directly above them, and they're leading into the metal case which is entirely shielded. so i *think* it's ok. l. From lkcl at lkcl.net Fri Aug 4 11:14:59 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 11:14:59 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 4, 2017 at 8:41 AM, mike.valk at gmail.com wrote: > 2017-08-03 17:28 GMT+02:00 Luke Kenneth Casson Leighton : >> ok i did a video explaining: https://youtu.be/vFbzAmLSHPY > > Informative. Might I suggest a screen recorder? Although that might be > a bit more work in post editing, it might be more clear and . ahh...... this screen's 3000x1800 :) > The middle GND traces could use a bit more riveting(via's). There's > space in the corners. The outer HDMI GND trace, on the inner side of > the board, might benefit from some riveting like to one on the outer > side. i can get some more in on the right lower side where the traces begin to turn 45 degrees upwards after a long run from the processor - i can't get any on the other side (right upper) because the 1206 capacitors for IPSOUT and 5VIN are in the way. l. From lkcl at lkcl.net Fri Aug 4 11:16:20 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 11:16:20 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 8:51 AM, mike.valk at gmail.com wrote: > 2017-08-04 9:19 GMT+02:00 Luke Kenneth Casson Leighton : >> On Thu, Aug 3, 2017 at 11:53 PM, Richard Wilbur >> wrote: >> >>> 3. Instead of using two separate anti-pads on signal vias, combine >>> them into an oval shared antipad (on every layer) to reduce parasitic >>> capacitance. >> >> oo. never heard of this practice. never heard of "anti-pads" >> either! so sorry, if you put some references i missed them. >> > https://e2e.ti.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-25/3124.Fig1.jpg > > From > https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias > > Basically a barrier between a via and a passing layer. Something > default to prevent shorting. oh, ok - just a hole where you'd expect one to be :) didn't know its name was "anti-pad". > With differentals have them combined so there is nothing in between > them in a horizontal line/z axis as well. turns out that the anti-pads from PADS are big enough to create a figure-8. l. From richard.wilbur at gmail.com Fri Aug 4 19:06:00 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 4 Aug 2017 12:06:00 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Impedance In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 4:16 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Aug 4, 2017 at 8:51 AM, mike.valk at gmail.com wrote: >> 2017-08-04 9:19 GMT+02:00 Luke Kenneth Casson Leighton : >>> On Thu, Aug 3, 2017 at 11:53 PM, Richard Wilbur >>> wrote: >>> >>>> 3. Instead of using two separate anti-pads on signal vias, combine >>>> them into an oval shared antipad (on every layer) to reduce parasitic >>>> capacitance. >>> >>> oo. never heard of this practice. never heard of "anti-pads" >>> either! so sorry, if you put some references i missed them. >>> [...] >> Basically a barrier between a via and a passing layer. Something >> default to prevent shorting. > > oh, ok - just a hole where you'd expect one to be :) didn't know its > name was "anti-pad". Sorry for not explaining very well and no references. Thank you Mike for adding both to the discussion. >> With differentals have them combined so there is nothing in between >> them in a horizontal line/z axis as well. > > turns out that the anti-pads from PADS are big enough to create a figure-8. That's cool. The reason for an oval (or ellipse) shape instead of a figure-8, if you can muster an oval or ellipse, is that the sharp points greatly concentrate electric fields--leading to capacitance--which is pretty much the opposite effect of a smooth curve. I'm glad to hear that successful HDMI layouts have been achieved using 5mil width, 5mil spacing for differential pairs. The reason I recommended 5.1mil width, 5mil spacing is because TI's geometry recommendation includes the condition width > spacing. Sounds like that is not a necessary condition for a working board. From richard.wilbur at gmail.com Fri Aug 4 21:41:55 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 4 Aug 2017 14:41:55 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: Sent from my iPhone > On Aug 4, 2017, at 02:46, Luke Kenneth Casson Leighton wrote: > > it works! signals on layer 6 (blue) can be made properly diff-paired. > only concern: both vias are now right hard-up against the board edge. > but... again, their pins are directly above them, and they're leading > into the metal case which is entirely shielded. so i *think* it's ok. I agree as this is a mid-mount connector with metal body/shield, right? The metal extends down covering the board edge, doesn't it? Sounds like a pretty cool accomplishment. It probably looks nice, too! That's one of things I've noticed, a good design tends to have an appealing appearance. From lkcl at lkcl.net Fri Aug 4 21:45:03 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 4 Aug 2017 21:45:03 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 4, 2017 at 9:41 PM, Richard Wilbur wrote: > > > Sent from my iPhone >> On Aug 4, 2017, at 02:46, Luke Kenneth Casson Leighton wrote: >> >> it works! signals on layer 6 (blue) can be made properly diff-paired. >> only concern: both vias are now right hard-up against the board edge. >> but... again, their pins are directly above them, and they're leading >> into the metal case which is entirely shielded. so i *think* it's ok. > > I agree as this is a mid-mount connector with metal body/shield, right? yehyeh... but in one sample it had some sort of thing coming down to meet the board, but in the reel of 1500 they don't. > The metal extends down covering the board edge, doesn't it? top and bottom (horizontally) yes, but vertically, no. > Sounds like a pretty cool accomplishment. well i wouldn't have tried it if you hadn't pushed me > It probably looks nice, too! it does. > That's one of things I've noticed, a good design tends to have an appealing appearance. ah gooood. someone else who noticed that beauty and elegance seems to actually.... work. l. From vkontogpls at gmail.com Sat Aug 5 00:47:02 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Sat, 5 Aug 2017 02:47:02 +0300 Subject: [Arm-netbook] Injection Molding Cost Message-ID: 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. From lkcl at lkcl.net Sat Aug 5 06:54:30 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 5 Aug 2017 06:54:30 +0100 Subject: [Arm-netbook] Injection Molding Cost In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Aug 5, 2017 at 12:47 AM, Bill Kontos wrote: > 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 with half a million dollars, yes. > The numbers don't make any sense given the ~100k cost luke has > mentioned in the past( the 2 keyboard halves have different designs). with only about 4 small part.... not 35. l. From doark at mail.com Mon Aug 7 23:46:39 2017 From: doark at mail.com (David Niklas) Date: Mon, 7 Aug 2017 18:46:39 -0400 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: Message-ID: <20170807184639.00566acd@ulgy_thing> On Sat, 29 Jul 2017 15:49:21 +0100 Luke Kenneth Casson Leighton wrote: > On Sat, Jul 29, 2017 at 2:51 PM, Benson Mitchell > wrote: > > On Sat, Jul 29, 2017 at 8:53 AM, Luke Kenneth Casson Leighton > > >> wrote: > > > >> http://hands.com/~lkcl/foldable3dsandwich200/belts.py > >> > >> ok, i could use some algorithm help, here, if anyone's interested. > >> the key function is add_bearing in class Belt. > >> > > I don't really speak python, but I'm happy to put my two cents in. > > python's pretty clear and human-readable. > > so if i may, i'd like to leave it to others to discuss this, if they > want to: i'll chip in if necessary. > > l. I'm going to look into this luke, no promises, but I'm ok with math and python. Sincerely, David From doark at mail.com Sun Aug 6 02:56:23 2017 From: doark at mail.com (doark at mail.com) Date: Sat, 5 Aug 2017 21:56:23 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> Message-ID: <20170804081015.3467e4d4@ulgy_thing> On Tue, 1 Aug 2017 21:14:11 +0200 Tzafrir Cohen wrote: > On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark at mail.com wrote: > > > And there were times when those on the Devuan mailing list would seem > > to head towards the "I hate Poettering" side, but we would all engage > > them (except, maybe me because I would miss most of the discussion), > > to thinking about the enemy we were fighting, which was systemd, not > > Poettering, and it would work 100% of the time, at least as far as I > > remember. > > I thought you were out to write a good system, and not up against > another software. > I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system. So nobody was out to write a system, rather to utilize others that they deemed was more suitable for their purposes. Sincerely, David From lkcl at lkcl.net Tue Aug 8 03:47:05 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 8 Aug 2017 03:47:05 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: <20170807184639.00566acd@ulgy_thing> References: <20170807184639.00566acd@ulgy_thing> Message-ID: On Mon, Aug 7, 2017 at 11:46 PM, David Niklas wrote: >> >> http://hands.com/~lkcl/foldable3dsandwich200/belts.py >> >> >> >> ok, i could use some algorithm help, here, if anyone's interested. >> >> the key function is add_bearing in class Belt. > I'm going to look into this luke, no promises, but I'm ok with math and > python. star. i _could_ do it.... it'd take time. l. From lkcl at lkcl.net Tue Aug 8 06:20:30 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 8 Aug 2017 06:20:30 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: <20170807184639.00566acd@ulgy_thing> Message-ID: https://math.stackexchange.com/questions/882067/given-two-circles-find-the-length-of-a-pulley-belt-that-connects-the-two this might help - i'm going to ask another question. From lkcl at lkcl.net Tue Aug 8 06:58:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 8 Aug 2017 06:58:49 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: <20170807184639.00566acd@ulgy_thing> Message-ID: https://math.stackexchange.com/questions/2386333/how-do-you-find-the-length-and-angle-of-a-belt-between-two-pulleys-both-outer-e 'faakin 'ellfire, faaking stupid system - you don't quotes have enough reputation quotes to post images, thus making it near-impossible to express th faaking question in an easy-to-faakin-understand way. faak! l. From pablo at parobalth.org Tue Aug 8 10:57:44 2017 From: pablo at parobalth.org (Pablo Rath) Date: Tue, 8 Aug 2017 11:57:44 +0200 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170804081015.3467e4d4@ulgy_thing> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> Message-ID: <20170808095721.GA4077@pabbook> On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark at mail.com wrote: > I aught to have been more clear, almost all of those on the list found > systemd a bad choice for them vs. another init system. I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian. kind regards Pablo From pablo at parobalth.org Tue Aug 8 11:11:07 2017 From: pablo at parobalth.org (Pablo Rath) Date: Tue, 8 Aug 2017 12:11:07 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> Message-ID: <20170808101107.GB4077@pabbook> On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.valk at gmail.com wrote: > Well they've announced the CHIP to be more open and supported than > actually delivered. > > Now that is unfortunately common practice. And due to experiences in > the past, Poulsbo, Andriod, I already knew that they would not be able > to deliver that, especially at that price point. Hey they even > promised opensource 3d graphics if the crowdfunding was successful > enough, if I recall correctly. > > But that is just us. That might not, and probably is, be true for a > lot of their customers, like David. That's we're the evil lies I > think. Announcing a "libre" computer but fail to follow it through. > Yes there is open source software for you to use, yes there > schematics. Please correct me if I am wrong but I am pretty sure they did not announce a "libre" computer. They use the term "open source" and "very open source" on their kickstarter page. People in the "Open Source Camp" seem to be more inclined to accept a very open source system with proprietary wifi. kind regards Pablo From vincent.legoll at gmail.com Tue Aug 8 12:45:39 2017 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Tue, 8 Aug 2017 13:45:39 +0200 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170808095721.GA4077@pabbook> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: Hello, On Tue, Aug 8, 2017 at 11:57 AM, Pablo Rath wrote: > On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark at mail.com wrote: >> I aught to have been more clear, almost all of those on the list found >> systemd a bad choice for them vs. another init system. > > I disagree. The majority of people on this list (2000+) stayed silent on this > particular topic. > Many ordered their Computer Card with Debian. I disagree, being silent about this topic is not endorsing any particular option. Neither is choosing a specific computer card. At least in my case... -- Vincent Legoll From mike.valk at gmail.com Tue Aug 8 14:57:57 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Tue, 8 Aug 2017 15:57:57 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170808101107.GB4077@pabbook> References: <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> <20170808101107.GB4077@pabbook> Message-ID: 2017-08-08 12:11 GMT+02:00 Pablo Rath : > On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.valk at gmail.com wrote: >> Well they've announced the CHIP to be more open and supported than >> actually delivered. >> >> Now that is unfortunately common practice. And due to experiences in >> the past, Poulsbo, Andriod, I already knew that they would not be able >> to deliver that, especially at that price point. Hey they even >> promised opensource 3d graphics if the crowdfunding was successful >> enough, if I recall correctly. >> >> But that is just us. That might not, and probably is, be true for a >> lot of their customers, like David. That's we're the evil lies I >> think. Announcing a "libre" computer but fail to follow it through. >> Yes there is open source software for you to use, yes there >> schematics. > > Please correct me if I am wrong but I am pretty sure they did not > announce a "libre" computer. They use the term "open source" and "very > open source" on their kickstarter page. People in the "Open Source Camp" > seem to be more inclined to accept a very open source system with > proprietary wifi. The term libre is somewhat new. The average joe knows about open source these days. But if I drop the libre keyword they don't understand. And they did not get to "very open" in my opinion. But the level op openness should be stated more clearly. As it is the system for all functionality is tied to a 3.4 kernel and fixed X11 version display stack. Or Android. So for all the openness upgrading is neigh impossible. As is running a generic Linux distribution. So in my opinion opensource means that you can upgrade and the every bit can be mainlined. Firmware, however evil in it's own right, is independent on the OS software stack and thus does not impair upgrading or switching OS and/or OS versions. So hence the general acceptance I guess. The MALI GPU requires a closed source driver dependent on the OS stack. Thus locking you in place. The Cedar VPU requires a closed source driver dependent on the OS stack. Thus locking you in place. That situation, again no thanks to NTC, is improving, albeit slowly. Thankfully display drivers (That's not the GPU. So no 2d or 3d acceleration!) are available or worked on. But no help from NTC. So on paper nothing better than a Intel GMA500 (Poulsbo/PowerVR). E.g. a Dell mini 1010 sold with Ubuntu, the trap I fell into, Three Ubuntu iterations further and that was it for that Laptop. When announcing an open source system. Companies should be very clear on what they are selling. Does it include firmware? (Acceptable ?) Does it include closed source drivers? (That limits upgradablity and usefull lifetime) Do you provide a complete stack, Source, Compile chain, Documentation? Do you provide schematics? Do you provide a BoM? Do you provide comprehensive component documentation free of NDA's? etc. Simply saying "we're selling an opensource system" is a farce. That's too broad. > > kind regards > Pablo > > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From hendrik at topoi.pooq.com Tue Aug 8 14:58:05 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 8 Aug 2017 09:58:05 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170808095721.GA4077@pabbook> References: <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: <20170808135805.GA10613@topoi.pooq.com> On Tue, Aug 08, 2017 at 11:57:44AM +0200, Pablo Rath wrote: > On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark at mail.com wrote: > > I aught to have been more clear, almost all of those on the list found > > systemd a bad choice for them vs. another init system. > > I disagree. The majority of people on this list (2000+) stayed silent on this particular > topic. > Many ordered their Computer Card with Debian. Debian is well-known to be upgradable to Devuan with just a dist-upgrade after editing /etc/apt/sources.list. If I wanted Devuan I would have ordered Debian too. -- hendrik From lkcl at lkcl.net Tue Aug 8 15:28:43 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 8 Aug 2017 15:28:43 +0100 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> <20170808101107.GB4077@pabbook> Message-ID: On Tue, Aug 8, 2017 at 2:57 PM, mike.valk at gmail.com wrote: > The Cedar VPU requires a closed source driver dependent you mean a criminally-infringing library which has at the very least stolen copyright code from ffmpeg confirmed (not a "closed source" driver). > on the OS > stack. Thus locking you in place. That situation, again no thanks to > NTC, is improving, albeit slowly. libcedrus has been around and working for a long, long time on the A13 / R8 / GR8 (all the same SoC). it also works on the A20 and i had full 1080p video playback fully operational back in august 2016. so i know it's a fully libre video stack. l. From mike.valk at gmail.com Tue Aug 8 16:13:33 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Tue, 8 Aug 2017 17:13:33 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> <20170728110816.03497692@ulgy_thing> <20170803203802.GA5217@pabbook> <20170808101107.GB4077@pabbook> Message-ID: 2017-08-08 16:28 GMT+02:00 Luke Kenneth Casson Leighton : > On Tue, Aug 8, 2017 at 2:57 PM, mike.valk at gmail.com wrote: > >> The Cedar VPU requires a closed source driver dependent > > you mean a criminally-infringing library which has at the very least > stolen copyright code from ffmpeg confirmed (not a "closed source" > driver). :-) yep that one! And the driver source, while constructed out of gpl software, was never released. And thus still closed software. Illegal, gpl violating, but closed. Their attempt to rectify was to create a open source stub driver and a closed source userspace part, consisting of obfuscated FFMPEG code. [1] Luc Verhagen, et al. explained and barked loudly at Allwinner on what they had to do to rectify. But I guess the IP owner of cedarx is not AllWinner. And their vendor, the IP owner, the original infringer, did not give them permission to rectify properly. Or something else. [1] > >> on the OS >> stack. Thus locking you in place. That situation, again no thanks to >> NTC, is improving, albeit slowly. > > libcedrus has been around and working for a long, long time on the > A13 / R8 / GR8 (all the same SoC). it also works on the A20 and i had > full 1080p video playback fully operational back in august 2016. so i > know it's a fully libre video stack. sunxi-vdpau is open source but it is a hack. An unsafe one! [3] sunxi-cedrus is not ready for primetime last time I checked. V4L is slow to accept the needed changes.[2] [1] http://linux-sunxi.org/CedarX [2] http://linux-sunxi.org/Cedrus [3] http://linux-sunxi.org/Cedrus/libvdpau-sunxi From calmstorm at posteo.de Tue Aug 8 16:21:44 2017 From: calmstorm at posteo.de (zap) Date: Tue, 8 Aug 2017 11:21:44 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: > I disagree, being silent about this topic is not endorsing any > particular option. > Neither is choosing a specific computer card. > > At least in my case... > I second this notion. I have been silent for a long time but because I didn't see this topic till today. I trust Luke's judgment on systemd. If he says it is insecure and has 20+ background of experience, then why should we disagree with him? Personally, I will be getting devuan when I decide whether it is up to my standards or not. Though I still wonder when rk3388 is coming out. ;) From lkcl at lkcl.net Tue Aug 8 16:45:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 8 Aug 2017 16:45:50 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: On Tue, Aug 8, 2017 at 4:21 PM, zap wrote: > I trust Luke's judgment on systemd. If he says it is insecure and has > 20+ background of experience, then why should we disagree with him? because you've thought it through or yourself, weighed the balance of factors *you* are comfortable with, and come to your own conclusion. which may or may not happen to be the same. i'm comfortable with a parallel-factors "fuzzy" approach to decision-making: it's part of reverse-engineering to consider factors that you really genuinely have no clue on, really, as to whether they're black-and-white "true" or not. but when you take 5, 10, 20, 50 or even more such "no-clue" samples and they *all* agree, that's as good an indication that the hypothesis is statistically valid as any. and it can be a lot faster and a lot less hassle. *but*... you try to explain this approach to people... dang it can get ugly *real* fast. the usual sign of trouble is when people ask the question "Give Me One Good Reason". with the analysis approach that i take on "nebulous" topics, to give ONE reason is not only flat-out impossible, it's completely and utterly misleading to do so. the multi-factor signs - the entire package - *is* the "reason"... but that is not something that many people can cope with. they consider the entire approach to be deeply flawed... because there is no "rational" single factor that says black and white yes or no. l. From calmstorm at posteo.de Tue Aug 8 21:12:44 2017 From: calmstorm at posteo.de (zap) Date: Tue, 8 Aug 2017 16:12:44 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: > because you've thought it through or yourself, weighed the balance of > factors *you* are comfortable with, and come to your own conclusion. > which may or may not happen to be the same. > > i'm comfortable with a parallel-factors "fuzzy" approach to > decision-making: it's part of reverse-engineering to consider factors > that you really genuinely have no clue on, really, as to whether > they're black-and-white "true" or not. but when you take 5, 10, 20, > 50 or even more such "no-clue" samples and they *all* agree, that's as > good an indication that the hypothesis is statistically valid as any. > > and it can be a lot faster and a lot less hassle. > > *but*... > > you try to explain this approach to people... dang it can get ugly > *real* fast. the usual sign of trouble is when people ask the > question "Give Me One Good Reason". with the analysis approach that i > take on "nebulous" topics, to give ONE reason is not only flat-out > impossible, it's completely and utterly misleading to do so. the > multi-factor signs - the entire package - *is* the "reason"... but > that is not something that many people can cope with. they consider > the entire approach to be deeply flawed... because there is no > "rational" single factor that says black and white yes or no. > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk My bad,I was just trying to say that we should trust your 20+ years of experience, considering your ethical standards in general, I thought this was a good analysis. I see part of your point though, there are a lot more reasons... Linus at one point after all said systemd's design scope was insanely complex. So yes, I did read up a bit on it a while ago. Should I have mentioned that? probably... but oh well too late now. From lkcl at lkcl.net Wed Aug 9 05:36:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 05:36:50 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: On Tue, Aug 8, 2017 at 9:12 PM, zap wrote: >> because you've thought it through or yourself, weighed the balance of >> factors *you* are comfortable with, and come to your own conclusion. >> which may or may not happen to be the same. > My bad,I was just trying to say that we should trust your 20+ years of > experience, considering your ethical standards in general, I thought > this was a good analysis. i'd be much more comfortable with you taking responsibility for your own decision-making (and rationale) not least, you can double-check mine. btw PLEASE zap, i believe i've had to tell you four or five times now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one person still in moderation, i can't just arbitrarily ignore those rules. do you see what i did above? i cut out everything that wasn't relevant. PLEASE DO THE SAME. l. From calmstorm at posteo.de Wed Aug 9 10:34:00 2017 From: calmstorm at posteo.de (zap) Date: Wed, 9 Aug 2017 05:34:00 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: <510c17b3-e9a7-7f0b-d100-456741e11aa8@posteo.de> > i'd be much more comfortable with you taking responsibility for your > own decision-making (and rationale) not least, you can double-check > mine. I don't really understand completely, I guess > btw PLEASE zap, i believe i've had to tell you four or five times > now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one > person still in moderation, i can't just arbitrarily ignore those > rules. > > do you see what i did above? i cut out everything that wasn't > relevant. PLEASE DO THE SAME. > Trim like this? To be honest, I thought I did trim it enough. my bad. From lkcl at lkcl.net Wed Aug 9 10:34:54 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 10:34:54 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: okaay, so this is what i've managed for the outgoing vias (layer 1), the two lengths are equal (to each other and including across all four pairs) and the relative positions of each via are identical. for layer 6.... faak it's tight on space down the bottom, so i simply can't get anything but "turns" in. it'll have to go dead-straight until the other end of the board, after the PMIC, where i'll then be able to correct the length differences between the CLK pair and the other pairs. richard you said that the difference between all pairs should be no more than 100mil, right? but that clock should be a leetle bit longer. CLK-pairs are 57.245 (i got them to within a thousandth of a mm! 57.245 and 57.24518 how jammy is that!!) HX2N/P are 49.something - a hell of a big difference. luckily that one's on the outside edge so i can "wiggle" it a lot :) oh... i had another go at the USB pairs, after reading all that you recommended i wasn't happy that there was skew (which i never noticed before). the USB lines worked but there would have been quite a bit of EM. l. From vincent.legoll at gmail.com Wed Aug 9 10:43:38 2017 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Wed, 9 Aug 2017 11:43:38 +0200 Subject: [Arm-netbook] Init Freedom In-Reply-To: <510c17b3-e9a7-7f0b-d100-456741e11aa8@posteo.de> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> <510c17b3-e9a7-7f0b-d100-456741e11aa8@posteo.de> Message-ID: On Wed, Aug 9, 2017 at 11:34 AM, zap wrote: >> btw PLEASE zap, i believe i've had to tell you four or five times >> now, please TRIM UNNECESSARY CONTEXT. >> >> do you see what i did above? i cut out everything that wasn't >> relevant. PLEASE DO THE SAME. >> > Trim like this? To be honest, I thought I did trim it enough. my bad. LGTM A good exercice, is to try reading web archives of a ML, you'll easily understand why this is so important (at least to some of us). -- Vincent Legoll From lkcl at lkcl.net Wed Aug 9 11:46:39 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 11:46:39 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: <510c17b3-e9a7-7f0b-d100-456741e11aa8@posteo.de> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> <510c17b3-e9a7-7f0b-d100-456741e11aa8@posteo.de> Message-ID: On Wed, Aug 9, 2017 at 10:34 AM, zap wrote: >> i'd be much more comfortable with you taking responsibility for your >> own decision-making (and rationale) not least, you can double-check >> mine. > I don't really understand completely, I guess well you did ok here. you're posting inline so that's great (you've been good at doing that). >> btw PLEASE zap, i believe i've had to tell you four or five times >> now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one >> person still in moderation, i can't just arbitrarily ignore those >> rules. >> >> do you see what i did above? i cut out everything that wasn't >> relevant. PLEASE DO THE SAME. >> > Trim like this? this time you took out the "to unsubscribe blah blah" bit... so yes. > To be honest, I thought I did trim it enough. my bad. previous message you did, you left in about 3 paragraphs written by me which was *not* related in any way to what *you* were saying, and you left in the "to unsubscribe blah blah" notice. imagine that this is a real conversation. whilst it's good practice to repeat a "summary" of what the other person has said, in order to indicate that you understand what they've said, if you repeated EVERY SINGLE WORD they'd get f*****d-off with you pretty quickly. basically you have to get inside the other person (or people's) head(s), and think, "okay, if i saw this, how much time would it take to read, is everything in it *absolutely* necessary, but also is it long enough (*enough* context) so that they'll understand where the conversation left off?" that's what it's all about. l. From lkcl at lkcl.net Wed Aug 9 11:39:19 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 11:39:19 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: ... forgot the images... From mike.valk at gmail.com Wed Aug 9 13:19:23 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Wed, 9 Aug 2017 14:19:23 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-09 12:39 GMT+02:00 Luke Kenneth Casson Leighton : > ... forgot the images... No image's here on the list From lkcl at lkcl.net Wed Aug 9 13:45:19 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 13:45:19 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Aug 9, 2017 at 1:19 PM, mike.valk at gmail.com wrote: > 2017-08-09 12:39 GMT+02:00 Luke Kenneth Casson Leighton : >> ... forgot the images... > No image's here on the list argh. bletch. frick. arse. https://www.youtube.com/watch?v=tpIkDZIqnnY damnit that'll be because i enabled attachment-stripping, didn't i.... *sigh* :) From lkcl at lkcl.net Wed Aug 9 13:44:54 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 13:44:54 +0100 Subject: [Arm-netbook] Fwd: HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: trying the images again (adding image/png to allowed attachment types).... -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled2.png Type: image/png Size: 34531 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.png Type: image/png Size: 16781 bytes Desc: not available URL: From lkcl at lkcl.net Wed Aug 9 14:23:30 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 9 Aug 2017 14:23:30 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: next set... wiggles.jpg is the layer 6 length-matching area: HX2N/P is the one that's the longest, it snakes back on itself. i length-matched all 3 signal pairs to 56.413, and left the CK lines at 57.134 just to give the tiniest bit of delay (TI recommendations iirc). no - not even enough space to do 5.1mil / 5.0 clearance... just... too much. the other images show the via'd portions, they're all either symmetrical or perfectly length-matched to 0.001mm. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles3.jpg Type: image/jpeg Size: 94752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles2.jpg Type: image/jpeg Size: 91904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles.jpg Type: image/jpeg Size: 169054 bytes Desc: not available URL: From mike.valk at gmail.com Thu Aug 10 09:01:23 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 10 Aug 2017 10:01:23 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : > next set... > GND shielding parallel to the differentials is interrupted quite often. Those GND tracks act as shields, for emission and reception. I'd try to put as much parallel GND as possible. And trace the parallel GND around the via's, see attachment. Make sure the'res as much solid GND on the layer above and below the traces, again shielding. Also I'd personally not use curved wriggles. HF signals travel in a straight direction. With curves they start diffracting and start bouncing cross each other and might start to radiate or echo back. But I see that the community is divided on that stance. If tight for space you can use 90% corners with a chamfered outer edge. I suppose the chamfer acts like a mirror. https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100 Figure 6 -------------- next part -------------- A non-text attachment was scrubbed... Name: BB_00615.png Type: image/png Size: 28036 bytes Desc: not available URL: From lasich at gmail.com Thu Aug 10 09:14:54 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Thu, 10 Aug 2017 10:14:54 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: the case for GND around differential pairs cant hurt, maybe even can help. But is it better to have GND in plane below that actually is doing same things? If there is no clear path for signal to go back then I guess put GND in parallel is good but if you have clean GND below than make it somehow redundant. Or am I wrong? I am discussing these because most probably there is tight space even without GND lines... On 10 August 2017 at 10:01, mike.valk at gmail.com wrote: > 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : > > next set... > > > GND shielding parallel to the differentials is interrupted quite > often. Those GND tracks act as shields, for emission and reception. > I'd try to put as much parallel GND as possible. > > And trace the parallel GND around the via's, see attachment. > > Make sure the'res as much solid GND on the layer above and below the > traces, again shielding. > > Also I'd personally not use curved wriggles. HF signals travel in a > straight direction. With curves they start diffracting and start > bouncing cross each other and might start to radiate or echo back. But > I see that the community is divided on that stance. > > If tight for space you can use 90% corners with a chamfered outer > edge. I suppose the chamfer acts like a mirror. From lkcl at lkcl.net Thu Aug 10 09:18:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 09:18:50 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com wrote: > 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >> next set... >> > GND shielding parallel to the differentials is interrupted quite > often. because there's simply not enough space to do otherwise. if i could move the entire CPU and RAM up another 0.5mm it would be doable. but then i would have to re-route 12 signals which go around the top area of the board and that's (a) risky and (b) not enough space to do it. > Those GND tracks act as shields, for emission and reception. > I'd try to put as much parallel GND as possible. > > And trace the parallel GND around the via's, see attachment. ah, got it - thanks for the tip, i thought i'd done that on all diffpairs, but i missed one. good call. yes there's only one, because the layer 1 and layer 6 will be flood-filled and that will fill the areas that "appear" to be missed. > Make sure the'res as much solid GND on the layer above and below the > traces, again shielding. these are layer 1 and layer 6, and layer 2 and 5 are solid GND. > Also I'd personally not use curved wriggles. HF signals travel in a > straight direction. With curves they start diffracting and start > bouncing cross each other and might start to radiate or echo back. mmmmm.... *stress*! anyone else feel the curves are "Bad"? > But > I see that the community is divided on that stance. > > If tight for space you can use 90% corners with a chamfered outer > edge. I suppose the chamfer acts like a mirror. i'd *really* prefer not to do that :) > https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100 > Figure 6 wow that's pretty bad-ass. From lkcl at lkcl.net Thu Aug 10 09:23:00 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 09:23:00 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 9:14 AM, Hrvoje Lasic wrote: > the case for GND around differential pairs cant hurt, maybe even can help. > But is it better to have GND in plane below that actually is doing same > things? If there is no clear path for signal to go back then I guess put > GND in parallel is good but if you have clean GND below than make it > somehow redundant. Or am I wrong? I am discussing these because most > probably there is tight space even without GND lines... the most amazing borad i saw was a 2-layer 5-port GbE router. man you should have seen the diff-pairs on that. it was... beautiful. every ethernet diffpair - bear in mind this is GbE with 5 ports - so that's TWENTY pairs - had GND vias equally spaced an absolute specific distance from them, absolutely regularly like clockwork every couple of mm. what that does is make *absolutely* certain that there's no cross-talk between the diff-pairs. with only a 5 mil GND trace between pairs i am really pushing it, but there really isn't any choice here. the first design (done by a superb senior engineer at wits-tech) didn't even have the GND separation between diff-pairs, and yet amazingly it worked. i don't feel comfortable leaving them out, but i can't get vias in at both ends on all pairs. l. From mike.valk at gmail.com Thu Aug 10 09:38:00 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 10 Aug 2017 10:38:00 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com > wrote: >> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >> Make sure the'res as much solid GND on the layer above and below the >> traces, again shielding. > > these are layer 1 and layer 6, and layer 2 and 5 are solid GND. I was referring mostly to layer 3 and 4. The diff pair is either on 3 or 4. If it is on 3 a slab of GND should be on 4 and vice versa. It's 1. Vsuply + components 2. Ground 3. HF 4. HF 5. Ground 6. Vsuply + componnents Right? >> If tight for space you can use 90% corners with a chamfered outer >> edge. I suppose the chamfer acts like a mirror. > > i'd *really* prefer not to do that :) > >> https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100 >> Figure 6 > > wow that's pretty bad-ass. Yeah I had read a more extensive guide in a TI pdf somewhere, can find it at the moment. But TI documentation also schizo's on curves vs. corners of 35 degrees and chamfered 90 degrees. From lkcl at lkcl.net Thu Aug 10 09:45:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 09:45:49 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 10, 2017 at 9:38 AM, mike.valk at gmail.com wrote: > 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : >> On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com >> wrote: >>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >>> Make sure the'res as much solid GND on the layer above and below the >>> traces, again shielding. >> >> these are layer 1 and layer 6, and layer 2 and 5 are solid GND. > > I was referring mostly to layer 3 and 4. The diff pair is either on 3 > or 4. no. > If it is on 3 a slab of GND should be on 4 and vice versa. > > It's > 1. Vsuply + components > 2. Ground > 3. HF > 4. HF > 5. Ground > 6. Vsuply + componnents > > Right? no. 1. SIG1 + components 2. Ground 3. SIG3 4. POWR 5. Ground 6. SIG6 + componnents there's only 3 signal layers: 1, 3 and 6. there are NO HDMI diffpairs on layer 3. i'm not happy about the fact that i have to use vias *at all* but there's no choice: layer 1 the 24mhz XTAL and the PMIC are in the way, and when you get to the DC3 connector the signals *have* to go round the back (layer 6) anyway. l. From lasich at gmail.com Thu Aug 10 09:59:10 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Thu, 10 Aug 2017 10:59:10 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On 10 August 2017 at 10:45, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Thu, Aug 10, 2017 at 9:38 AM, mike.valk at gmail.com > wrote: > > 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : > >> On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com > >> wrote: > >>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton >: > >>> Make sure the'res as much solid GND on the layer above and below the > >>> traces, again shielding. > >> > >> these are layer 1 and layer 6, and layer 2 and 5 are solid GND. > > > > I was referring mostly to layer 3 and 4. The diff pair is either on 3 > > or 4. > > no. > > > If it is on 3 a slab of GND should be on 4 and vice versa. > > > > It's > > 1. Vsuply + components > > 2. Ground > > 3. HF > > 4. HF > > 5. Ground > > 6. Vsuply + componnents > > > > Right? > > no. > > 1. SIG1 + components > 2. Ground > 3. SIG3 > 4. POWR > 5. Ground > 6. SIG6 + componnents > this is what we have been using for our design more or less and that came with freescale reference design as well. > > there's only 3 signal layers: 1, 3 and 6. there are NO HDMI > diffpairs on layer 3. i'm not happy about the fact that i have to use > vias *at all* but there's no choice: layer 1 the 24mhz XTAL and the > PMIC are in the way, and when you get to the DC3 connector the signals > *have* to go round the back (layer 6) anyway. > > l. From mike.valk at gmail.com Thu Aug 10 10:21:15 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 10 Aug 2017 11:21:15 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-10 10:45 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 10, 2017 at 9:38 AM, mike.valk at gmail.com > wrote: >> 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : >>> On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com >>> wrote: >>>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >>>> Make sure the'res as much solid GND on the layer above and below the >>>> traces, again shielding. > > 1. SIG1 + components > 2. Ground > 3. SIG3 > 4. POWR > 5. Ground > 6. SIG6 + componnents > That work's as well. But the enclosure should shield very well. And there should not be a HF signals on layer 3. From lkcl at lkcl.net Thu Aug 10 10:23:11 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 10:23:11 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 10, 2017 at 10:21 AM, mike.valk at gmail.com wrote: > 2017-08-10 10:45 GMT+02:00 Luke Kenneth Casson Leighton : >> On Thu, Aug 10, 2017 at 9:38 AM, mike.valk at gmail.com >> wrote: >>> 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : >>>> On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com >>>> wrote: >>>>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >>>>> Make sure the'res as much solid GND on the layer above and below the >>>>> traces, again shielding. >> >> 1. SIG1 + components >> 2. Ground >> 3. SIG3 >> 4. POWR >> 5. Ground >> 6. SIG6 + componnents >> > That work's as well. But the enclosure should shield very well. metal case... yes. > And > there should not be a HF signals on layer 3. USB in places but not HDMI. l. From lkcl at lkcl.net Thu Aug 10 10:43:48 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 10:43:48 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: <20170807184639.00566acd@ulgy_thing> Message-ID: https://math.stackexchange.com/questions/2386333/how-do-you-find-the-length-and-angle-of-a-belt-between-two-pulleys-both-outer-e/ hiya david: okay! so someone kindly edited the question to put the proper links in, so the question's actually understandable. so... benson.... with the diagrams that aretino kindly added, i was able to not only understand what he was saying, but, also, understood it well enough to appreciate that *your* answer is correct :) aretino recommends using arccos instead of arcsin. l. From lkcl at lkcl.net Thu Aug 10 10:52:16 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 10:52:16 +0100 Subject: [Arm-netbook] my favourite dilbert... evvah! Message-ID: http://dilbert.com/strip/1994-02-06 still beautifully relevant today.... From mike.valk at gmail.com Thu Aug 10 11:14:37 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 10 Aug 2017 12:14:37 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 10, 2017 at 9:01 AM, mike.valk at gmail.com > wrote: >> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton : >>> next set... >>> >> GND shielding parallel to the differentials is interrupted quite >> often. > > because there's simply not enough space to do otherwise. if i could > move the entire CPU and RAM up another 0.5mm it would be doable. but > then i would have to re-route 12 signals which go around the top area > of the board and that's (a) risky and (b) not enough space to do it. > I found quite some room. See attachments. Red: Easy improvement. Yellow questionable but could use some improvement. Excuse the crappy image editor it's all I have at the moment. Also wouldn't a GND infill on the signal layers be preferable? As log not unconnected islands emerge. -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles3_mv.jpg Type: image/jpeg Size: 32678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles_mv.jpg Type: image/jpeg Size: 55199 bytes Desc: not available URL: From lkcl at lkcl.net Thu Aug 10 12:09:05 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 12:09:05 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 11:14 AM, mike.valk at gmail.com wrote: > I found quite some room. See attachments. Red: Easy improvement. yep, all those will be covered by flood-fill: no need to do them manually. wiggles3_mv, the HXT0 and HXT1 GND segment on the left middle, that one i got. but near IPSOUT, top left, in wiggles_mv? no. it means moving those IPSOUT vias, and i'm not doing that. am i. can i yes. am i going to... mmmmm..... *strains*.... okayokay you twisted my arm :) > Yellow questionable but could use some improvement. Excuse the crappy > image editor it's all I have at the moment. i _like_ crappy editors, i use them all the time :) as long as it gets the job done and it doesn't take long, communicates the intent, *why* would you spend $600 and hours of time?? :) > Also wouldn't a GND infill on the signal layers be preferable? As log > not unconnected islands emerge. GND infill *is* going to be done on the signal layers. but the copper-to-track clearance is 10mil (where tracks are 5mil). so what happens is: any space smaller than 10mil does *not* get flood-filled. so i put little "leaders" - like you can see - into the areas where the beer cannot reach. https://www.youtube.com/watch?v=ab6dJYDgj48 l. From mike.valk at gmail.com Thu Aug 10 12:33:00 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 10 Aug 2017 13:33:00 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-10 13:09 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 10, 2017 at 11:14 AM, mike.valk at gmail.com > wrote: > >> Also wouldn't a GND infill on the signal layers be preferable? As log >> not unconnected islands emerge. > > GND infill *is* going to be done on the signal layers. but the > copper-to-track clearance is 10mil (where tracks are 5mil). so what > happens is: any space smaller than 10mil does *not* get flood-filled. > so i put little "leaders" - like you can see - into the areas where > the beer cannot reach. Ah that explains a lot indeed. Too bad the infill isn't visualized. Sadly the space between the HDMI connectors is to small to fill. That would encapsulate the HDMI signal pairs. > https://www.youtube.com/watch?v=ab6dJYDgj48 LOL From lkcl at lkcl.net Thu Aug 10 12:47:20 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 10 Aug 2017 12:47:20 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 12:33 PM, mike.valk at gmail.com wrote: > Ah that explains a lot indeed. Too bad the infill isn't visualized. i can do a flood-fill and screenshot the gerber files, i'll do that for a final check. > Sadly the space between the HDMI connectors is to small to fill. That > would encapsulate the HDMI signal pairs. that's why, if you look carefully, each pair has a GND pad directly opposite it. this is by design in the MicroHDMI connector specification, it's *designed* to be 10 / 9 staggered pins. l. From richard.wilbur at gmail.com Thu Aug 10 23:40:40 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 10 Aug 2017 16:40:40 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: <3C8A1B76-51E7-4632-AEF4-B9F5D11C0C52@gmail.com> > On Aug 9, 2017, at 03:34, Luke Kenneth Casson Leighton wrote: > > > okaay, so this is what i've managed for the outgoing vias (layer 1), > the two lengths are equal (to each other and including across all four > pairs) and the relative positions of each via are identical. Very nicely done--especially considering how tight that space is. I like the way you snuck some extra length on the traces from the closer pins and with 45 degree bends no less. > for layer 6.... faak it's tight on space down the bottom, so i simply > can't get anything but "turns" in. it'll have to go dead-straight > until the other end of the board, after the PMIC, where i'll then be > able to correct the length differences between the CLK pair and the > other pairs. Since the digital portion of the receivers is built to specifically correlate up to 5 (out of 10) bit times of inter-pair skew (arrival time difference between differential pairs) for every pixel clock, you could think of building in some inter-pair skew as similar to spread-spectrum techniques which have been employed in communications to drop the energy peak on the carrier frequency and more recently on motherboard chipsets. The clock period for 340MHz is T(Pixel) = 1/(pixel clock) = 1/(340MHz) = 2.94ns wavelength = velocity * period = 150um/ps * 2940ps = 441mm = 17400mil So half that period = 1470ps, which at the speed of propagation is ~ 220mm ~ 8700mil. So there is our inter-pair skew budget for the whole path: differential driver, IC lead wire, pin, PCB (the part we have design control of presently), connector, HDMI cable, connector, receiver PCB, pin, IC lead wire, receiver. I believe that if we reserve one-tenth of that inter-pair skew for our transmitter PCB, we should not be unduly stressing the budget and that amounts to ~ 22mm ~ 870mils. Interestingly this is Toradex' suggested limit for skew between clock and data. The HDMI standard restricts transmitters to T(inter-pair skew) = 0.2 * T(pixel) = 2 * T(bit) = 588ps => Δl < v * Δt = 88.2mm ~= 3470mil > richard you said that the difference between all pairs should be no > more than 100mil, right? but that clock should be a leetle bit > longer. I did suggest we might work towards that as a goal based on Chrontel's recommendation, but now I'm giving the spread-spectrum idea more thought and thinking we might design some inter-pair skew into the system on purpose to reduce the amplitude of EM from the constructive interference of all those (painstakingly) phase-aligned transitions. So here is one strategy to implement what I was thinking (predicated on the spread between shortest and longest data pairs being less than 0.5 * L(bit)): 1. Shortest pair becomes our reference length. 2. Other two data pairs are routed different fractions of T(bit) longer than the reference pair. 3. Clock pair is routed a larger fraction of T(bit) longer. Hence: L(reference) = L(shortest data pair without inter-pair skew compensation) T(bit) = 294ps => L(bit) = v * T(bit) = 150um/ps * 294ps = 44.1mm ~ 1740mil Suppose we select fractions: 0.2, 0.3, 0.5(clock) then we would make L(longer data pair) = L(reference) + 0.2 * L(bit) L(longest data pair) = L(reference) + 0.3 * L(bit) L(clock pair) = L(reference) + 0.5 * L(bit) = L(reference) + 22mm I guess I should first ask what are the differential pair lengths before inter-pair skew corrections? > CLK-pairs are 57.245 (i got them to within a thousandth of a mm! > 57.245 and 57.24518 how jammy is that!!) Now that is some great length matching! And intra-pair where it looks like it matters the most! > HX2N/P are 49.something - a hell of a big difference. luckily that > one's on the outside edge so i can "wiggle" it a lot :) The clock data difference is ~8mm ~ 310mil. That's around an order of magnitude (factor of 10) smaller than the limit the HDMI standard imposes on transmitters and more than a factor of 2 smaller than Toradex' recommended limit. > oh... i had another go at the USB pairs, after reading all that you > recommended i wasn't happy that there was skew (which i never noticed > before). the USB lines worked but there would have been quite a bit > of EM. I must confess I hadn't looked at the USB traces but it sounds like a good thing. Which level of support are you providing? From richard.wilbur at gmail.com Fri Aug 11 00:37:35 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 10 Aug 2017 17:37:35 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Wed, Aug 9, 2017 at 7:23 AM, Luke Kenneth Casson Leighton wrote: > next set... > > wiggles.jpg is the layer 6 length-matching area: HX2N/P is the one > that's the longest, it snakes back on itself. i length-matched all 3 > signal pairs to 56.413, and left the CK lines at 57.134 just to give > the tiniest bit of delay (TI recommendations iirc). Very nicely done! 57.134mm - 56.413mm = 721um => T(delay) = 721um / 150um/ps = 4.8ps That is a very tiny delay! Now that we have achieved such close synchronization, I'm suggesting we go for the next goal where we design a certain amount of inter-pair skew into the layout for purposes of lowering the strength of our synchronized pulsing data lines to a more diffuse chatter. > no - not even enough space to do 5.1mil / 5.0 clearance... just... too much. I understand. We might end up with more room--see discussion below. > the other images show the via'd portions, they're all either > symmetrical or perfectly length-matched to 0.001mm. Again, they look nice.

Virus-free. www.avg.com
From eaterjolly at gmail.com Fri Aug 11 01:08:25 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Thu, 10 Aug 2017 20:08:25 -0400 Subject: [Arm-netbook] Conflict-free minerals Message-ID: I just thought I'd make a poke about this. Been a bit busy lately to contribute to the liberating chip or the standards thread, but will be getting back on those soon. No one has really mentioned conflict-free minerals, or does so often in the libre community. It's kinda like adding just one other complication to an already mess-y problem, but I'm interested to know more about the details and problems involved with paying attention to the actual mineral sourcing. I can imagine many OEM's don't publish or even pay attention to where they get minerals from, so I imagine the potential parts list dwindles beyond reason at simply limiting one's self to OEM's that at least list their mineral sources, much less then actually trying to them limit it based on the fairly subjective "conflict-free" qualification. From fivepointpalmexplodingheart at gmail.com Fri Aug 11 02:56:50 2017 From: fivepointpalmexplodingheart at gmail.com (Andrew Bolin) Date: Fri, 11 Aug 2017 11:56:50 +1000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations Message-ID: >> Also I'd personally not use curved wriggles. HF signals travel in a >> straight direction. With curves they start diffracting and start >> bouncing cross each other and might start to radiate or echo back. > > mmmmm.... *stress*! anyone else feel the curves are "Bad"? No. You've followed a bunch of very good advice about length matching, impedance etc. It looks like you've generally kept the pairs parallel through the curves, which is great. If you have an easy option in your software to switch from 45 degree corners to smooth curves, I would do it - if there's not, don't worry. >> If tight for space you can use 90% corners with a chamfered outer >> edge. I suppose the chamfer acts like a mirror. The chamfer is there for impedance reasons, it's not a mirror, and note that a curve is preferred. You also run the risk of manufacturing problems by doing the chamfer - you're already at the minimum trace width, right? As you've previously said, the old layout was further away from best practices, and *it worked*. From lkcl at lkcl.net Fri Aug 11 07:03:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 07:03:49 +0100 Subject: [Arm-netbook] Conflict-free minerals In-Reply-To: References: Message-ID: On Fri, Aug 11, 2017 at 1:08 AM, Jean Flamelle wrote: > I just thought I'd make a poke about this. good idea. > Been a bit busy lately to contribute to the liberating chip or the > standards thread, but will be getting back on those soon. great. knock yourself out :) > No one has really mentioned conflict-free minerals, or does so often > in the libre community. > It's kinda like adding just one other complication to an already > mess-y problem, but I'm interested to know more about the details and > problems involved with paying attention to the actual mineral > sourcing. correct. libre means software... which is another area of highly specialist ethical expertise (the application of ethics to software). conflict minerals is the application of specialist ethical expertise to the sourcing of materials. > I can imagine many OEM's don't publish or even pay attention to where > they get minerals from, so I imagine the potential parts list dwindles > beyond reason at simply limiting one's self to OEM's that at least > list their mineral sources, much less then actually trying to them > limit it based on the fairly subjective "conflict-free" qualification. fairphones does.... but they then screwed up by not bothering with the ethical issues of ensuring that the operating system was actually... legal to distribute. so all the Fairphone 1 products they designed are basically a ticking landfill timebomb.... ENTIRELY DEFEATING the whole fucking point of the exercise. they still have not resolved the use of the GPL-violating Mediatek OS distributed with that phone, meaning that they have LOST ALL RIGHTS TO DISTRIBUTE PRODUCT - including the Fairphone 2 and all future products. the way that they can fix that is to ask every single contributor to u-boot and the linux kernel for their distribution rights back, but first obtain the full GPLv2 source to that Mediatek OS. alcatel did this (alcatel is one of the main sources of mediatek GPLv2 compliant source code). Fairphones did not. so. what do you think of that, jean? should we go out and buy Fairphone products? l. From lkcl at lkcl.net Fri Aug 11 07:04:58 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 07:04:58 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 11, 2017 at 2:56 AM, Andrew Bolin wrote: >>> Also I'd personally not use curved wriggles. HF signals travel in a >>> straight direction. With curves they start diffracting and start >>> bouncing cross each other and might start to radiate or echo back. >> >> mmmmm.... *stress*! anyone else feel the curves are "Bad"? > > No. You've followed a bunch of very good advice about length matching, > impedance etc. > It looks like you've generally kept the pairs parallel through the curves, > which is great. > > If you have an easy option in your software to switch from 45 degree > corners to smooth curves, I would do it - if there's not, don't worry. i did those by hand using the "accordian" feature >>> If tight for space you can use 90% corners with a chamfered outer >>> edge. I suppose the chamfer acts like a mirror. > > The chamfer is there for impedance reasons, it's not a mirror, and note > that a curve is preferred. > You also run the risk of manufacturing problems by doing the chamfer - > you're already at the minimum trace width, right? yehyeh > As you've previously said, the old layout was further away from best > practices, and *it worked*. but it was done by someone else and it didn't use curves. l From lkcl at lkcl.net Fri Aug 11 07:12:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 07:12:45 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Fri, Aug 11, 2017 at 12:37 AM, Richard Wilbur wrote: > On Wed, Aug 9, 2017 at 7:23 AM, Luke Kenneth Casson Leighton > wrote: >> next set... >> >> wiggles.jpg is the layer 6 length-matching area: HX2N/P is the one >> that's the longest, it snakes back on itself. i length-matched all 3 >> signal pairs to 56.413, and left the CK lines at 57.134 just to give >> the tiniest bit of delay (TI recommendations iirc). > > Very nicely done! 57.134mm - 56.413mm = 721um > => T(delay) = 721um / 150um/ps = 4.8ps > That is a very tiny delay! ooooOoo :) > Now that we have achieved such close > synchronization, I'm suggesting we go for the next goal where we > design a certain amount of inter-pair skew into the layout for > purposes of lowering the strength of our synchronized pulsing data > lines to a more diffuse chatter. *deep breath*.... aaaaaaaa! :) well.... that actually happens for the majority of the length in the middle (starting layer 6) but.... if i simply *take out* the intermediary wiggles on layer 6.... >> no - not even enough space to do 5.1mil / 5.0 clearance... just... too much. > > I understand. We might end up with more room--see discussion below. which has probably been truncated... >> the other images show the via'd portions, they're all either >> symmetrical or perfectly length-matched to 0.001mm. > > Again, they look nice.
whoops.... something melted there... From mike.valk at gmail.com Fri Aug 11 07:50:49 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Fri, 11 Aug 2017 08:50:49 +0200 Subject: [Arm-netbook] Conflict-free minerals In-Reply-To: References: Message-ID: 2017-08-11 8:03 GMT+02:00 Luke Kenneth Casson Leighton : > On Fri, Aug 11, 2017 at 1:08 AM, Jean Flamelle wrote: > >> I can imagine many OEM's don't publish or even pay attention to where >> they get minerals from, so I imagine the potential parts list dwindles >> beyond reason at simply limiting one's self to OEM's that at least >> list their mineral sources, much less then actually trying to them >> limit it based on the fairly subjective "conflict-free" qualification. > > fairphones does.... but they then screwed up by not bothering with > the ethical issues of ensuring that the operating system was > actually... legal to distribute. so all the Fairphone 1 products > they designed are basically a ticking landfill timebomb.... ENTIRELY > DEFEATING the whole fucking point of the exercise. > > they still have not resolved the use of the GPL-violating Mediatek OS > distributed with that phone, meaning that they have LOST ALL RIGHTS TO > DISTRIBUTE PRODUCT - including the Fairphone 2 and all future > products. True and the FP1 has been officially been discontinued from support. FP2 is a Qualcomm device. > > the way that they can fix that is to ask every single contributor to > u-boot and the linux kernel for their distribution rights back, but > first obtain the full GPLv2 source to that Mediatek OS. > > alcatel did this (alcatel is one of the main sources of mediatek > GPLv2 compliant source code). > > Fairphones did not. They've tried to do better with FP2. But still they did not fully grasp the implications. > > > so. > > what do you think of that, jean? should we go out and buy Fairphone products? Well, They've focused on one side of the equation, upstream. We've focused on the to other, downstream. So in the end we need both approaches. At least they've raised some awareness and show the world that a viable business can be founded with focus on ethical hardware resources. The software part remained as shitty as the rest. Let us show the world that can be done as well! From lkcl at lkcl.net Fri Aug 11 08:15:26 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 08:15:26 +0100 Subject: [Arm-netbook] Conflict-free minerals In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 11, 2017 at 7:50 AM, mike.valk at gmail.com wrote: >> they still have not resolved the use of the GPL-violating Mediatek OS >> distributed with that phone, meaning that they have LOST ALL RIGHTS TO >> DISTRIBUTE PRODUCT - including the Fairphone 2 and all future >> products. > > True and the FP1 has been officially been discontinued from support. > FP2 is a Qualcomm device. ceasing sale of one criminally-infringing product does not grant the right to sell another. once rights are lost they may NOT be re-established without the consent of ALL copyright parties. thus sadly they no longer have the right to distribute the FP2. or future products. if they continue to do so they will be operating as an illegal criminal cartel (an Organised Crime Syndicate) *not* a Cooperative. they can fix that by obtaining that Mediatek source code. l. From lkcl at lkcl.net Fri Aug 11 08:36:34 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 08:36:34 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: ok richard, so what would you suggest for the amount of skew to be added? l. From richard.wilbur at gmail.com Fri Aug 11 16:30:31 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 11 Aug 2017 09:30:31 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Fri, Aug 11, 2017 at 1:36 AM, Luke Kenneth Casson Leighton wrote: > ok richard, so what would you suggest for the amount of skew to be added? Sorry about the HTML that snuck into that last message! I deleted a similar egregious amount of off-color HTML in the previous message that must be coming from one of my E-mail clients when I instructed it to reply. (I just saw it again on this message. Turns out the free anti-virus software from AVG on this M$ windows machine was configured to add an E-mail signature which looks like it was basically an HTML advertisement with URL. I disabled it so I hope to not see any more.) My earlier message from yesterday opens the discussion of designing a certain amount of inter-pair skew into the HDMI signals. Before I give a more definitive recommendation it would be useful to know the pair lengths of each of the 3 HDMI data pairs HTX0, HTX1, HTX2, and the clock pair length HTXC before you added inter-pair skew compensation. From lkcl at lkcl.net Fri Aug 11 16:52:56 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 16:52:56 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Fri, Aug 11, 2017 at 4:30 PM, Richard Wilbur wrote: > My earlier message from yesterday opens the discussion of designing a > certain amount of inter-pair skew into the HDMI signals. Before I > give a more definitive recommendation it would be useful to know the > pair lengths of each of the 3 HDMI data pairs HTX0, HTX1, HTX2, and > the clock pair length HTXC before you added inter-pair skew > compensation. previous message. look through logs or archives. clock's 57.135. HTX2 was something like 49. others in between. l. From richard.wilbur at gmail.com Fri Aug 11 18:15:15 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 11 Aug 2017 11:15:15 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 2:01 AM, mike.valk at gmail.com wrote: > GND shielding parallel to the differentials is interrupted quite > often. Those GND tracks act as shields, for emission and reception. > I'd try to put as much parallel GND as possible. > > And trace the parallel GND around the via's, see attachment. > > Make sure the'res as much solid GND on the layer above and below the > traces, again shielding. > > Also I'd personally not use curved wriggles. HF signals travel in a > straight direction. With curves they start diffracting and start > bouncing cross each other and might start to radiate or echo back. But > I see that the community is divided on that stance. I also prefer 45 degree corners to the curves. Looks like they only occur in one section. > If tight for space you can use 90% corners with a chamfered outer > edge. I suppose the chamfer acts like a mirror. > > https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100 > Figure 6 This is good advice for single-ended signals on a stripline--high-speed digital and RF. That is the situation Maxim are addressing in the referenced document. The signals we are dealing with are high-speed digital but transmitted in differential mode on a microstrip. Single-ended signals are transmitted relative to a ground reference and so putting ground reference next to them tends to block the side-view of the antenna created by either microstrip or stripline, thus reducing radiated and coupled interference. That's a very good thing! microstrip (The following diagrams are in cross-section perpendicular to the direction of signal transmission. Think of the signal going into the diagram away from the viewer.) single-ended signal without ground shield traces signal + dielectric from the side we see a dipole antenna ground - single-ended signal with ground shield traces - + - ground signal ground - dielectric dielectrc dielectric ground ground ground ground - (ground shield traces would need some vias to connect them with ground plane) This blocks the view of the dipole antenna from the side and reduces the size of the dipole antenna so that far field it is vanishingly small being primarily the area between the ground shield traces and the signal trace. (Far field: distance from microstrip at least 10 * separation between signal and ground shield traces.) Since we have a different geometry, the problem changes. We are using differential microstrips. Differential-mode signals are transmitted relative to each other instead of ground. Only common-mode noise in the signals is transmitted relative to ground. microstrip differential-mode signal without ground shield traces signal+ signal- dielectric dielectric ground ground ground Here the dipole antenna is limited to area between the two signal traces, blocked on the bottom side by ground plane, and insignificant in far field (because the traces are close together, have opposite potential and currents, and the fields cancel each other). I'm out of time to add detail or references, so sending now. From chadvellacott at sasktel.net Fri Aug 11 22:07:37 2017 From: chadvellacott at sasktel.net (chadvellacott at sasktel.net) Date: Fri, 11 Aug 2017 15:07:37 -0600 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170808095721.GA4077@pabbook> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: On 17.8.8 3:57, Pablo Rath wrote: > On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark at mail.com wrote: >> I aught to have been more clear, almost all of those on the list found >> systemd a bad choice for them vs. another init system. > > I disagree. The majority of people on this list (2000+) stayed silent on this particular > topic. > Many ordered their Computer Card with Debian. > I am nearly sure, from the context, that with the words 'those on the list', he was referring to "Devuan's" mailing-list, NOT this mailing-list. From chadvellacott at sasktel.net Fri Aug 11 22:07:56 2017 From: chadvellacott at sasktel.net (chadvellacott at sasktel.net) Date: Fri, 11 Aug 2017 15:07:56 -0600 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> Message-ID: <475d7e8a-d5bd-3971-0693-c1e4485315be@sasktel.net> This is a late response, but persons seem to keep confusing the two mailing-lists. On 17.7.8 8:24, Luke Kenneth Casson Leighton wrote: > On Fri, Jul 7, 2017 at 11:35 PM, David Niklas wrote: > >> Luke I became involved about three weeks after the project started. I'm >> still on the ML but had no time to keep up or contribute much. > > not a problem. At first, I too thought that he was referring to THIS mailing-list, "Arm-netbook". But considering that David's message (as retained below) ends up obviously focusing on Devuan and Debian, it seems that he is, even at the start of his message, talking of a mailing-list for Devuan. > >> I saw some >> of the most cordial behaviour that I have had the privilege to witness on >> a mailing list from most of (all?) the members! > > huh. despite quite a lot of "venting", that's really appreciated to hear. > (My comment above, fits here too.) >> I really believe that they >> will meet with success in their toiling. ~~~ > >> I really think that Devuan is just taking an obvious short cut in the >> above case. That is to say, if devuan and debian devs got together to >> merge then devuan would get support for system and debian would support >> other inits. I do not and did not see any resentment to debian on the >> list by the devuan devs. > > the devuan team have a really nice team spirit, ~~~ > > l. From lkcl at lkcl.net Fri Aug 11 22:12:00 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 11 Aug 2017 22:12:00 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: <475d7e8a-d5bd-3971-0693-c1e4485315be@sasktel.net> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <475d7e8a-d5bd-3971-0693-c1e4485315be@sasktel.net> Message-ID: On Fri, Aug 11, 2017 at 10:07 PM, wrote: > This is a late response, but persons seem to keep confusing the two > mailing-lists. yeah me included. thanks for pointing this out chad. From chadvellacott at sasktel.net Sat Aug 12 05:43:44 2017 From: chadvellacott at sasktel.net (chadvellacott at sasktel.net) Date: Fri, 11 Aug 2017 22:43:44 -0600 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: On 17.7.23 23:38, Luke Kenneth Casson Leighton wrote: ~~~ > On ~[month 7, day] 24, 2017 at 2:07 AM, wrote: ~~~ >> "EOMA68-A20"-card. > > one option is to get a very small card (512mb, 1gb) and put a > "loader" OS on that. if they're $0.25 or $0.50 in qty 1000 then > that's worth considering. instead of $4 for an 8GB card. say. ~~~ (Quoting Luke) >>> and/or to offer much smaller 128 MB or 256 MB microSD cards which have an >>> absolute bare minimum OS on them, with scripts that will download an OS ~~~ >> How secure would this "bare minimum OS" be, for both down-loading AND >> installing onto a microSD-card (supplied by me)? > > if it's designed properly, none. I do not understand this response. I understand being tired. > >> Ideally, I hope that (1) it does not permit any connections other than >> downloading one of several particular "OS"-images, via "URLs" which are >> white-listed as part of the "bare minimum OS", > > not whitelisted: hard-coded. that is good too. But, if not significantly more work, then I hope that the mini-"OS" can be modified by A TECHNICALLY-MINDED user, to download and "install" a different one of the particular "OSs/images" offered. Something like a "config"-file whose content is like this: BEGIN FILE 0 # lines like this, are comments # to download and install a different OS (to the microSD-card which you supply), change the number on the first line, as follows: # # 0 for Parabola 4.3 (3.9 GB) (comes with the RYF Libre Tea card) # 1 for Devuan 3.2 (4.1 GB) # 2 for Debian 2.1 custom without systemd (4.2 GB) # 3 for Fedora 1.0 (3.8 GB) # # but make sure that the microSD-card which you supply, is big enough! END FILE (Of course, the sizes and version-numbers for the sample above, are largely just place-holders, not things which I checked for realisticness.) This way, a user can try or use several different "OSs". It might even make it easier for Luke preparing the "microSD-cards" with the loader-"OS", because the difference between preparing a card for someone who backed a "Parabola"-card, is only one byte (one key-press) different from preparing a card for someone who backed a different card. Furthermore, if one or more backers end up unhappy with what they receive for the "OS" which they backed, then this method probably makes it FAR easier to help those backers try a different "OS". As long as the change requires manually editing a configuration-file, it should be an adequately-technical task to satisfy the "RYF"-criterion of not offering non-libre "software" to average users. > >> and (2) it afterwards checks >> the image to see whether the crypto-graphic hash (better than MD5) matches >> the hash which the "bare minimum OS" says is valid for that image. > > bittorrent would automatically do that. command-line version is > btdownloadheadless. sounds good. I imagine that any necessary further details on using this, can come later. but I hope that "headless" does not mean that we do not even get a statement of progress with numbers, something like Downloading. done 1% ... or Downloading. amount left to download is 10 mb ... or Downloaded 3990 mb of 4000 mb ... and I hope that we get something similar for "installing". Some such estimate of progress, is valuable (1) for trouble-shooting if necessary, and (2) for backers to judge when they should next come back to check whether it is done, like 5 minutes later or 1 day later. > > very tired. stopping here. sorry. please do carry on the > conversation. i'll pick it up later. > > l From pablo at parobalth.org Sat Aug 12 10:43:22 2017 From: pablo at parobalth.org (Pablo Rath) Date: Sat, 12 Aug 2017 11:43:22 +0200 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> <20170728103722.65a5d2c3@ulgy_thing> <20170801191411.lf6q3uexxbvrzymv@lemon.cohens.org.il> <20170804081015.3467e4d4@ulgy_thing> <20170808095721.GA4077@pabbook> Message-ID: <20170812094322.GA3948@pabbook> On Fri, Aug 11, 2017 at 03:07:37PM -0600, chadvellacott at sasktel.net wrote: > On 17.8.8 3:57, Pablo Rath wrote: > >On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark at mail.com wrote: > >>I aught to have been more clear, almost all of those on the list found > >>systemd a bad choice for them vs. another init system. > > > >I disagree. The majority of people on this list (2000+) stayed silent on this particular > >topic. > >Many ordered their Computer Card with Debian. > > > I am nearly sure, from the context, that with the words 'those on the > list', he was referring to "Devuan's" mailing-list, NOT this mailing-list. Yes, now that you pointed it out I can see it too. I should have focused more on the context but my brain jumped to the wrong conclusion too quickly. Thank you Chad for pointing this out. This makes my reply to David above meaningless. kind regards Pablo From lkcl at lkcl.net Sun Aug 13 13:09:24 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 13 Aug 2017 13:09:24 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Fri, Aug 11, 2017 at 6:15 PM, Richard Wilbur wrote: >> Also I'd personally not use curved wriggles. HF signals travel in a >> straight direction. With curves they start diffracting and start >> bouncing cross each other and might start to radiate or echo back. But >> I see that the community is divided on that stance. > > I also prefer 45 degree corners to the curves. Looks like they only > occur in one section. yes - i was trying to save space. ok i managed to get some 45-corner wiggles in, instead. and also got the GND separation in between the CK lines up to the via. i'd *really* like to get this done and into test, particularly the DC3 connector test PCB (first). ok. so wiggles1.jpg is the beginning part. track-pairs remain slightly offset, if you take the difference betweeen each pair it's nearly... 8 mm because the clock lines have to go down (3mm) then right-angle (2mm) then right (2mm) just to catch up with TX2. so they _stay_ up to 8mm out until they get to the right end.. then they wiggle again to get match-lengthed. BUT... it just occurred to me that on the *other* side of those ESD rclamp0524p protectors the diff-pairs are all *different lengths*. so on the other side of the rclamp0524p components all four diff-pairs will be different lengths. would that be sufficient, do you think, richard, to satisfy the "spread spectrum" style you were thinking of? short lengths to the RIGHT of the rclamp0524p: TXC: 3.11mm TX0: 1.23mm TX1: 3.23mm TX2: 1.14mm total lengths: TXC:57.252mm TX0:56.418mm TX1:56.398mm TX2: 56.401mm so the signal pairs are all eever so slightly different, and they're all around 0.85mm shorter than CK. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles2.jpg Type: image/jpeg Size: 147650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wiggles1.jpg Type: image/jpeg Size: 56855 bytes Desc: not available URL: From lkcl at lkcl.net Sun Aug 13 13:20:15 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 13 Aug 2017 13:20:15 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: btw yes i managed to move IPSOUT slightly to the right and got a GND line in between them, without too much disruption. thank you for prompting me to do that. l. From lkcl at lkcl.net Sun Aug 13 14:49:44 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 13 Aug 2017 14:49:44 +0100 Subject: [Arm-netbook] frickin funny Message-ID: https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity i had no idea this article existed... i absolutely love the conclusion.... --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From mike.valk at gmail.com Mon Aug 14 07:43:00 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Mon, 14 Aug 2017 08:43:00 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-13 14:20 GMT+02:00 Luke Kenneth Casson Leighton : > btw yes i managed to move IPSOUT slightly to the right and got a GND > line in between them, without too much disruption. thank you for > prompting me to do that. Amazing! Just a nitpick left. You mentioned the GND flood-fill distance is 10mil. That means that GND will 10 mil removed from tracks. Personally I'd trace the GND as close as possible to the diff signals. But that may be just overcautious. I don't have any fancy math like Richard so it might be FUD. Or just my mild form of OCD. :-) Or is that 10mil the minimum gap size? That would make sense. Anyway a picture of the flood-fill will reveal everything. From mike.valk at gmail.com Mon Aug 14 07:59:06 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Mon, 14 Aug 2017 08:59:06 +0200 Subject: [Arm-netbook] frickin funny In-Reply-To: References: Message-ID: 2017-08-13 15:49 GMT+02:00 Luke Kenneth Casson Leighton : > https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity LOL. Even EOMA gets mentioned. From lkcl at lkcl.net Mon Aug 14 12:14:41 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 14 Aug 2017 12:14:41 +0100 Subject: [Arm-netbook] riki200 revision.... 2 going on 3 Message-ID: ok so the intermediary etch-a-sketch concept "works", but i'm definitely going to go for the design you came up with, benson: pulley'd ultimaker-2. actually.... reviewing the forum messages the mistake that i made was in *not* following what you originally suggested! http://forums.reprap.org/read.php?177,767087,780154#msg-780154 putting the 2 belts back-to-back round the idler and GT2, it's now obvious that the inner and outer belts travel different lengths round the arcs... so you get "pulling". whoops. anyway out with that - i'll begin on the pulley-augmented ultimaker style. l. From mike.valk at gmail.com Mon Aug 14 12:23:21 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Mon, 14 Aug 2017 13:23:21 +0200 Subject: [Arm-netbook] PCB Collaboration and Revision Message-ID: https://hackaday.com/2011/10/14/hardware-version-control-using-visual-diff/ http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/ For the next project From lkcl at lkcl.net Mon Aug 14 12:28:41 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 14 Aug 2017 12:28:41 +0100 Subject: [Arm-netbook] PCB Collaboration and Revision In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Aug 14, 2017 at 12:23 PM, mike.valk at gmail.com wrote: > https://hackaday.com/2011/10/14/hardware-version-control-using-visual-diff/ > > http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/ > > For the next project useful *right now*! From richard.wilbur at gmail.com Mon Aug 14 16:58:13 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 14 Aug 2017 08:58:13 -0700 Subject: [Arm-netbook] PCB Collaboration and Revision In-Reply-To: References: Message-ID: I have successfully used DiffPDF to determine changes to the script for a play in which my daughters had parts. I only had to reprint ~10 of >60 pages. From lkcl at lkcl.net Mon Aug 14 18:26:00 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 14 Aug 2017 18:26:00 +0100 Subject: [Arm-netbook] PCB Collaboration and Revision In-Reply-To: References: Message-ID: On Mon, Aug 14, 2017 at 4:58 PM, Richard Wilbur wrote: > I have successfully used DiffPDF to determine changes to the script > for a play in which my daughters had parts. I only had to reprint ~10 of >60 pages. coool. i'm... puzzled why i haven't heard of it before, i could really have done with knowing about it when PADS manages to damage files by accidentally removing GND shielding vias (a known bug) l. From calmstorm at posteo.de Mon Aug 14 21:00:13 2017 From: calmstorm at posteo.de (zap) Date: Mon, 14 Aug 2017 16:00:13 -0400 Subject: [Arm-netbook] frickin funny In-Reply-To: References: Message-ID: <4378f431-9598-96f1-f19c-ee5eadf03f59@posteo.de> On 08/13/2017 09:49 AM, Luke Kenneth Casson Leighton wrote: > https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity > > i had no idea this article existed... i absolutely love the conclusion.... Ah yes, the good ol cable company putting the user first and letting them have the freedom to choose, wait a minute, did I say that they did that? my mistake I was thinking of the exact opposite... hmm... From richard.wilbur at gmail.com Mon Aug 14 22:37:29 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 14 Aug 2017 14:37:29 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: I have some time today to continue this discussion. Sent from my iPhone > On Aug 11, 2017, at 10:15, Richard Wilbur wrote: > On Thu, Aug 10, 2017 at 2:01 AM, mike.valk at gmail.com > wrote: >> GND shielding parallel to the differentials is interrupted quite >> often. Those GND tracks act as shields, for emission and reception. >> I'd try to put as much parallel GND as possible. >> >> And trace the parallel GND around the via's, see attachment. >> >> Make sure the'res as much solid GND on the layer above and below the >> traces, again shielding. microstrip differential-mode signal with ground shield traces ground signal+ signal- ground dielectric dielectric dielectric dielectric ground ground ground ground ground ground Here the dipole antenna remains small and the half-strength fields between each signal trace and its associated ground guard shield trace work to truncate electric fields in the plane of the PCB. The fields are still insignificant in far field (because the traces are close together, have opposite potential and currents, and the fields cancel each other). It seems the best argument for including ground shield traces on this layout might be to guard against coupling signals between differential pairs that were packed in too closely to otherwise meet the recommended distance between different signal pairs. But with the dimensions of our layout being the minimum allowed by the board fabricator, the min(s) = min(w) => d = s + w + s = 3 * s.[1] So if we were to remove the ground shield traces from between differential pairs we could meet the inter-pair spacing recommendations without moving anything else. This may explain the design by the wits-tech senior engineer you mentioned which worked without ground shield traces between the differential pairs. The ground shield traces surrounding a differential pair on the same layer will mostly block common-mode signal radiation and coupling. They will have little beneficial effect on differential signals--but can contribute asymmetric loading (lower single-ended impedance of one trace) to the differential pair (through asymmetric geometry) which will convert some differential energy into common-mode energy. In other words, if we are expecting significant common-mode signal, whether from pathologies in the layout or incompetence of the differential-mode signal driver, then ground shield traces may be in order. Regardless, caveat emptor (let the buyer beware): 1. asymmetries in ground guard shield implementation contribute to conversion of differential signal to common-mode signal (which for a differential receiver is noise, thus lowering signal-to-noise ratio), 2. symmetric ground guard shield traces reduce the single-ended impedance of both traces of the differential pair, lowering the differential impedance of the pair. The effect is distance-dependent, the greater the spacing the less-pronounced the effect. Another interesting reference on high-speed HDMI PCB layout is TI's SLLA324[2]. Notice how in none of the layouts pictured in Figures 4, 6, or 8 are there any ground shield traces. Judging from the eye diagrams in Figure 10, even with fairly close pair-to-pair spacing there doesn't seem to be significant cross-talk between the pairs (look for noise at transitions): 1. in the absence of ground shield traces 2. running at top speed of HDMI v1.4 (340MHz pixel clock, 1080p video, 3.4GHz data rate) 3. space between differential pairs doesn't seem to be all that large. Figure 4 looks like it depicts a similar connector (micro HDMI <=> type D) and it looks like they have a similar pair length relationship (which, interestingly enough, they don't seem to take any pains to equalize): length(D2) < length(D0) < length(D1) < length(CLK) So, for the HDMI differential signals' sake, we don't necessarily need: 1. Ground guard traces between neighboring differential pairs 2. Ground guard traces between HDMI differential pairs and other circuits 3. Multiple ground vias riveting along the side of the board to block emissions 4. Perfectly matched inter-pair lengths On the other hand: 1. Ground guard traces can be important in reducing noise radiated from single-ended circuits and coupled into other single-ended circuits on the board. 2. Ground fences, traces riveted with multiple ground vias, can help even more with the goals of "reducing noise radiated from and coupled into other single-ended circuits on the board" as above. In other words, if we had more board space there are several things we could do differently: increase differential pair trace width and spacing, ground shield trace spacing. But as it stands I believe it will likely work fine. Without changing anything else we could drop the ground shield traces which would serve to increase our differential impedance. We would want to retain the ground vias near signal vias. Reference: [1] HDMI, p. 5.2 [2] SLLA324, pp. 4-7 Bibliography: Texas Instruments (TI): "HDMI Design Guide", High-Speed Interface Products, June 2007, http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-138-01-00-00-10-65-80/Texas-Instruments-HDMI-Design-Guide.pdf Texas Instruments (TI): SLLA324 February 2012 Application Report, "TPD12S016 PCB Layout Guidelines for HDMI ESD" http://www.ti.com/lit/an/slla324/slla324.pdf From richard.wilbur at gmail.com Mon Aug 14 22:43:58 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 14 Aug 2017 14:43:58 -0700 Subject: [Arm-netbook] PCB Collaboration and Revision In-Reply-To: References: Message-ID: I hadn't heard of it before I needed it but upon searching it came up. Somebody else must have had the same need and used libre software to scratch the itch. From doark at mail.com Mon Aug 14 23:11:42 2017 From: doark at mail.com (David Niklas) Date: Mon, 14 Aug 2017 18:11:42 -0400 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: Message-ID: <20170814181142.6ebd5521@ulgy_thing> Luke, Is this the correct location of pyopenscad? http://forum.openscad.org/ANN-pyopenscad-spline-surface-generator-td21838.html Are there any other deps I should be aware of? Sincerely, David From richard.wilbur at gmail.com Tue Aug 15 00:08:00 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 14 Aug 2017 16:08:00 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: <06AA10CA-CB5E-43B8-A7F0-5FF19B6308FD@gmail.com> On Aug 10, 2017, at 23:12, Luke Kenneth Casson Leighton wrote: > > On Fri, Aug 11, 2017 at 12:37 AM, Richard Wilbur > wrote: > >> On Wed, Aug 9, 2017 at 7:23 AM, Luke Kenneth Casson Leighton >> wrote: >>> next set... >>> >>> wiggles.jpg is the layer 6 length-matching area: HX2N/P is the one >>> that's the longest, it snakes back on itself. i length-matched all 3 >>> signal pairs to 56.413, and left the CK lines at 57.134 just to give >>> the tiniest bit of delay (TI recommendations iirc). >> >> Very nicely done! 57.134mm - 56.413mm = 721um >> => T(delay) = 721um / 150um/ps = 4.8ps > >> That is a very tiny delay! I would need to do more research to make a meaningful recommendation. Sorry for bringing up a topic I wasn't prepared to discuss intelligently. Let's go with what you've done. According to my calculations you could get away without any inter-pair skew compensation on the board whatsoever and still meet the HDMI specification for the transmitter budget. What you have done regarding inter-pair skew compensation reserves nearly all of the transmitter inter-pair skew budget from the HDMI standard for the connector and the rest of the system. This will serve to accommodate less than optimal inter-pair skew imposed by the cable and/or receiver. >> Now that we have achieved such close >> synchronization, I'm suggesting we go for the next goal where we >> design a certain amount of inter-pair skew into the layout for >> purposes of lowering the strength of our synchronized pulsing data >> lines to a more diffuse chatter. > > *deep breath*.... aaaaaaaa! :) > > well.... that actually happens for the majority of the length in the > middle (starting layer 6) > > but.... if i simply *take out* the intermediary wiggles on layer 6.... Ill-founded proposal for which I don't presently have the time to improve. >>> no - not even enough space to do 5.1mil / 5.0 clearance... just... too much. >> >> I understand. We might end up with more room--see discussion below. > > which has probably been truncated... Turns out we don't have the room to change the trace width or spacing without having a deleterious effect on impedance. From eaterjolly at gmail.com Tue Aug 15 03:25:25 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 14 Aug 2017 22:25:25 -0400 Subject: [Arm-netbook] frickin funny In-Reply-To: <4378f431-9598-96f1-f19c-ee5eadf03f59@posteo.de> References: <4378f431-9598-96f1-f19c-ee5eadf03f59@posteo.de> Message-ID: It's funny part of the legacy though, being that the FCC adopted it in an attempt to force cable companies to give people choice. On 8/14/17, zap wrote: > On 08/13/2017 09:49 AM, Luke Kenneth Casson Leighton wrote: > >> https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity >> >> i had no idea this article existed... i absolutely love the conclusion.... > Ah yes, the good ol cable company putting the user first and letting > them have the freedom to choose, wait a minute, did I say that they did > that? my mistake I was thinking of the exact opposite... hmm... > > > > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Tue Aug 15 07:33:56 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 15 Aug 2017 07:33:56 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <06AA10CA-CB5E-43B8-A7F0-5FF19B6308FD@gmail.com> References: <06AA10CA-CB5E-43B8-A7F0-5FF19B6308FD@gmail.com> Message-ID: On Tue, Aug 15, 2017 at 12:08 AM, Richard Wilbur wrote: > I would need to do more research to make a > meaningful recommendation. Sorry for bringing up > a topic I wasn't prepared to discuss intelligently. > Let's go with what you've done. hey this is all extremely worthwhile. it's me who is barely able to follow along. > According to my calculations you could get away without > any inter-pair skew compensation on the board whatsoever > and still meet the HDMI specification for the transmitter budget. ah ha!! that would be better, it's quite a mess to be honest. > What you have done regarding inter-pair skew compensation > reserves nearly all of the transmitter inter-pair skew budget > from the HDMI standard for the connector and the rest of the > system. This will serve to accommodate less than optimal > inter-pair skew imposed by the cable and/or receiver. .... i'm translating this to mean "lose the large middle set of wiggles on TX0, TX1 and TX2". they're bugging me anyway ("beauty" criteria) plus, we know that the very first design.. i should open that up shouldn't i... never had large wiggles and it worked fine. looking at it now, the guy who designed it had all the vias coming out from the CPU in a straight line, no diff-pair via considerations *at all*, ran the CK lines right past *all* those vias, but, butbutbut, he put CK on layer 6, TX0-2 on layer 3 i'm amazed it worked. > Turns out we don't have the room to change the trace width or spacing without having a deleterious effect on impedance. blech :) l. From lkcl at lkcl.net Tue Aug 15 07:39:16 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 15 Aug 2017 07:39:16 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Mon, Aug 14, 2017 at 10:37 PM, Richard Wilbur wrote: > I have some time today to continue this discussion. awesome. > So if we were to remove the ground shield traces > from between differential pairs we could meet the > inter-pair spacing recommendations without moving > anything else. This may explain the design by the > wits-tech senior engineer you mentioned which worked > without ground shield traces between the differential pairs. yehyeh. i could then move them slightly away from the edge of the board. > Another interesting reference on high-speed HDMI PCB layout is TI's SLLA324[2]. nnniiiiiice. i love it. that's exactly the same connector being used. hmmm iinteresting, they bring the vias up from underneath on all 4 diff-pairs... > So, for the HDMI differential signals' sake, we don't necessarily need: > 1. Ground guard traces between neighboring differential pairs > 2. Ground guard traces between HDMI differential pairs and other circuits > 3. Multiple ground vias riveting along the side of the board to block emissions > 4. Perfectly matched inter-pair lengths hmmm.... > On the other hand: > 1. Ground guard traces can be important in reducing noise radiated from single-ended circuits and coupled into other single-ended circuits on the board. > 2. Ground fences, traces riveted with multiple ground vias, can help even more with the goals of "reducing noise radiated from and coupled into other single-ended circuits on the board" as above. > > In other words, if we had more board space there are several things we could do differently: increase differential pair trace width and spacing, ground shield trace spacing. > > But as it stands I believe it will likely work fine. Without changing anything else we could drop the ground shield traces which would serve to increase our differential impedance. i think i will do that. > We would want to retain the ground vias near signal vias. yehyeh. From lkcl at lkcl.net Tue Aug 15 07:41:57 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 15 Aug 2017 07:41:57 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: <20170814181142.6ebd5521@ulgy_thing> References: <20170814181142.6ebd5521@ulgy_thing> Message-ID: On Mon, Aug 14, 2017 at 11:11 PM, David Niklas wrote: > Luke, > Is this the correct location of pyopenscad? > http://forum.openscad.org/ANN-pyopenscad-spline-surface-generator-td21838.html yes. do let me know how you get on, it would be good to have a double-check from someone that i got the files right. > Are there any other deps I should be aware of? python2, openscad... thaaat's... about it :) l. From vkontogpls at gmail.com Tue Aug 15 09:32:15 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Tue, 15 Aug 2017 11:32:15 +0300 Subject: [Arm-netbook] frickin funny In-Reply-To: References: Message-ID: Luke Kenneth Casson Leighton wrote: > https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity A year or 2 back I was reading Cory Doctorow's Little Brother and I was wondering "what happened to the upgradable personal electronics he envisioned", we were clearly heading that way in the 90s. And it's not like upgradable electronics would be the end all be all, the world would still be able to monitor us as usual. We could have had both faster and more upgradable laptops today, yet we are still trying to reverse engineer apple's pin shuffling on their macbook pro ssds... Luckily Luke stepped in the game to show them off :) From jah at jahboite.co.uk Tue Aug 15 09:58:31 2017 From: jah at jahboite.co.uk (jah) Date: Tue, 15 Aug 2017 09:58:31 +0100 Subject: [Arm-netbook] frickin funny In-Reply-To: References: Message-ID: <5992B7B7.4000708@jahboite.co.uk> On 13/08/17 14:49, Luke Kenneth Casson Leighton wrote: > https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity Does anybody have a link to an alternative page on which the text is displayed without requiring javascript? I'll never understand why some folk eschew progressive enhancement of web pages. grumble grumble grumble. jah From listmaster at beauxbead.com Tue Aug 15 15:06:46 2017 From: listmaster at beauxbead.com (KRT Listmaster) Date: Tue, 15 Aug 2017 08:06:46 -0600 Subject: [Arm-netbook] frickin funny In-Reply-To: <5992B7B7.4000708@jahboite.co.uk> References: <5992B7B7.4000708@jahboite.co.uk> Message-ID: <5e6b4e4b-3ca3-7abb-48de-a39eb423b60f@beauxbead.com> On 08/15/2017 02:58 AM, jah wrote: > On 13/08/17 14:49, Luke Kenneth Casson Leighton wrote: >> https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity > > Does anybody have a link to an alternative page on which the text is > displayed without requiring javascript? > > I'll never understand why some folk eschew progressive enhancement of > web pages. grumble grumble grumble. > > jah The original blog seems to be NoScript-friendly. http://tedium.co/2017/01/26/pcmcia-pc-card-laptop-expansion-history/ -- This email account is used for list management only. From jah at jahboite.co.uk Tue Aug 15 15:57:15 2017 From: jah at jahboite.co.uk (jah) Date: Tue, 15 Aug 2017 15:57:15 +0100 Subject: [Arm-netbook] frickin funny In-Reply-To: <5e6b4e4b-3ca3-7abb-48de-a39eb423b60f@beauxbead.com> References: <5992B7B7.4000708@jahboite.co.uk> <5e6b4e4b-3ca3-7abb-48de-a39eb423b60f@beauxbead.com> Message-ID: <59930BCB.5060400@jahboite.co.uk> On 15/08/17 15:06, KRT Listmaster wrote: > The original blog seems to be NoScript-friendly. > > http://tedium.co/2017/01/26/pcmcia-pc-card-laptop-expansion-history/ Perfect. Thank you. From richard.wilbur at gmail.com Wed Aug 16 06:11:13 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 15 Aug 2017 22:11:13 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> > On Aug 14, 2017, at 23:39, Luke Kenneth Casson Leighton wrote: > > On Mon, Aug 14, 2017 at 10:37 PM, Richard Wilbur > wrote: >> >> So if we were to remove the ground shield traces from between differential pairs we could meet the inter-pair spacing recommendations without moving anything else. This may explain the design by the wits-tech senior engineer you mentioned which worked without ground shield traces between the differential pairs. > > 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. The ground shield traces with 5mil spacing, 5mil trace width, and another 5mil spacing enforce this spacing on the differential signal traces. So if we remove the ground shield traces, and don't move anything closer, we get that spacing for previous effort. Are you talking about moving the differential pairs further from the edge of the board? I'm guessing since there is a ground shield trace along the edge presently, that the ground shield trace would make the distance from the nearest differential trace to board edge at least s + w = 10mil. If the ground shield trace is 5mil from board edge then we have 15mil from nearest differential trace to board edge. >> Another interesting reference on high-speed HDMI PCB layout is TI's SLLA324[2]. > > nnniiiiiice. i love it. that's exactly the same connector being > used. hmmm iinteresting, they bring the vias up from underneath on > all 4 diff-pairs... I think that is to keep the path as similar for all 4 pairs as possible. Vias add delay and (if not properly tuned) reduce the impedance. So it seems they are working with the stratagem that it is better to treat each component of the signal the same. From lkcl at lkcl.net Wed Aug 16 07:31:17 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 16 Aug 2017 07:31:17 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> Message-ID: On Wed, Aug 16, 2017 at 6:11 AM, Richard Wilbur 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 :) > The ground shield traces with 5mil spacing, 5mil trace width, > and another 5mil spacing enforce this spacing on the differential signal traces. > So if we remove the ground shield traces, and don't move anything closer, > we get that spacing for previous effort. ha! ok. so. if i just take *out* the ground intermediary traces that would do the trick of bringing the impedance back up, is that right? what would you suggest, here - leave the intermediary GND traces in or take them out. 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. why? 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. > 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. >>> Another interesting reference on high-speed HDMI PCB layout is TI's SLLA324[2]. >> >> nnniiiiiice. i love it. that's exactly the same connector being >> used. hmmm iinteresting, they bring the vias up from underneath on >> all 4 diff-pairs... > > I think that is to keep the path as similar for all 4 pairs as possible. yehyeh. > Vias add delay and (if not properly tuned) reduce the impedance. > So it seems they are working with the stratagem that it is > better to treat each component of the signal the same. 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. l. From lkcl at lkcl.net Mon Aug 14 08:14:32 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 14 Aug 2017 08:14:32 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Mon, Aug 14, 2017 at 7:43 AM, mike.valk at gmail.com wrote: > 2017-08-13 14:20 GMT+02:00 Luke Kenneth Casson Leighton : >> btw yes i managed to move IPSOUT slightly to the right and got a GND >> line in between them, without too much disruption. thank you for >> prompting me to do that. > > Amazing! Just a nitpick left. You mentioned the GND flood-fill > distance is 10mil. That means that GND will 10 mil removed from > tracks. Personally I'd trace the GND as close as possible to the diff > signals. But that may be just overcautious. ok sorry, i was slightly wrong. clearance is also 5mil but there's something called "rounding" on the flood fill which stops it from curving into tight spaces. > I don't have any fancy math like Richard so it might be FUD. Or just > my mild form of OCD. :-) :) > Or is that 10mil the minimum gap size? That would make sense. > > Anyway a picture of the flood-fill will reveal everything. attached. greyscaled (smaller). original GND tracks are still visible but they're *combined* with the floodfill. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 59429 bytes Desc: not available URL: From mike.valk at gmail.com Wed Aug 16 10:31:34 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Wed, 16 Aug 2017 11:31:34 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-14 9:14 GMT+02:00 Luke Kenneth Casson Leighton : > On Mon, Aug 14, 2017 at 7:43 AM, mike.valk at gmail.com > wrote: >> Anyway a picture of the flood-fill will reveal everything. > > attached. greyscaled (smaller). original GND tracks are still > visible but they're *combined* with the floodfill. > Looks pretty. Seeing that does raise a question too me. Is it necessary to match length between the different pairs? I didn't think that was a requirement. Because I see pairs wriggling and wasting a lot of space. I thought that only matching was required on a single pair. Impedance matching. From lkcl at lkcl.net Wed Aug 16 10:33:02 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 16 Aug 2017 10:33:02 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: On Wed, Aug 16, 2017 at 10:31 AM, mike.valk at gmail.com wrote: > Looks pretty. Seeing that does raise a question too me. Is it > necessary to match length between the different pairs? I didn't think > that was a requirement. Because I see pairs wriggling and wasting a > lot of space. > > I thought that only matching was required on a single pair. Impedance matching. that's what we've been discussing. read richard's message and my response. l. From mike.valk at gmail.com Wed Aug 16 14:17:21 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Wed, 16 Aug 2017 15:17:21 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-16 11:33 GMT+02:00 Luke Kenneth Casson Leighton : > On Wed, Aug 16, 2017 at 10:31 AM, mike.valk at gmail.com > wrote: > >> Looks pretty. Seeing that does raise a question too me. Is it >> necessary to match length between the different pairs? I didn't think >> that was a requirement. Because I see pairs wriggling and wasting a >> lot of space. >> >> I thought that only matching was required on a single pair. Impedance matching. > > that's what we've been discussing. read richard's message and my response. I've read it again. But did not digest that from Richard's responses. Inter-pair skew: Length (un)matching between two traces making op one differential pair? Intra-pair skew: Length (un)matching between differential pairs? Not mentioned. What else I read so far: Possibly remove the GND traces between pairs. Differential pairs are designed to cancel each other out thus limit radiation. The pair coupling creates force to repel incoming radiation noise. Correct me if I'm wrong The same construction as in twisted pair cables. But there you have differential pair twisting creates an even bigger effect. But there we also have types with shielding. Shielding around the whole set and even with shielding per pair. The HMDI cables I've butchered had per pair shielding and the other lines, clock, cec, etc, unshielded bundled in one extra shield. Removing the, intra pair, GND traces improves impedance, but decreases shielding from external incoming radiation. But I suspect that effect is limited due to the GND layer below, far bigger and nearer than those traces. Differential pairs should have a bigger, dielectric, space surrounding them than they have to each other. Because the nearer you get to a pair the less the differential cancelling effect. With the exception for GND, which should act as a sink for EM emissions. Removing the, intra pair, GND traces won't give you more space because the pairs should keep the extra distance from each other. Via's should occur only when, inter pair, length is matched. Differential via's should have a rounded, oval, common, dielectric, space surrounding them so the Z-axis radiation can cancel out uninterrupted. Digital differential signals might be skewed to begin with. Limiting the differential EM canceling effect to begin with. I'd say keep the intra pair GND traces. Maybe loose the intra pair length mathing. There should be no electric/magnetic coupling between intra pairs. But if their length differs the parallel digital signals might become time skewed. But I doubt that on this length that would be a problem. Richards math should help with that along with max allowed digital signal skew. Don't have the time to convert the math in a spreadsheet calculator to confirm. From mike.valk at gmail.com Wed Aug 16 17:10:39 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Wed, 16 Aug 2017 18:10:39 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: 2017-08-16 15:17 GMT+02:00 mike.valk at gmail.com : > 2017-08-16 11:33 GMT+02:00 Luke Kenneth Casson Leighton : >> On Wed, Aug 16, 2017 at 10:31 AM, mike.valk at gmail.com >> wrote: >> >>> Looks pretty. Seeing that does raise a question too me. Is it >>> necessary to match length between the different pairs? I didn't think >>> that was a requirement. Because I see pairs wriggling and wasting a >>> lot of space. >>> >>> I thought that only matching was required on a single pair. Impedance matching. >> >> that's what we've been discussing. read richard's message and my response. > > I've read it again. But did not digest that from Richard's responses. > > Inter-pair skew: Length (un)matching between two traces making op one > differential pair? > > Intra-pair skew: Length (un)matching between differential pairs? Not mentioned. Ah it seems it's the other way around. Silly me. I knew why I kept away from the intra and inter prefixes. I always switch them. > The HMDI cables I've butchered had per > pair shielding and the other lines, clock, cec, etc, unshielded > bundled in one extra shield. Sorry. Clock is also one of the diff-pairs. As well as pin 17 and 19, HEAC, Utilized for ARC (S/PDIF) and Ethernet. But not in the A20 so less of a problem. > Richards math should help with that along with max allowed digital > signal skew. Don't have the time to convert the math in a spreadsheet > calculator to confirm. Hmm not the only ones out there with these questions. https://e2e.ti.com/support/interface/high_speed_interface/f/138/t/267205 "intra-pair length mismatch is recommended to be less than 5mils, inter-pair length mismatch is less of a concern but the recommendation is to keep the traces <2" and keep the clock slightly longer than the data traces." Keeping the clock longer makes sense. All the data is buffered before the clock signal arrives. https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter-pair-synchronization.75801/ 5bits of buffer. http://ieeexplore.ieee.org/document/1706346/ https://www.researchgate.net/publication/224650488_Effects_of_skew_on_EMI_for_HDMI_connectors_and_cables paywall, blegh. Put in a request on the second one. Let's see https://www.infocomm.org/cps/rde/xbcr/infocomm/Dietro_HDMI.pdf That explained the "eye diagrams". Overlapping differential signals. Hmm 1bit buffer? 1920x1080p60 = 148.5 Mhz From richard.wilbur at gmail.com Thu Aug 17 00:01:39 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 16 Aug 2017 16:01:39 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> Message-ID: <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> On Aug 15, 2017, at 23:31, Luke Kenneth Casson Leighton wrote: > > On Wed, Aug 16, 2017 at 6:11 AM, Richard Wilbur > 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. From lkcl at lkcl.net Thu Aug 17 06:22:40 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 17 Aug 2017 06:22:40 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: On Thu, Aug 17, 2017 at 12:01 AM, Richard Wilbur wrote: >> 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. ok. > 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. flood-fill will just end up putting them back - i'd have to set a copper-to-trace separation @ 15mil as well. there's one place where the diffpairs go past the main power line (IPSOUT) - that's got a 5 mil copper GND separating it at present: i'd be nervous about taking that out. > 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, o arse: *receiver* not transmitter. > 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. 22 mm... okaaay. > From what I've seen, even without inter-pair skew compensation in the layout the inter-pair skew you observed was ~8mm < 22mm. 9. or so. okaaay now i get it. > If this is indeed how it works then I'll need to rethink my recommendations. (I outlined my understanding above.) nono, my mistake. >>> 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? 0.9mm -> 35 mil. to the nearest vias is 0.2mm -> 0.787mil l. From mike.valk at gmail.com Thu Aug 17 07:28:06 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 17 Aug 2017 08:28:06 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: 2017-08-17 1:01 GMT+02:00 Richard Wilbur : > On Aug 15, 2017, at 23:31, Luke Kenneth Casson Leighton wrote: >> 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. > How about the ground plane below the traces... That's a major stray capacitance and closer than the "narrow" surrounding GND traces? From lkcl at lkcl.net Thu Aug 17 07:42:58 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 17 Aug 2017 07:42:58 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: On Thu, Aug 17, 2017 at 7:28 AM, mike.valk at gmail.com wrote: > How about the ground plane below the traces... That's a major stray > capacitance and closer than the "narrow" surrounding GND traces? good question! From mike.valk at gmail.com Thu Aug 17 08:08:03 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 17 Aug 2017 09:08:03 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: 2017-08-17 7:22 GMT+02:00 Luke Kenneth Casson Leighton : > On Thu, Aug 17, 2017 at 12:01 AM, Richard Wilbur > wrote: >> 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. > > flood-fill will just end up putting them back - i'd have to set a > copper-to-trace separation @ 15mil as well. > Isn't there a option to create barriers or free form where the floodfill may not come, white spaces so to speak. Seems to me there should be. You should be able to create "white" spots on the GND planes for various reasons. From lkcl at lkcl.net Thu Aug 17 08:30:41 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 17 Aug 2017 08:30:41 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: On Thu, Aug 17, 2017 at 8:08 AM, mike.valk at gmail.com wrote: >> flood-fill will just end up putting them back - i'd have to set a >> copper-to-trace separation @ 15mil as well. >> > Isn't there a option to create barriers or free form where the > floodfill may not come, white spaces so to speak. Seems to me there > should be. there is..... however that would mean having to maintain an exact and specific mirror of the exact path of the traces, whereby any changes *to* the exact and specific path of the traces would require a corresponding, exact, specific and precisely and without fail 100% matching change to that area. total pain in the ass in other words. ... on the other hand simply changing *one parameter* in the design rules achieves the exact same result... done dynamically and with no fuss. > You should be able to create "white" spots on the GND > planes for various reasons. indeed. From richard.wilbur at gmail.com Thu Aug 17 17:20:34 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 17 Aug 2017 09:20:34 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> On Aug 16, 2017, at 22:22, Luke Kenneth Casson Leighton wrote: > On Thu, Aug 17, 2017 at 12:01 AM, Richard Wilbur > wrote: >> […] >> 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. > > flood-fill will just end up putting them back - i'd have to set a > copper-to-trace separation @ 15mil as well. Sounds like just the ticket. So you have a flood-fill on the bottom layer? Is the flood-fill connected to GND? Can you set the 15mil copper-to-trace separation as a property of the differential traces? The goal with this 15mil clearance is to space other copper in the same plane far enough away to have a negligible effect on the differential impedance of the differential pair and by the same token negligible high-frequency signal coupling. The microstrip differential pair geometry is based on having ground plane (may it extend forever ;>) underneath the traces separated by a dielectric of thickness t. (We took that into account in the impedance calculations. Actually power and ground are identical from the perspective of high-frequency signals so we could have built our microstrip differential pair over a power plane--or even moved from one reference plane to another. If we change reference planes, then we need to provide a low-impedance at high frequency path for any return current. Since we used two different ground planes, plated through-hole vias work well. If we had used planes at different potentials we would couple through capacitors.) > there's one place where the diffpairs go past the main power line > (IPSOUT) - that's got a 5 mil copper GND separating it at present: i'd > be nervous about taking that out. I wouldn't worry because that 5mil copper GND has 5mil spacing on each side, thus ensuring 15mil between the closest differential trace and power. That should be sufficient. On the other hand, if I remember correctly the proximity to IPSOUT happened because we decided to do significant inter-pair skew compensation close to the power circuit. If we remove that inter-pair compensation, we may have enough space to keep that ground trace around IPSOUT and still make our 15mil clearance around the differential pairs. The other thing that we can do if we have a little extra space after taking out the intermediary GND shield traces and inter-pair skew compensation wiggles is distribute the intra-pair skew compensation closer to the sources of intra-pair skew--corners. Right now you've done a great job of compensating for intra-pair skew in the first segment: from CPU lands to first via. Then there are some very significant wiggles when we first get to the bottom layer and I don't see any other intra-pair skew compensation all the way out to the connector. If we can do it, the most effective place for intra-pair skew compensation is within 15mil of the skew source--right before or after a bend. If skew originates in a bend and is resolved by a complementary bend within 15mils, then we don't need to add anything specific. If we distribute the intra-pair skew compensation as outlined above we will likely be able to accomplish it with some pretty small wiggles which may fit more easily into the available space. […] >> 1. The receiver has the capability to recover up to 5 bit times of inter-pair skew, > > o arse: *receiver* not transmitter. No problem then. But it sure highlights the importance of having the correct perspective when thinking about the problem.:) (I have trouble with it too, at times. The right perspective often makes the problem much more tractable.) […] >> 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. > > 22 mm... okaaay. > >> From what I've seen, even without inter-pair skew compensation in the layout the inter-pair skew you observed was ~8mm < 22mm. > > 9. or so. okaaay now i get it. You can see how I came to the conclusion that we will likely be fine without any inter-pair skew compensation--with even a pretty generous engineering margin. >>>> 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? > > 0.9mm -> 35 mil. > > to the nearest vias is 0.2mm -> 0.787mil How far is the board-edge ground shield trace from the edge of the board? From the closest differential pair trace? How wide is the board-edge ground shield trace? I'm guessing you meant the closest vias to the differential pair traces are 0.2mm = 7.87mil? Are these the ground-to-ground vias for low-impedance connection of reference planes? (Low-impedance return path close to signal vias?) From richard.wilbur at gmail.com Thu Aug 17 17:30:49 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 17 Aug 2017 09:30:49 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> Message-ID: <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> On Aug 16, 2017, at 23:28, "mike.valk at gmail.com" wrote: > > 2017-08-17 1:01 GMT+02:00 Richard Wilbur : >>> On Aug 15, 2017, at 23:31, Luke Kenneth Casson Leighton wrote: >>> 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. >> > > How about the ground plane below the traces... That's a major stray > capacitance and closer than the "narrow" surrounding GND traces? The ground plane would be stray except we designed it into the single-ended and differential impedance. At this point it is integral to our differential microstrip geometry. (See my original post in the thread "HDMI High-Frequency Layout: Impedance".) From richard.wilbur at gmail.com Thu Aug 17 19:59:16 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 17 Aug 2017 11:59:16 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: Message-ID: <11AEC1A9-D7C5-4857-84FC-F1D373207129@gmail.com> On Aug 14, 2017, at 00:14, Luke Kenneth Casson Leighton wrote: > > On Mon, Aug 14, 2017 at 7:43 AM, mike.valk at gmail.com > wrote: >> 2017-08-13 14:20 GMT+02:00 Luke Kenneth Casson Leighton : > >> I don't have any fancy math like Richard so it might be FUD. Or just >> my mild form of OCD. :-) > > :) I'm sorry if any of this looks like fancy mathematics. (As someone whose first degree is in mathematics, I thought this was all very mundane algebra at best. I didn't get into field theory, Maxwell's equations [partial differential], et cetera.) >> Anyway a picture of the flood-fill will reveal everything. > > attached. greyscaled (smaller). original GND tracks are still > visible but they're *combined* with the floodfill. So I enjoyed looking at the picture but I'm curious what I'm looking at. Is this one layer? Which layer? What does the black mean? What about the gray? From mike.valk at gmail.com Thu Aug 17 22:24:32 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 17 Aug 2017 23:24:32 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <11AEC1A9-D7C5-4857-84FC-F1D373207129@gmail.com> References: <11AEC1A9-D7C5-4857-84FC-F1D373207129@gmail.com> Message-ID: 2017-08-17 20:59 GMT+02:00 Richard Wilbur : > On Aug 14, 2017, at 00:14, Luke Kenneth Casson Leighton wrote: >> >> On Mon, Aug 14, 2017 at 7:43 AM, mike.valk at gmail.com >> wrote: >>> 2017-08-13 14:20 GMT+02:00 Luke Kenneth Casson Leighton : >> >>> I don't have any fancy math like Richard so it might be FUD. Or just >>> my mild form of OCD. :-) >> >> :) > > I'm sorry if any of this looks like fancy mathematics. (As someone whose first degree is in mathematics, I thought this was all very mundane algebra at best. I didn't get into field theory, Maxwell's equations [partial differential], et cetera.) It is fancy math. And it is mundane. I didn't have the time refresh my electrical formulas and/or follow yours. So it simply needs time and attention. Formulas don't teach you what's going on. It's applying/verifying/quantifying your understaning of the subject. Any one can apply simple formulas. But when you don't understand where they come from you are just repeating tricks with the risk of doing it wrong. Your formulas are however infinitely more valuable then the fixed recommendations but require more time to understand, verify and use: http://www.ti.com/lit/an/spraar7g/spraar7g.pdf figure 13 That document has some nice recommendations. I've been away from electrical calculations for 16 years now. So they need time to enter my mind again and become applicable. > >>> Anyway a picture of the flood-fill will reveal everything. >> >> attached. greyscaled (smaller). original GND tracks are still >> visible but they're *combined* with the floodfill. > > So I enjoyed looking at the picture but I'm curious what I'm looking at. Is this one layer? Which layer? What does the black mean? What about the gray? The normal traces are all in black. The GND fill is gray. If a trace is GND the fill distance is 0 if not 5 thus connecting the GND traces to the GND fill > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From mike.valk at gmail.com Thu Aug 17 22:44:28 2017 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Thu, 17 Aug 2017 23:44:28 +0200 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> Message-ID: 2017-08-17 18:30 GMT+02:00 Richard Wilbur : > On Aug 16, 2017, at 23:28, "mike.valk at gmail.com" wrote: >> >> 2017-08-17 1:01 GMT+02:00 Richard Wilbur : >>>> On Aug 15, 2017, at 23:31, Luke Kenneth Casson Leighton wrote: >>>> 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. After thinking it through I have to agree. Each GND trace would become coupled with the diff pairs. Effectively creating a link between two pairs. Which we do not want. >>> >> >> How about the ground plane below the traces... That's a major stray >> capacitance and closer than the "narrow" surrounding GND traces? > > The ground plane would be stray except we designed it into the single-ended and differential impedance. At this point it is integral to our differential microstrip geometry. (See my original post in the thread "HDMI High-Frequency Layout: Impedance".) I'll read that again. I guess we just need to make sure that no other GND loop crosses the HDMI plane. Perhaps create a barrier on the GND that follows the outer HDMI traces. To prevent unwanted GND loops http://www.ti.com/lit/ml/slyp173/slyp173.pdf From doark at mail.com Thu Aug 17 23:24:51 2017 From: doark at mail.com (doark at mail.com) Date: Thu, 17 Aug 2017 18:24:51 -0400 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: <20170807184639.00566acd@ulgy_thing> Message-ID: On Thu, 10 Aug 2017 05:43:48 -0400 Luke Kenneth Casson Leighton wrote: > https://math.stackexchange.com/ (bla) > > hiya david: okay! so someone kindly edited the question to put the > proper links in, so the question's actually understandable. > > so... benson.... with the diagrams that aretino kindly added, i was > able to not only understand what he was saying, but, also, understood > it well enough to appreciate that *your* answer is correct :) > > aretino recommends using arccos instead of arcsin. > Luke, just getting through my emails, does this mean that you have your problem solved or were you referring this info for my benefit? Thanks, David From lkcl at lkcl.net Fri Aug 18 06:58:54 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 18 Aug 2017 06:58:54 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: <20170807184639.00566acd@ulgy_thing> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 17, 2017 at 11:24 PM, wrote: > On Thu, 10 Aug 2017 05:43:48 -0400 > Luke Kenneth Casson Leighton wrote: >> >> https://math.stackexchange.com/ (bla) >> >> hiya david: okay! so someone kindly edited the question to put the >> proper links in, so the question's actually understandable. >> >> so... benson.... with the diagrams that aretino kindly added, i was >> able to not only understand what he was saying, but, also, understood >> it well enough to appreciate that *your* answer is correct :) >> >> aretino recommends using arccos instead of arcsin. >> > > Luke, just getting through my emails, does this mean that > you have your problem solved that's incorrect. > or were you referring this info for my benefit? that is correct. if you look at the source code (git cloned or simply verify belts.py manually) you will see that there have been no commits which implement the algorithm. i have too much else to do, so your help is very much needed. l. From richard.wilbur at gmail.com Fri Aug 18 17:51:31 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 18 Aug 2017 09:51:31 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> Message-ID: <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> On Aug 17, 2017, at 14:44, "mike.valk at gmail.com" wrote: > I guess we just need to make sure that no other GND loop crosses the > HDMI plane. Perhaps create a barrier on the GND that follows the outer > HDMI traces. To prevent unwanted GND loops > > http://www.ti.com/lit/ml/slyp173/slyp173.pdf (Thank you for the link to another interesting high-frequency circuit and PCB layout reference. It concentrates on analog circuits but still has good wisdom and recommendations.) Since we are routing the highest speed signals as a differential pair, and to the extent that we are able to create a differential microstrip transmission line, our biggest return current will be through the neighboring trace of the differential pair. Since our differential microstrip transmission line will not be perfect, we are using ground vias to provide a low-impedance path for return currents across changes in the associated ground plane. You bring up an interesting point: what other current return paths are in the same vicinity? I have not analyzed that in any detail. At least there are no other lines from signal source to signal sink that I know of that cross the region of the board where the high-frequency HDMI signals are routed. Also, to my knowledge we don't have segmented or restricted ground planes that would isolate regions with a higher-impedance reference. From lkcl at lkcl.net Sat Aug 19 03:54:37 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 03:54:37 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> Message-ID: On Thu, Aug 17, 2017 at 5:20 PM, Richard Wilbur wrote: >> flood-fill will just end up putting them back - i'd have to set a >> copper-to-trace separation @ 15mil as well. > > Sounds like just the ticket. So you have a flood-fill on the bottom layer? all layers. > Is the flood-fill connected to GND? only when it's properly arranged to be so... i.e. when you don't you get a warning... short answer: yes. > Can you set the 15mil copper-to-trace separation as a property of the differential traces? yyup. i really like PADS for this reason > The goal with this 15mil clearance is to space other copper > in the same plane far enough away to have a negligible effect > on the differential impedance of the differential pair and by the > same token negligible high-frequency signal coupling. okaaay. i get it. > The microstrip differential pair geometry is based on having ground > plane (may it extend forever ;>) :) > underneath the traces separated by a dielectric of thickness t. > (We took that into account in the impedance calculations. yehyeh. > Actually power and ground are identical from the perspective of > high-frequency signals so we could have built our microstrip > differential pair over a power plane--or even moved from one > reference plane to another. ohhh that explains why DDR3 has a big power-plane @ the 1/2 way "reference" voltage. nice. >> there's one place where the diffpairs go past the main power line >> (IPSOUT) - that's got a 5 mil copper GND separating it at present: i'd >> be nervous about taking that out. > > I wouldn't worry because that 5mil copper GND has > 5mil spacing on each side, thus ensuring 15mil between the closest > differential trace and power. That should be sufficient. ... need to check it. > On the other hand, if I remember correctly the proximity to IPSOUT > happened because we decided to do significant inter-pair skew > compensation close to the power circuit. ah no: it's always been very close: in this revision i particularly wanted the vias left of the rclamp0524p to be reasonably symmetrical and clean, with a straight (diff-paired) path to the rclamp0524p instead of taking a turn to get to it (as in previous revisions). that required a little bit more space, which meant moving IPSOUT's vias a little bit further over. i could _probably_ move them over a bit further... > The other thing that we can do if we have a little extra space > after taking out the intermediary GND shield traces and inter-pair > skew compensation wiggles is distribute the intra-pair skew > compensation closer to the sources of intra-pair skew--corners. aw poop - changing those is quite a task. there's some bugs due to a combination of grid snap and push-and-shove in PADS where removing the long straights means i can't add them back in again. and i need to remove them because otherwise i don't know how long the traces are from the vias. what i do is: * remove the long sections * re-add a *short* diffpair section of only about 1mm * those end up being equal length * then because the traces aren't complete PADS will tell you exactly how long they are * therefore i can now measure them both and... * therefore i know exactly how much manual "wiggle" to put in the shorter one. once the wiggles are done i can re-add the long sections, confident that the signals will be matched. but it's a pain to do! :) > Right now you've done a great job of compensating for intra-pair > skew in the first segment: from CPU lands to first via. yehyeh. they're near-identical. > Then there are some very significant wiggles when we first get > to the bottom layer yes. intra-pair correction due to wanting to have the 1st layer traces all the same length. it's nearly... 1.5mm to correct, due to not just the offset of the vias but also the turn. if i tried to stagger those first vias the other way (which i tried once) then there's not enough room to have those 1st trace segments be equal length... > and I don't see any other intra-pair skew > compensation all the way out to the connector. that's because they're all fine... ok i read somewhere that it's ok to have some intra-pair skew on short lengths between turns. sooOo... i'm assuming that the critical part is the long straight. sooOOo i arranged for the wiggles to make perfect length-matching just as each pair hits the beginning of each long straight. now (and i've removed the inter-pair skew in the current revision) what i *haven't* done is add in any inter-skew correction at the points marked in green (attached). i'm assuming that those diagonal cross-paths (between each green ring) are... within acceptable tolerance for intra-skew. > If we can do it, the most effective place for intra-pair skew compensation > is within 15mil of the skew source--right before or after a bend. > If skew originates in a bend and is resolved by a complementary bend within 15mils, > then we don't need to add anything specific. mmmm *grumble, grumble*.... i think there might be space to add them, around where the green rings are, by moving the diagonal pieces to the right a bit. >>> How far are the differential traces from board edge at present? >> >> 0.9mm -> 35 mil. >> >> to the nearest vias is 0.2mm -> 0.787mil > > How far is the board-edge ground shield trace > from the edge of the board? to the edge of the GND shield trace: 0.46mm -> 18 mil > From the closest differential pair trace? to the edge of the CK diffpair, 0.93mm -> 36.6 mil > How wide is the board-edge ground shield trace? pffh :) peanuts. very tight. 13 mil (that's to the vias as well, which i realise is slightly dodgy). > I'm guessing you meant the closest vias to the differential pair > traces are 0.2mm = 7.87mil? yyep. > Are these the ground-to-ground vias for low-impedance connection > of reference planes? (Low-impedance return path close to signal vias?) honestly i haven't been thinking in terms so specific: i just add them arbitrarily because i heard it was the right thing to do! learning fast... l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 372556 bytes Desc: not available URL: From lkcl at lkcl.net Sat Aug 19 04:13:30 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 04:13:30 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: On Fri, Aug 18, 2017 at 5:51 PM, Richard Wilbur wrote: > You bring up an interesting point: what other current return paths are in the same vicinity? I have not analyzed that in any detail. At least there are no other lines from signal source to signal sink that I know of that cross the region of the board where the high-frequency HDMI signals are routed. Also, to my knowledge we don't have segmented or restricted ground planes that would isolate regions with a higher-impedance reference. CEC etc. all follow roughly the same path, on layer 3 (separated by GND). i just noticed that SD0 runs round the back of the HDMI 1st set of VIAS (with no GND separation) on layer 3 - i've removed the SATA power (not being used) so i can shift them up a bit some GPIOs cross on layer 3 as well, just near the GND shielding near those first vias... not much. l. From lkcl at lkcl.net Sat Aug 19 10:51:01 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 10:51:01 +0100 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system Message-ID: some background: http://forums.reprap.org/read.php?177,767087,784083#msg-784083 and the same question here: https://physics.stackexchange.com/questions/352661/ can anyone help? basically - and i really should have done this before going ahead... *sigh*... - when you have a pulley system is the amount of force on the belt less, equal, or greater, under the same *print-head* acceleration conditions, compared to a *non* pulley system? l. From lasich at gmail.com Sat Aug 19 11:38:55 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Sat, 19 Aug 2017 12:38:55 +0200 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: Ok, so correct me if I am wrong but you are asking some mechanical questions. so, I speak in general now and if you have question ask deeper. Force needed to drive whatever you want to drive will be exactly the same at the end part of system. But efficiency of belt system could be slightly different then efficiency of `non` pulley system (whatever it is). But again, efficiency could be neglected for sake of easy of calculation or you can put around some value that (guess) could be 80-90%. What you will be looking is gear ratio on pulley that could alter force/speed ratio and same thing on other system. also, you will be looking on backlash. On 19 August 2017 at 11:51, Luke Kenneth Casson Leighton wrote: > some background: > http://forums.reprap.org/read.php?177,767087,784083#msg-784083 > > and the same question here: > https://physics.stackexchange.com/questions/352661/ > > can anyone help? basically - and i really should have done this > before going ahead... *sigh*... - when you have a pulley system is the > amount of force on the belt less, equal, or greater, under the same > *print-head* acceleration conditions, compared to a *non* pulley > system? > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk -- Hrvoje Lasić Vulpes d.o.o. Gračanska 120a 10000 Zagreb Croatia tel +385 1 6152 706 tel +38598 450 603 *lasich at gmail.com hrvoje at vebbu.co m* *www.vebbu.co m* From lkcl at lkcl.net Sat Aug 19 11:52:42 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 11:52:42 +0100 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Aug 19, 2017 at 11:38 AM, Hrvoje Lasic wrote: > Ok, so correct me if I am wrong but you are asking some mechanical > questions. mechanical / physics, yes. > so, I speak in general now and if you have question ask deeper. > > Force needed to drive whatever you want to drive will be exactly the same > at the end part of system. on the print-head yes. but because of the doubled speed, the DRIVE end *NO*, the force is NOT the same. > But efficiency of belt system could be slightly > different then efficiency of `non` pulley system (whatever it is). But > again, efficiency could be neglected for sake of easy of calculation or you > can put around some value that (guess) could be 80-90%. i'm assuming that there are no significant losses around pulley bearings. > What you will be looking is gear ratio on pulley that could alter > force/speed ratio and same thing on other system. the gear ratio on a single pulley system is 2:1. > also, you will be looking on backlash. *thinks*... backlash should be reduced (halved) due to the better effectiveness of the pulleys - assuming that there is no "play" in the bearings (we can assume decent bearings / idlers). l. From lasich at gmail.com Sat Aug 19 15:00:30 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Sat, 19 Aug 2017 16:00:30 +0200 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: below are answers On 19 August 2017 at 12:52, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Sat, Aug 19, 2017 at 11:38 AM, Hrvoje Lasic wrote: > > Ok, so correct me if I am wrong but you are asking some mechanical > > questions. > > mechanical / physics, yes. > > > so, I speak in general now and if you have question ask deeper. > > > > Force needed to drive whatever you want to drive will be exactly the same > > at the end part of system. > > on the print-head yes. but because of the doubled speed, the DRIVE > end *NO*, the force is NOT the same. > so, if on the print head-side force is the same then it is on the drive side same as well (work can not be missing somewhere). However, if you are doubling the speeds, then overall work required will be some higher value so, correct would be to say that because of double speed you are having more force on print head needed and as result drive will also have to work more, losses will be bigger etc. anyway, that is all theoretical. Real value would be to find out force you need to have on print head then do some sort of calculation back to the drive. I guess you don't know that but maybe you can see what has been done on system that have other drive and then try to extrapolate what you will need. We can also assume here that someone has already put some reserve on what is now there, so possibly you can leave same motor or if you have problem increase force at disposal assuming you can do that on same motor size (nema 17 or so) I think backlash here will be your biggest problem here. Backlash is in fact inertia of the system. So, for example when you run you want to stop you cant do it right away, you need some time/distance. Or comparing to electrical engineering you can compare it to inductance. Inductance is resistance plus reactance. You said that you expect lesser backlash on pulley system. If that is the case (I am not sure why or why not this statement would be truth) you will be able to increase speed up to certain point but you will have to test where is that point. Basically you will have to do a lot of testing. > > > But efficiency of belt system could be slightly > > different then efficiency of `non` pulley system (whatever it is). But > > again, efficiency could be neglected for sake of easy of calculation or > you > > can put around some value that (guess) could be 80-90%. > > i'm assuming that there are no significant losses around pulley bearings. > > > What you will be looking is gear ratio on pulley that could alter > > force/speed ratio and same thing on other system. > > the gear ratio on a single pulley system is 2:1. > > > also, you will be looking on backlash. > > *thinks*... backlash should be reduced (halved) due to the better > effectiveness of the pulleys - assuming that there is no "play" in the > bearings (we can assume decent bearings / idlers). > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk > -- Hrvoje Lasić Vulpes d.o.o. Gračanska 120a 10000 Zagreb Croatia tel +385 1 6152 706 <+385%201%206152%20706> tel +38598 450 603 <+385%2098%20450%20603> *lasich at gmail.com hrvoje at vebbu.co m* *www.vebbu.co m* From richard.wilbur at gmail.com Sat Aug 19 15:07:11 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sat, 19 Aug 2017 07:07:11 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> Message-ID: <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> On Aug 18, 2017, at 19:54, Luke Kenneth Casson Leighton wrote: > > On Thu, Aug 17, 2017 at 5:20 PM, Richard Wilbur > wrote: […] > So you have a flood-fill on the bottom layer? > > all layers. > >> Is the flood-fill connected to GND? > > only when it's properly arranged to be so... i.e. when you don't you > get a warning... short answer: yes. > >> Can you set the 15mil copper-to-trace separation as a property of the differential traces? > > yyup. i really like PADS for this reason > >> The goal with this 15mil clearance is to space other copper >> in the same plane far enough away to have a negligible effect >> on the differential impedance of the differential pair and by the >> same token negligible high-frequency signal coupling. > > okaaay. i get it. > >> The microstrip differential pair geometry is based on having ground >> plane (may it extend forever ;>) > > :) > >> underneath the traces separated by a dielectric of thickness t. >> (We took that into account in the impedance calculations. > > yehyeh. > >> Actually power and ground are identical from the perspective of >> high-frequency signals so we could have built our microstrip >> differential pair over a power plane--or even moved from one >> reference plane to another. > > ohhh that explains why DDR3 has a big power-plane @ the 1/2 way > "reference" voltage. nice. > >>> there's one place where the diffpairs go past the main power line >>> (IPSOUT) - that's got a 5 mil copper GND separating it at present: i'd >>> be nervous about taking that out. >> >> I wouldn't worry because that 5mil copper GND has >> 5mil spacing on each side, thus ensuring 15mil between the closest >> differential trace and power. That should be sufficient. > > ... need to check it. > >> On the other hand, if I remember correctly the proximity to IPSOUT >> happened because we decided to do significant inter-pair skew >> compensation close to the power circuit. > > ah no: it's always been very close: in this revision i particularly > wanted the vias left of the rclamp0524p to be reasonably symmetrical > and clean, with a straight (diff-paired) path to the rclamp0524p > instead of taking a turn to get to it (as in previous revisions). > > that required a little bit more space, which meant moving IPSOUT's > vias a little bit further over. i could _probably_ move them over a > bit further... > > >> The other thing that we can do if we have a little extra space >> after taking out the intermediary GND shield traces and inter-pair >> skew compensation wiggles is distribute the intra-pair skew >> compensation closer to the sources of intra-pair skew--corners. > > aw poop - changing those is quite a task. there's some bugs due to a > combination of grid snap and push-and-shove in PADS where removing the > long straights means i can't add them back in again. and i need to > remove them because otherwise i don't know how long the traces are > from the vias. what i do is: > > * remove the long sections > * re-add a *short* diffpair section of only about 1mm > * those end up being equal length > * then because the traces aren't complete PADS will tell you exactly > how long they are > * therefore i can now measure them both and... > * therefore i know exactly how much manual "wiggle" to put in the shorter one. > > once the wiggles are done i can re-add the long sections, confident > that the signals will be matched. > > but it's a pain to do! :) > >> Right now you've done a great job of compensating for intra-pair >> skew in the first segment: from CPU lands to first via. > > yehyeh. they're near-identical. > >> Then there are some very significant wiggles when we first get >> to the bottom layer > > yes. intra-pair correction due to wanting to have the 1st layer > traces all the same length. it's nearly... 1.5mm to correct, due to > not just the offset of the vias but also the turn. if i tried to > stagger those first vias the other way (which i tried once) then > there's not enough room to have those 1st trace segments be equal > length... > >> and I don't see any other intra-pair skew >> compensation all the way out to the connector. > > that's because they're all fine... ok i read somewhere that it's ok > to have some intra-pair skew on short lengths between turns. sooOo... > i'm assuming that the critical part is the long straight. sooOOo i > arranged for the wiggles to make perfect length-matching just as each > pair hits the beginning of each long straight. > > now (and i've removed the inter-pair skew in the current revision) > what i *haven't* done is add in any inter-skew correction at the > points marked in green (attached). i'm assuming that those diagonal > cross-paths (between each green ring) are... within acceptable > tolerance for intra-skew. > >> If we can do it, the most effective place for intra-pair skew compensation >> is within 15mil of the skew source--right before or after a bend. >> If skew originates in a bend and is resolved by a complementary bend within 15mils, >> then we don't need to add anything specific. > > mmmm *grumble, grumble*.... i think there might be space to add them, > around where the green rings are, by moving the diagonal pieces to the > right a bit. > >>>> How far are the differential traces from board edge at present? >>> >>> 0.9mm -> 35 mil. >>> >>> to the nearest vias is 0.2mm -> 0.787mil >> >> How far is the board-edge ground shield trace >> from the edge of the board? > > to the edge of the GND shield trace: 0.46mm -> 18 mil > >> From the closest differential pair trace? > > to the edge of the CK diffpair, 0.93mm -> 36.6 mil > >> How wide is the board-edge ground shield trace? > > pffh :) peanuts. very tight. 13 mil (that's to the vias as well, > which i realise is slightly dodgy). > > >> I'm guessing you meant the closest vias to the differential pair >> traces are 0.2mm = 7.87mil? > > yyep. > >> Are these the ground-to-ground vias for low-impedance connection >> of reference planes? (Low-impedance return path close to signal vias?) > > honestly i haven't been thinking in terms so specific: i just add > them arbitrarily because i heard it was the right thing to do! > learning fast... > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Sat Aug 19 15:12:44 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 15:12:44 +0100 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Aug 19, 2017 at 3:00 PM, Hrvoje Lasic wrote: > below are answers > > On 19 August 2017 at 12:52, Luke Kenneth Casson Leighton > wrote: > >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> >> >> On Sat, Aug 19, 2017 at 11:38 AM, Hrvoje Lasic wrote: >> > Ok, so correct me if I am wrong but you are asking some mechanical >> > questions. >> >> mechanical / physics, yes. >> >> > so, I speak in general now and if you have question ask deeper. >> > >> > Force needed to drive whatever you want to drive will be exactly the same >> > at the end part of system. >> >> on the print-head yes. but because of the doubled speed, the DRIVE >> end *NO*, the force is NOT the same. >> > > so, if on the print head-side force is the same then it is on the drive > side same as well (work can not be missing somewhere). However, if you are > doubling the speeds, then overall work required will be some higher value doubling the speed of the *belt* but not the print-head. we're comparing like-for-like scenario (pulleys / no-pulleys). btw benson kindly answered on the forum (thank you!) and i think i have a handle on the situation now. > so, correct would be to say that because of double speed you are having > more force on print head needed and as result drive will also have to work > more, losses will be bigger etc. no, the speed of the print-head should be the same in both scenarios (pulleys / no-pulleys) therefore the force should be the same. now, what benson kindly pointed out is that in a pulley system the force is *SHARED* between the two belt segments, therefore the amount of "stretch" (which is what i was concerned about) should also be HALVED compared to a non-pulley system. where i got confused was, i thought that the belt's actual travel speed was somehow involved in the equation: it would be.... *if* the belt's mass was significant. > I think backlash here will be your biggest problem here. Backlash is in > fact inertia of the system. So, for example when you run you want to stop > you cant do it right away, you need some time/distance. Or comparing to > electrical engineering you can compare it to inductance. Inductance is > resistance plus reactance. indeed. so, because the force is halved (for the same speed compared to a non-pulley system) we *should* also get less backlash as well. yay. > You said that you expect lesser backlash on pulley system. If that is the > case (I am not sure why or why not this statement would be truth) you will > be able to increase speed up to certain point but you will have to test > where is that point. Basically you will have to do a lot of testing. indeed :) the aim is to use the extra wiggle-room (less backlash, less load) to increase speed by some factor... probably not double but a good fraction of that, and see what happens. certainly someone pointed out that the speed of the NEMA17s, when you go faster, you actually get less torque. whoops. and the rated maximum seems to be around 1800 mm / sec. at that point you get *significantly* less torque. so it's not going to be a straightforward "go twice as fast" thing. l. From lkcl at lkcl.net Sat Aug 19 15:30:24 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 15:30:24 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> Message-ID: whoops looks like you hit reply early, richard! :) On Sat, Aug 19, 2017 at 3:07 PM, Richard Wilbur wrote: >> From lasich at gmail.com Sat Aug 19 15:34:39 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Sat, 19 Aug 2017 16:34:39 +0200 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: > > certainly someone pointed out that the speed of the NEMA17s, when you > go faster, you actually get less torque. whoops. and the rated > maximum seems to be around 1800 mm / sec. at that point you get > *significantly* less torque. > > so, when you say nema 17 you refer to dimensions of the motor, not torque. it is some American standard,so nema 17 refer to 43.2 mmx 43.2 mm if you look at face of motor. But you can have different torques at same size of the motor. They increase the size of the motor in length. so you will be still able to alter torque to some extent no matter speed. Keep in mind that you are flexible here up to certain point. After that, if you need more torque you go to next bigger size of motor nema 23 or so. > so it's not going to be a straightforward "go twice as fast" thing. > for sure not otherwise you would see some speeds as standard. My guess is that what you have on market is pretty much optimized per cost/performance but you may well be more efficient for your particular case. > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk > -- Hrvoje Lasić Vulpes d.o.o. Gračanska 120a 10000 Zagreb Croatia tel +385 1 6152 706 tel +38598 450 603 *lasich at gmail.com hrvoje at vebbu.co m* *www.vebbu.co m* From lkcl at lkcl.net Sat Aug 19 15:47:26 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 19 Aug 2017 15:47:26 +0100 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: On Sat, Aug 19, 2017 at 3:34 PM, Hrvoje Lasic wrote: > so, when you say nema 17 you refer to dimensions of the motor, not torque. yes. they're common enough that they're quite low-priced. > look at face of motor. But you can have different torques at same size of > the motor. yes. for the purposes of the analysis (pulley / non-pulley) we assume exact same motor. > They increase the size of the motor in length. so you will be > still able to alter torque to some extent no matter speed. Keep in mind > that you are flexible here up to certain point. After that, if you need > more torque you go to next bigger size of motor nema 23 or so. yes. that also increases cost, and weight, not just the motor size but also the holders, and also the ampage needed of the controller. which again increases cost. so, trying not to do that as it's not necessary. l. From richard.wilbur at gmail.com Sun Aug 20 14:58:21 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 20 Aug 2017 06:58:21 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> Message-ID: <50DB29D5-5C96-4898-AA73-D312E1CC2D98@gmail.com> On Aug 19, 2017, at 07:30, Luke Kenneth Casson Leighton wrote: > > whoops looks like you hit reply early, richard! :) Yes! My apologies to everyone on the list. I am working on a more substantive reply but didn't get it finished or sent yesterday before I did several hours of driving (southeast from Seattle, Washington into northern Oregon). Today several more hours of driving to reach an area where we can observe the total solar eclipse tomorrow morning. (I'm on vacation with my family.) From lkcl at lkcl.net Sun Aug 20 15:37:38 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 20 Aug 2017 15:37:38 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <50DB29D5-5C96-4898-AA73-D312E1CC2D98@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> <50DB29D5-5C96-4898-AA73-D312E1CC2D98@gmail.com> Message-ID: On Sun, Aug 20, 2017 at 2:58 PM, Richard Wilbur wrote: >> whoops looks like you hit reply early, richard! :) > > Today several more hours of driving to reach an area where we can > observe the total solar eclipse tomorrow morning. > (I'm on vacation with my family.) nice! yeh the lunar eclipse was... eclipsed by clouds here in taipei. l. From richard.wilbur at gmail.com Sun Aug 20 16:47:59 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 20 Aug 2017 08:47:59 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <9A45BECE-2988-4A4D-B726-352EE401EE20@gmail.com> <50DB29D5-5C96-4898-AA73-D312E1CC2D98@gmail.com> Message-ID: <302AD54C-5A0B-4073-B420-42F82AD0525E@gmail.com> On Aug 20, 2017, at 07:37, Luke Kenneth Casson Leighton wrote: > nice! yeh the lunar eclipse was... eclipsed by clouds here in taipei. Sorry to hear that. My family saw a lunar eclipse several years ago and it was quiet and beautiful. It happened in the wee hours of the morning so my wife and I got the kids up, bundled them into the car and drove half a mile to a field where we had a great view. So I recommend it--if you can get the weather to cooperate! ;>) From gpast_panama at protonmail.com Tue Aug 22 08:16:46 2017 From: gpast_panama at protonmail.com (Gpast_panama) Date: Tue, 22 Aug 2017 03:16:46 -0400 Subject: [Arm-netbook] Flash Debian and U-Boot to a PocketChip? Message-ID: Perhaps this is better suited to a reply than a new topic, but I'm not aware of how to do that with messages in digest mode so... Back in July, Pablo claimed at http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-July/014340.html that he had successfully managed to get Debian Stretch running from USB on the PocketChip. Could somebody explain to a novice (i.e. me) what the steps entailed to flash u-boot and then boot Stretch are? A description of how to flash the OS to NAND would be amazing, but even just a brief outline of Pablo's process would be great. Thanks (and sorry for my ignorance)! Regards, Grace Past From richard.wilbur at gmail.com Tue Aug 22 14:43:15 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 22 Aug 2017 06:43:15 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> Message-ID: <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> On Aug 18, 2017, at 19:54, Luke Kenneth Casson Leighton wrote: > > On Thu, Aug 17, 2017 at 5:20 PM, Richard Wilbur > wrote: >> >> So you have a flood-fill on the bottom layer? > > all layers. > >> Is the flood-fill connected to GND? > > only when it's properly arranged to be so... i.e. when you don't you > get a warning... short answer: yes. So it sounds to me like some of the ground vias can connect more than just layers 2 and 5 if they happen to coincide with ground flood-fill on one or more other layers? >> Can you set the 15mil copper-to-trace separation as a property of the differential traces? > > yyup. i really like PADS for this reason Nice. […] >>> there's one place where the diffpairs go past the main power line >>> (IPSOUT) - that's got a 5 mil copper GND separating it at present: i'd >>> be nervous about taking that out. >> >> I wouldn't worry because that 5mil copper GND has >> 5mil spacing on each side, thus ensuring 15mil between the closest >> differential trace and power. That should be sufficient. > > ... need to check it. Those were my understanding of the limits of your board fabricator: min{spacing} = 5mil min{trace width} = 5mil > it's always been very close: in this revision i particularly > wanted the vias left of the rclamp0524p to be reasonably symmetrical > and clean, with a straight (diff-paired) path to the rclamp0524p > instead of taking a turn to get to it (as in previous revisions). > > that required a little bit more space, which meant moving IPSOUT's > vias a little bit further over. i could _probably_ move them over a > bit further... Sounds fine. > >> The other thing that we can do if we have a little extra space >> after taking out the intermediary GND shield traces and inter-pair >> skew compensation wiggles is distribute the intra-pair skew >> compensation closer to the sources of intra-pair skew--corners. > > aw poop - changing those is quite a task. there's some bugs due to a > combination of grid snap and push-and-shove in PADS where removing the > long straights means i can't add them back in again. and i need to > remove them because otherwise i don't know how long the traces are > from the vias. what i do is: > > * remove the long sections > * re-add a *short* diffpair section of only about 1mm > * those end up being equal length > * then because the traces aren't complete PADS will tell you exactly > how long they are > * therefore i can now measure them both and... > * therefore i know exactly how much manual "wiggle" to put in the shorter one. > > once the wiggles are done i can re-add the long sections, confident > that the signals will be matched. > > but it's a pain to do! :) I'm glad you have a method that works. I'm sorry it is such a pain. Too bad it isn't more straightforward. Is PADS libre software? I ask because here's an itch. >> Right now you've done a great job of compensating for intra-pair >> skew in the first segment: from CPU lands to first via. > > yehyeh. they're near-identical. > >> Then there are some very significant wiggles when we first get >> to the bottom layer > > yes. intra-pair correction due to wanting to have the 1st layer > traces all the same length. it's nearly... 1.5mm to correct, due to > not just the offset of the vias but also the turn. if i tried to > stagger those first vias the other way (which i tried once) then > there's not enough room to have those 1st trace segments be equal > length... > >> and I don't see any other intra-pair skew >> compensation all the way out to the connector. > > that's because they're all fine... ok i read somewhere that it's ok > to have some intra-pair skew on short lengths between turns. sooOo... > i'm assuming that the critical part is the long straight. sooOOo i > arranged for the wiggles to make perfect length-matching just as each > pair hits the beginning of each long straight. > > now (and i've removed the inter-pair skew in the current revision) > what i *haven't* done is add in any inter-skew correction at the > points marked in green (attached). i'm assuming that those diagonal > cross-paths (between each green ring) are... within acceptable > tolerance for intra-skew. > >> If we can do it, the most effective place for intra-pair skew compensation >> is within 15mil of the skew source--right before or after a bend. >> If skew originates in a bend and is resolved by a complementary bend within 15mils, >> then we don't need to add anything specific. > > mmmm *grumble, grumble*.... i think there might be space to add them, > around where the green rings are, by moving the diagonal pieces to the > right a bit. Sounds like a good plan. How much intra-pair skew do we incur at each of those bends? >>>> How far are the differential traces from board edge at present? >>> >>> 0.9mm -> 35 mil. >>> >>> to the nearest vias is 0.2mm -> 0.787mil >> >> How far is the board-edge ground shield trace >> from the edge of the board? > > to the edge of the GND shield trace: 0.46mm -> 18 mil > >> From the closest differential pair trace? > > to the edge of the CK diffpair, 0.93mm -> 36.6 mil > >> How wide is the board-edge ground shield trace? > > pffh :) peanuts. very tight. 13 mil (that's to the vias as well, > which i realise is slightly dodgy). We'll take what we can fit. >> I'm guessing you meant the closest vias to the differential pair >> traces are 0.2mm = 7.87mil? > > yyep. In order for me to understand better the dimensions you're quoting allow me to resort to a diagram. edge of the world/board |<- spacing to first Cu ->| v |<-width of ground shield trace ->|<-spacing to diff. pair->|CLK- FR-4 substrateFR-4 substrateFR-4 substrateFR-4 substrateFR-4 substrate >> Are these the ground-to-ground vias for low-impedance connection >> of reference planes? (Low-impedance return path close to signal vias?) > > honestly i haven't been thinking in terms so specific: i just add > them arbitrarily because i heard it was the right thing to do! > learning fast... It is good to have a scattering of vias connecting related planes (in this case ground). With limited space it becomes more important to use what heuristic we can muster to place them strategically. (Writing from our tent here in John Day, Oregon. The total solar eclipse yesterday morning was spectacular. I'm glad we travelled to be in the path of totality. I've seen partial solar eclipses before but this was well worth the trip. We're going to visit the John Day Fossil Beds today before we head home tomorrow.) From richard.wilbur at gmail.com Tue Aug 22 16:30:21 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 22 Aug 2017 08:30:21 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: On Aug 18, 2017, at 20:13, Luke Kenneth Casson Leighton wrote: > > On Fri, Aug 18, 2017 at 5:51 PM, Richard Wilbur > wrote: > >> You bring up an interesting point: what other current return paths are in the same vicinity? I have not analyzed that in any detail. At least there are no other lines from signal source to signal sink that I know of that cross the region of the board where the high-frequency HDMI signals are routed. Also, to my knowledge we don't have segmented or restricted ground planes that would isolate regions with a higher-impedance reference. > > CEC etc. all follow roughly the same path, on layer 3 (separated by GND). > > i just noticed that SD0 runs round the back of the HDMI 1st set of > VIAS (with no GND separation) on layer 3 - i've removed the SATA power > (not being used) so i can shift them up a bit > > some GPIOs cross on layer 3 as well, just near the GND shielding near > those first vias... > > not much. Layer 3 always has ground separation from layer 1 in the intervening ground plane on layer 2 and likewise from layer 6 by layers 4 and 5. So I'm not worried about those signals. Regarding the SATA power: Is it an important part of providing a SATA interface? If so, I would suggest not limiting our options on this card. My understanding is that SATA is significantly more efficient for harddisk data interface than USB. Regarding SD0: To what interface does it belong? What is the maximum data rate on this line? From lkcl at lkcl.net Tue Aug 22 15:13:48 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 22 Aug 2017 15:13:48 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Aug 22, 2017 at 2:43 PM, Richard Wilbur wrote: > On Aug 18, 2017, at 19:54, Luke Kenneth Casson Leighton wrote: >> >> On Thu, Aug 17, 2017 at 5:20 PM, Richard Wilbur >> wrote: >>> >>> So you have a flood-fill on the bottom layer? >> >> all layers. >> >>> Is the flood-fill connected to GND? >> >> only when it's properly arranged to be so... i.e. when you don't you >> get a warning... short answer: yes. > > So it sounds to me like some of the ground vias can connect more than just layers 2 and 5 if they happen to coincide with ground flood-fill on one or more other layers? yehyeh, they go all the way through and connect to all layers 1 through 6 if there's flood-fill or a GND trace on any of them. > Those were my understanding of the limits of your board fabricator: > min{spacing} = 5mil > min{trace width} = 5mil yeah it's more what i set so things don't get ridiculously expensive... but yes. >> it's always been very close: in this revision i particularly >> wanted the vias left of the rclamp0524p to be reasonably symmetrical >> and clean, with a straight (diff-paired) path to the rclamp0524p >> instead of taking a turn to get to it (as in previous revisions). >> >> that required a little bit more space, which meant moving IPSOUT's >> vias a little bit further over. i could _probably_ move them over a >> bit further... > > Sounds fine. > >> >>> The other thing that we can do if we have a little extra space >>> after taking out the intermediary GND shield traces and inter-pair >>> skew compensation wiggles is distribute the intra-pair skew >>> compensation closer to the sources of intra-pair skew--corners. >> >> aw poop - changing those is quite a task. there's some bugs due to a >> combination of grid snap and push-and-shove in PADS where removing the >> long straights means i can't add them back in again. and i need to >> remove them because otherwise i don't know how long the traces are >> from the vias. what i do is: >> >> * remove the long sections >> * re-add a *short* diffpair section of only about 1mm >> * those end up being equal length >> * then because the traces aren't complete PADS will tell you exactly >> how long they are >> * therefore i can now measure them both and... >> * therefore i know exactly how much manual "wiggle" to put in the shorter one. >> >> once the wiggles are done i can re-add the long sections, confident >> that the signals will be matched. >> >> but it's a pain to do! :) > > I'm glad you have a method that works. I'm sorry it is such a pain. Too bad it isn't more straightforward. Is PADS libre software? I ask because here's an itch. > >>> Right now you've done a great job of compensating for intra-pair >>> skew in the first segment: from CPU lands to first via. >> >> yehyeh. they're near-identical. >> >>> Then there are some very significant wiggles when we first get >>> to the bottom layer >> >> yes. intra-pair correction due to wanting to have the 1st layer >> traces all the same length. it's nearly... 1.5mm to correct, due to >> not just the offset of the vias but also the turn. if i tried to >> stagger those first vias the other way (which i tried once) then >> there's not enough room to have those 1st trace segments be equal >> length... >> >>> and I don't see any other intra-pair skew >>> compensation all the way out to the connector. >> >> that's because they're all fine... ok i read somewhere that it's ok >> to have some intra-pair skew on short lengths between turns. sooOo... >> i'm assuming that the critical part is the long straight. sooOOo i >> arranged for the wiggles to make perfect length-matching just as each >> pair hits the beginning of each long straight. >> >> now (and i've removed the inter-pair skew in the current revision) >> what i *haven't* done is add in any inter-skew correction at the >> points marked in green (attached). i'm assuming that those diagonal >> cross-paths (between each green ring) are... within acceptable >> tolerance for intra-skew. >> >>> If we can do it, the most effective place for intra-pair skew compensation >>> is within 15mil of the skew source--right before or after a bend. >>> If skew originates in a bend and is resolved by a complementary bend within 15mils, >>> then we don't need to add anything specific. >> >> mmmm *grumble, grumble*.... i think there might be space to add them, >> around where the green rings are, by moving the diagonal pieces to the >> right a bit. > > Sounds like a good plan. How much intra-pair skew do we incur at each of those bends? very little. it's a 45 degree bend in each case so.... can probably work out the maths... 15mil separation... >>>>> How far are the differential traces from board edge at present? >>>> >>>> 0.9mm -> 35 mil. >>>> >>>> to the nearest vias is 0.2mm -> 0.787mil >>> >>> How far is the board-edge ground shield trace >>> from the edge of the board? >> >> to the edge of the GND shield trace: 0.46mm -> 18 mil >> >>> From the closest differential pair trace? >> >> to the edge of the CK diffpair, 0.93mm -> 36.6 mil >> >>> How wide is the board-edge ground shield trace? >> >> pffh :) peanuts. very tight. 13 mil (that's to the vias as well, >> which i realise is slightly dodgy). > > We'll take what we can fit. > >>> I'm guessing you meant the closest vias to the differential pair >>> traces are 0.2mm = 7.87mil? >> >> yyep. > > In order for me to understand better the dimensions you're quoting allow me to resort to a diagram. > > edge of the world/board > |<- spacing to first Cu ->| > v |<-width of ground shield trace ->|<-spacing to diff. pair->|CLK- > FR-4 substrateFR-4 substrateFR-4 substrateFR-4 substrateFR-4 substrate urk. attached diagram is probably a lot easier. i also checked the Design Rules: board-to-everything-and-anything is set to 11.84 mil, everything-else-to-anything-else is set to 5mil. so in the attached diagram those traces i put right at the bottom will be overwritten by about... 1.2 mil to make up to the 11.84 board-to-copper clearance. so, actually very simple. everything-to-everything-but-board: 5mil. board-to-everything: 11.84mil. > (Writing from our tent here in John Day, Oregon. The total solar eclipse yesterday morning was spectacular. I'm glad we travelled to be in the path of totality. I've seen partial solar eclipses before but this was well worth the trip. We're going to visit the John Day Fossil Beds today before we head home tomorrow.) niice :) -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 151606 bytes Desc: not available URL: From lkcl at lkcl.net Tue Aug 22 18:09:22 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 22 Aug 2017 18:09:22 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: On Tue, Aug 22, 2017 at 4:30 PM, Richard Wilbur wrote: > Layer 3 always has ground separation from layer 1 in the intervening ground plane on layer 2 and likewise from layer 6 by layers 4 and 5. So I'm not worried about those signals. ok great. > Regarding the SATA power: Is it an important part of providing a SATA interface? If so, I would suggest not limiting our options on this card. My understanding is that SATA is significantly more efficient for harddisk data interface than USB. SATA was on a very preliminary version of EOMA68. it was cut a long time ago. > Regarding SD0: To what interface does it belong? What is the maximum data rate on this line? MicroSD card reading (and other SD/MMC / SDIO compatible interfaces). i *think* it's a max datarate of 50mhz.... l. From lkcl at lkcl.net Tue Aug 22 19:25:43 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 22 Aug 2017 19:25:43 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i can shorten even more, there's definitely plenty of space there, big gap. 2nd image, right end, this is where i've added intra-pair wiggles at the 45 degree bends. i can't get away with a proper 4-turn using 45 degrees, PADS goes "nope that's too short a trace, i'm gonna assume you want a straight line instead" - there's probably an option somewhere for that but i've not found it. alternatively i can add in a (curvy) accordion.... anyway those wiggles are done by hand, some of them aren't pretty but in mil those traces are now nearly all to within 0.01 mil. i cheat a little and have made some of the corners in places a very very tiny arc, where you get better fine-grain control over the amount it takes off. HTXCN just before the diff-pair vias at the end i'm a little concerned about, it looks a bit too... sharp-angled to make me feel totally comfortable... not a lot of space... i tried a single wiggle and it went too far away from HTXCP for me to feel happy about it.... put in two much smaller wiggles instead... GND i'll remove as the absolute last thing. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled2.jpg Type: image/jpeg Size: 206022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 90434 bytes Desc: not available URL: From richard.wilbur at gmail.com Tue Aug 22 21:06:46 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 22 Aug 2017 13:06:46 -0700 Subject: [Arm-netbook] m Message-ID: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> Sent from my iPhone From lkcl at lkcl.net Wed Aug 23 12:27:57 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 23 Aug 2017 12:27:57 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: damn. i just noticed: the via transition here is at 90 degrees. i've been switching off except 1 layer at a time so didn't notice. arse. i'll need to shift all but the TX2 via set down a fixed amount so i can get a second wiggle in the right-hand one one layer 1, to make the track come in to the top right corner (1 o clock). rather than as they do now: from right side (3 o clock). TX2 i'll have to move to the right somewhat... -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 60391 bytes Desc: not available URL: From richard.wilbur at gmail.com Wed Aug 23 20:04:31 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 23 Aug 2017 13:04:31 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: <8165DA8A-25A4-4EC5-A53B-03D6DB765F33@gmail.com> On Aug 22, 2017, at 10:09, Luke Kenneth Casson Leighton wrote: > SATA was on a very preliminary version of EOMA68. it was cut a long time ago. Sorry for bringing up old news. > On Tue, Aug 22, 2017 at 4:30 PM, Richard Wilbur wrote: >> Regarding SD0: To what interface does it belong? What is the maximum data rate on this line? > > MicroSD card reading (and other SD/MMC / SDIO compatible interfaces). > i *think* it's a max datarate of 50mhz.... Sounds like SD0 is high-frequency single-ended so it might warrant a ground shield trace--if there's room. But I would rather maintain the 15mil differential pair trace to any other trace spacing because I'm guessing the coupling to differential pairs will be small. (It is not parallel to differential signals for a significant distance, is it?) From lkcl at lkcl.net Wed Aug 23 20:09:59 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 23 Aug 2017 20:09:59 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <8165DA8A-25A4-4EC5-A53B-03D6DB765F33@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8165DA8A-25A4-4EC5-A53B-03D6DB765F33@gmail.com> Message-ID: On Wed, Aug 23, 2017 at 8:04 PM, Richard Wilbur wrote: > On Aug 22, 2017, at 10:09, Luke Kenneth Casson Leighton wrote: >> SATA was on a very preliminary version of EOMA68. it was cut a long time ago. > > Sorry for bringing up old news. ey no problem it's all interesting stuff >> MicroSD card reading (and other SD/MMC / SDIO compatible interfaces). >> i *think* it's a max datarate of 50mhz.... > > Sounds like SD0 is high-frequency single-ended > so it might warrant a ground shield trace--if there's room. there is... just! > But I would rather maintain the 15mil differential pair trace to any > other trace spacing because I'm guessing the coupling to > differential pairs will be small. (It is not parallel to differential > signals for a significant distance, is it?) nono - they run round the back of the vias (attached) - yellow, 6 lines. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 66382 bytes Desc: not available URL: From kyle at free2.ml Wed Aug 23 21:52:05 2017 From: kyle at free2.ml (Kyle) Date: Wed, 23 Aug 2017 16:52:05 -0400 Subject: [Arm-netbook] m In-Reply-To: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> Message-ID: Sent from my kerosene powered cheese grater running Arch Linux From laserhawk64 at gmail.com Wed Aug 23 21:55:23 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Wed, 23 Aug 2017 16:55:23 -0400 Subject: [Arm-netbook] m In-Reply-To: References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> Message-ID: LOL. I think Mr Wilbur just had a mild keylock failure. I would've remarked such at the time, but I didn't think it was even worth that much attention. From pablo at parobalth.org Wed Aug 23 22:05:17 2017 From: pablo at parobalth.org (Pablo Rath) Date: Wed, 23 Aug 2017 23:05:17 +0200 Subject: [Arm-netbook] Flash Debian and U-Boot to a PocketChip? In-Reply-To: References: Message-ID: <20170823210517.jxejhzbclot3obk4@cherry> Hello Grace, On Tue, Aug 22, 2017 at 03:16:46AM -0400, Gpast_panama via arm-netbook wrote: > Perhaps this is better suited to a reply than a new topic, but I'm not aware of how to do that with messages in digest mode so... This was the reason why I stopped using digest mode for this list. > Back in July, Pablo claimed at http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-July/014340.html that he had successfully managed to get Debian Stretch running from USB on the PocketChip. I installed Debian Stretch on my *Chip*. I don't own a PocketChip. > Could somebody explain to a novice (i.e. me) what the steps entailed to flash u-boot and then boot Stretch are? Necessary steps to install on Chip like I did are at least: 1. You will need some command line basics. 2. You will need a USB TTL Serial cable (USB to serial converter cables) providing a connection between USB and serial UART interface to interact with Debian Installer. 3. You will need sunxi-tools (http://linux-sunxi.org/Sunxi-tools) 4. Compile mainline U-Boot (build target is "CHIP_defconfig") 5. Download hd-media tarball and CD iso (see https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_from_a_USB_stick) The wiki still points to testing, but current stable (stretch) works. 6. Prepare the USB-stick like described and leave a large space free (without a partition) 7. put Chip into fel-mode and connect it with another computer. Use a "special" version of U-Boot via fel (http://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB) and boot Debian Installer on USB. 8. Install with Debian Installer 9. boot and see if this bug report is already fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866521 if not you have to manually update initramfs 10. Install firmware/driver for the proprietary wifi-chip if you need it. I don't know how to do it and can't recommend it (thread title is liberating PocketChip). Or use ethernet via usb-otg and connect through a host computer. This is what I did. > A description of how to flash the OS to NAND would be amazing, As far as I know flashing to NAND is not possible with vanilla Debian. I asked at linxu-sunxi IRC channel and the response was to stick with NextThings U-Boot and NextThings Kernel if you want onboard NAND. I installed on an external USB-stick. >but even just a brief outline of Pablo's process would be great. See above. I know it is a long list. The result is a device with a quite tedious boot process (see https://lists.debian.org/debian-arm/2017/06/msg00033.html). Hopefully the described steps are not to intimidating to a novice. You can work on it step by step. If you are still willing, I am willing to answer your questions and add details where necessary. I have promised to write a dedicated page on Debian Wiki but I only have a short draft (offline) and it will take some time to finish. I recommend you start with just the Chip (take it out of the PocketChip enclosure). Once you have Stretch up and running you can decide and research own your own if you can make it work with PocketChip (see my discussion with David in the July/August archives). kind regards Pablo From richard.wilbur at gmail.com Thu Aug 24 15:44:04 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 24 Aug 2017 08:44:04 -0600 Subject: [Arm-netbook] m In-Reply-To: References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> Message-ID: <428F7CC8-4481-471E-A95D-7B5921C40B20@gmail.com> > On Aug 23, 2017, at 14:55, Christopher Havel wrote: > > LOL. > > I think Mr Wilbur just had a mild keylock failure. I would've remarked such > at the time, but I didn't think it was even worth that much attention. Sorry for the noise. I had no idea I wrote or sent that. From laserhawk64 at gmail.com Thu Aug 24 15:46:40 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 24 Aug 2017 10:46:40 -0400 Subject: [Arm-netbook] m In-Reply-To: <428F7CC8-4481-471E-A95D-7B5921C40B20@gmail.com> References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> <428F7CC8-4481-471E-A95D-7B5921C40B20@gmail.com> Message-ID: Like I suggested, keylock failure. Make sure your phone has its lock feature activated when it's in your pocket and it shouldn't happen too often... ...unless your phone is like my father's, where the keylock feature is so poorly implemented that it calls people from his pocket, WITH keylock activated! From lkcl at lkcl.net Thu Aug 24 15:53:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 24 Aug 2017 15:53:49 +0100 Subject: [Arm-netbook] m In-Reply-To: References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> <428F7CC8-4481-471E-A95D-7B5921C40B20@gmail.com> Message-ID: On Thu, Aug 24, 2017 at 3:46 PM, Christopher Havel wrote: > ...unless your phone is like my father's, where the keylock feature is so > poorly implemented that it calls people from his pocket, WITH keylock > activated! that's hilarious... because then he couldn't unlock the phone to switch off the call :) From lkcl at lkcl.net Thu Aug 24 16:09:12 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 24 Aug 2017 16:09:12 +0100 Subject: [Arm-netbook] http://rhombus-tech.net/allwinner_a10/news/ Message-ID: ok so i did a quick summary (despite the length) of the status so far... i hope there is light at the end of the tunnel.... --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From laserhawk64 at gmail.com Fri Aug 25 15:26:02 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Fri, 25 Aug 2017 10:26:02 -0400 Subject: [Arm-netbook] m In-Reply-To: References: <73129C59-EA72-45B6-A1DF-82F02A23B048@gmail.com> <428F7CC8-4481-471E-A95D-7B5921C40B20@gmail.com> Message-ID: Wrong. The phone goes off of keylock in his pocket, causing it to be able to place the pocket calls... From calmstorm at posteo.de Sat Aug 26 18:40:16 2017 From: calmstorm at posteo.de (calmstorm at posteo.de) Date: Sat, 26 Aug 2017 13:40:16 -0400 Subject: [Arm-netbook] gnu/linux distro of interest? Message-ID: https://www.voidlinux.eu/ Luke I know you might have interest in this, because you are not fond of systemd correct? Sorry to bring that topic up again, But I think you may have interest in this gnu/linux distro for that reason. Also, it is free software if you don't load the non-free repository. The bad? If you do load the module it isn't free software. It does however use runit by default. Also, it is rolling release like parabola and it is an independent distro. pity there isn't a free software fork but still, I think you could rake in more money by making a card for it in the future. If you can figure out how to install it that is... ;P xD only kidding... you have way, way, way more experience with gnu/linux then me. From bernardlprf at openmailbox.org Sat Aug 26 18:58:37 2017 From: bernardlprf at openmailbox.org (mdn) Date: Sat, 26 Aug 2017 19:58:37 +0200 Subject: [Arm-netbook] gnu/linux distro of interest? In-Reply-To: References: Message-ID: <59A1B6CD.9070402@openmailbox.org> Sharing this if anyone is interested https://sourcemage.org/ Le 26/08/2017 19:40, calmstorm at posteo.de a écrit : > https://www.voidlinux.eu/ > > Luke I know you might have interest in this, because you are not fond of > systemd correct? Sorry to bring that topic up again, > > But I think you may have interest in this gnu/linux distro for that > reason. Also, it is free software if you don't load the non-free > repository. > > The bad? If you do load the module it isn't free software. > > It does however use runit by default. Also, it is rolling release like > parabola and it is an independent distro. > > pity there isn't a free software fork but still, I think you could rake > in more money by making a card for it in the future. If you can figure > out how to install it that is... ;P > > xD only kidding... you have way, way, way more experience with gnu/linux > then me. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk > -- Librement BERNARD ENG: Please be kind enough to use GPG for our future conversations: https://emailselfdefense.fsf.org/en/ If this email isn't PGP signed then it isn't mine. -If you can't compile it dump it. From calmstorm at posteo.de Sun Aug 27 00:35:06 2017 From: calmstorm at posteo.de (zap) Date: Sat, 26 Aug 2017 19:35:06 -0400 Subject: [Arm-netbook] gnu/linux distro of interest? In-Reply-To: <59A1B6CD.9070402@openmailbox.org> References: <59A1B6CD.9070402@openmailbox.org> Message-ID: <5e733d25-a2a0-39ca-b960-416196c5f7c0@posteo.de> On 08/26/2017 01:58 PM, mdn wrote: > Sharing this if anyone is interested > https://sourcemage.org/ I am... I would like to know if it works in qemu first though... > > Le 26/08/2017 19:40, calmstorm at posteo.de a écrit : >> https://www.voidlinux.eu/ >> >> Luke I know you might have interest in this, because you are not fond of >> systemd correct? Sorry to bring that topic up again, >> >> But I think you may have interest in this gnu/linux distro for that >> reason. Also, it is free software if you don't load the non-free >> repository. >> >> The bad? If you do load the module it isn't free software. >> >> It does however use runit by default. Also, it is rolling release like >> parabola and it is an independent distro. >> >> pity there isn't a free software fork but still, I think you could rake >> in more money by making a card for it in the future. If you can figure >> out how to install it that is... ;P >> >> xD only kidding... you have way, way, way more experience with gnu/linux >> then me. >> >> _______________________________________________ >> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >> Send large attachments to arm-netbook at files.phcomp.co.uk >> From bernardlprf at openmailbox.org Sun Aug 27 02:04:17 2017 From: bernardlprf at openmailbox.org (mdn) Date: Sun, 27 Aug 2017 03:04:17 +0200 Subject: [Arm-netbook] gnu/linux distro of interest? In-Reply-To: <5e733d25-a2a0-39ca-b960-416196c5f7c0@posteo.de> References: <59A1B6CD.9070402@openmailbox.org> <5e733d25-a2a0-39ca-b960-416196c5f7c0@posteo.de> Message-ID: <59A21A91.5020407@openmailbox.org> Le 27/08/2017 01:35, zap a écrit : > > > On 08/26/2017 01:58 PM, mdn wrote: >> Sharing this if anyone is interested >> https://sourcemage.org/ > I am... I would like to know if it works in qemu first though... No idea, ^^ I said that "I share if anyone is interested" not that I used it myself ;) If you test it tell us how is it (I don't have much time to do so unfortunately). Good luck and take care. >> >> Le 26/08/2017 19:40, calmstorm at posteo.de a écrit : >>> https://www.voidlinux.eu/ >>> >>> Luke I know you might have interest in this, because you are not fond of >>> systemd correct? Sorry to bring that topic up again, >>> >>> But I think you may have interest in this gnu/linux distro for that >>> reason. Also, it is free software if you don't load the non-free >>> repository. >>> >>> The bad? If you do load the module it isn't free software. >>> >>> It does however use runit by default. Also, it is rolling release like >>> parabola and it is an independent distro. >>> >>> pity there isn't a free software fork but still, I think you could rake >>> in more money by making a card for it in the future. If you can figure >>> out how to install it that is... ;P >>> >>> xD only kidding... you have way, way, way more experience with gnu/linux >>> then me. >>> >>> _______________________________________________ >>> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >>> Send large attachments to arm-netbook at files.phcomp.co.uk >>> > > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk > -- Librement BERNARD From richard.wilbur at gmail.com Sun Aug 27 19:09:41 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 27 Aug 2017 12:09:41 -0600 Subject: [Arm-netbook] gnu/linux distro of interest? In-Reply-To: <59A1B6CD.9070402@openmailbox.org> References: <59A1B6CD.9070402@openmailbox.org> Message-ID: On Aug 26, 2017, at 11:58, mdn wrote: > > Sharing this if anyone is interested > https://sourcemage.org/ Looks interesting, but in this context [arm] I notice: "We currently support x86 and x86_64 architectures. We support ppc as well, but it's getting less activity lately."[*] Reference: [*] https://sourcemage.org/Intro From richard.wilbur at gmail.com Sun Aug 27 19:36:35 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 27 Aug 2017 12:36:35 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> Message-ID: <2F45BE29-CAA3-42CE-94BE-25494677F0CE@gmail.com> On Aug 22, 2017, at 07:13, Luke Kenneth Casson Leighton wrote: > > On Tue, Aug 22, 2017 at 2:43 PM, Richard Wilbur > wrote: >> >> Is PADS libre software? I ask because here's an itch. I looked for myself and found PADS[*] is a product of Mentor Graphics. Looks like a nice tool, but I guess I don't have to worry about submitting a patch. ;>) Reference: [*] https://www.pads.com/ From lkcl at lkcl.net Sun Aug 27 20:32:58 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 27 Aug 2017 20:32:58 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <2F45BE29-CAA3-42CE-94BE-25494677F0CE@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> <2F45BE29-CAA3-42CE-94BE-25494677F0CE@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Aug 27, 2017 at 7:36 PM, Richard Wilbur wrote: > On Aug 22, 2017, at 07:13, Luke Kenneth Casson Leighton wrote: >> >> On Tue, Aug 22, 2017 at 2:43 PM, Richard Wilbur >> wrote: >>> >>> Is PADS libre software? I ask because here's an itch. > > I looked for myself and found PADS[*] is a product of Mentor Graphics. yyep. absolutely awesome one, too. i'm recommending it constantly to people, not just in the libre world but also those who use proprietary tools as well. the learning curve is nowhere near as steep as with other proprietary tools. ORCAD is completely insane: 20 menus with over 30 options on each. totally user-hostile. PADS: everything is context-sensitive, and the menu options show you a graphical representation (2D cutaway or overhead view) of what you just selected. absolutely superb. > Looks like a nice tool, but I guess I don't have to worry about submitting a patch. ;>) love to... but ehhmmm.. no :) l. From richard.wilbur at gmail.com Mon Aug 28 22:13:46 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 28 Aug 2017 15:13:46 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> Message-ID: <7BFE036D-4B8C-493C-AA2D-F909C0DB08FC@gmail.com> On Aug 22, 2017, at 08:13, Luke Kenneth Casson Leighton wrote: > > On Tue, Aug 22, 2017 at 2:43 PM, Richard Wilbur > wrote: >> How much intra-pair skew do we incur at each of those bends? > > very little. it's a 45 degree bend in each case so.... can probably > work out the maths... 15mil separation... Between traces of the same differential pair (intra-pair) I would have expected 5mil separation. I'm not entirely sure how PADS does the trace length calculation: 1. Is it measuring the inside edges of the differential pair traces? Then the intra-pair skew from one 45° corner would be 5mil. 2. Is it measuring the centers of the 5mil wide traces? If so I'd expect the intra-pair skew to be 10mil. 3. It may be measuring in a different way of which I'm not thinking. > attached diagram is probably a lot easier. i also checked the > Design Rules: board-to-everything-and-anything is set to 11.84 mil, > everything-else-to-anything-else is set to 5mil. > > so in the attached diagram those traces i put right at the bottom > will be overwritten by about... 1.2 mil to make up to the 11.84 > board-to-copper clearance. Does that mean that flood fill will cover out from 13mil off the board edge (as noted in the diagram) up to the 11.84mil board-to-copper clearance? > so, actually very simple. everything-to-everything-but-board: 5mil. > board-to-everything: 11.84mil. Simple is good--only as complicated as it needs to be. From lkcl at lkcl.net Mon Aug 28 23:44:31 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 28 Aug 2017 23:44:31 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <7BFE036D-4B8C-493C-AA2D-F909C0DB08FC@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> <7BFE036D-4B8C-493C-AA2D-F909C0DB08FC@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Aug 28, 2017 at 10:13 PM, Richard Wilbur wrote: > On Aug 22, 2017, at 08:13, Luke Kenneth Casson Leighton wrote: >> >> On Tue, Aug 22, 2017 at 2:43 PM, Richard Wilbur >> wrote: >>> How much intra-pair skew do we incur at each of those bends? >> >> very little. it's a 45 degree bend in each case so.... can probably >> work out the maths... 15mil separation... > > Between traces of the same differential pair (intra-pair) I would have expected 5mil separation. sorry i was referring to outer-edge to outer-edge so 5 trace + 5 gap + 5 tracee > I'm not entirely sure how PADS does the trace length calculation: no idea. it's most likely to be down the middle. > 2. Is it measuring the centers of the 5mil wide traces? If so I'd expect the intra-pair skew to be 10mil. true! this i would expect. >> so in the attached diagram those traces i put right at the bottom >> will be overwritten by about... 1.2 mil to make up to the 11.84 >> board-to-copper clearance. > > Does that mean that flood fill will cover out from 13mil > off the board edge (as noted in the diagram) up to the > 11.84mil board-to-copper clearance? remember i mentioned that the flood-fill has some "curvature" rules on it: if the radius (a parameter somewhere) is too small the flood-fill won't go in there. example attached: see green arrow, the track "jigs" in just at that point. grey is the flood outline btw. at that point the radius of the grey flood-fill just below the green arrow is too small, so the flood-fill refuses to go into the gap between the board edge and the track with the "jig" in it. so instead what i have to do here is to make that "manual" GND track 11 or so mil wide, and that does the trick. anyway *apart* from those special circumstances, what will happen in the case you refer to is that PADS will create a tiny bit of GND copper (13-11.84 = 1.16mm) wide just *below* that VIA's outer edge, including covering the via itself. so.. yes! that's actually shown in the 2nd picture. i selected (highlighted) the VIA, and you can see how the flood-fill outline (grey) overlaps the entire VIA (outer extent of which is 13mm from the board edge) but the flood comes *no closer* than it is told to, which is 11.84mm. basically the VIA - which is a GND via - is totally irrelevant to the distance / extent that the flood fill goes to the board edge. now if that VIA was NOT a part of the GND net *THEN* the flood fill would avoid THAT via (by the amount set in the Design Rules). but if it's the same net, flood fill "ignores" it in effect (and just floods over it as if it wasn't there). l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 42701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled2.jpg Type: image/jpeg Size: 61801 bytes Desc: not available URL: From richard.wilbur at gmail.com Tue Aug 29 01:13:10 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 28 Aug 2017 18:13:10 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <80E22C03-B0F1-4D10-863F-9A60EAD8689F@gmail.com> <14DBB668-7E5C-4013-83FD-A9BD3A299A28@gmail.com> Message-ID: On Aug 22, 2017, at 08:13, Luke Kenneth Casson Leighton wrote: Looking at your cool diagram from 22 Aug, the ground trace at the bottom of the board looks like it is 5mil wide as it appears the same width as HTXCN et al. That assumption together with the dimensions you provide leads me to believe that we can nearly have our cake and eat too! distance from ground trace to closest differential trace = 37mil from board edge to closest differential trace - 18mil from board edge to ground trace - 5mil ground trace width = 14mil I notice that the via copper extends to 13mil from board edge. Thus, if we were to move the ground trace down 1mil, we would have 15mil spacing to the closest differential trace without breaking the 11.84mil board edge clearance. (Vias would extend to 12mil from board edge.) This is good for impedance on the differential pair next to the board edge, HTXC = HDMI transmit clock. The vias will encroach closer. Can we trim the pad on the side towards the differential trace to reduce the encroachment? From doark at mail.com Tue Aug 22 22:43:08 2017 From: doark at mail.com (David Niklas) Date: Tue, 22 Aug 2017 17:43:08 -0400 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: References: Message-ID: <20170822174308.3f386a9f@ulgy_thing> On Sat, 19 Aug 2017 15:47:26 +0100 Luke Kenneth Casson Leighton wrote: > On Sat, Aug 19, 2017 at 3:34 PM, Hrvoje Lasic wrote: > > They increase the size of the motor in length. so you will be > > still able to alter torque to some extent no matter speed. Keep in > > mind that you are flexible here up to certain point. After that, if > > you need more torque you go to next bigger size of motor nema 23 or > > so. > > yes. that also increases cost, and weight, not just the motor size > but also the holders, and also the ampage needed of the controller. > which again increases cost. so, trying not to do that as it's not > necessary. > > l. Or you could use two nema 17's on one pulley. Mind, I don't know how you designed the pulley system so this might be rather difficult or really easy. Sincerely, David From lkcl at lkcl.net Tue Aug 29 18:58:32 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 29 Aug 2017 18:58:32 +0100 Subject: [Arm-netbook] physics analysis needed of belt-driven pulley system In-Reply-To: <20170822174308.3f386a9f@ulgy_thing> References: <20170822174308.3f386a9f@ulgy_thing> Message-ID: On Tue, Aug 22, 2017 at 10:43 PM, David Niklas wrote: > Or you could use two nema 17's on one pulley. > Mind, I don't know how you designed the pulley system so this might be > rather difficult or really easy. yyeah... trying that would have me concerned. more tomorrow. 2am now. l. From richard.wilbur at gmail.com Tue Aug 29 19:12:47 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 29 Aug 2017 12:12:47 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: > On Aug 22, 2017, at 12:25, Luke Kenneth Casson Leighton wrote: > > okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i > can shorten even more, there's definitely plenty of space there, big > gap. Do you mean left end from the top of the board? (The first image I see shows the μHDMI connector end of the differential pairs.) > 2nd image, right end, this is where i've added intra-pair wiggles at > the 45 degree bends. Do you mean right end from the top of the board? (The second image I see shows the SoC end of the HDMI differential pairs.) From lkcl at lkcl.net Tue Aug 29 19:23:32 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 29 Aug 2017 19:23:32 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Aug 29, 2017 at 7:12 PM, Richard Wilbur wrote: >> On Aug 22, 2017, at 12:25, Luke Kenneth Casson Leighton wrote: >> >> okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i >> can shorten even more, there's definitely plenty of space there, big >> gap. > > Do you mean left end from the top of the board? (The first image I see shows the μHDMI connector end of the differential pairs.) micro-hdmi connector is right end. >> 2nd image, right end, this is where i've added intra-pair wiggles at >> the 45 degree bends. > > Do you mean right end from the top of the board? (The second image I see shows the SoC end of the HDMI differential pairs.) SoC end of the HDMI traces is left end. so. http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-August/014639.html this is right end: http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170822/a4632db6/attachment-0002.jpg this is left end: http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170822/a4632db6/attachment-0003.jpg so. >> okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i >> can shorten even more, there's definitely plenty of space there, big >> gap. http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170822/a4632db6/attachment-0003.jpg >> 2nd image, right end, this is where i've added intra-pair wiggles at >> the 45 degree bends. http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170822/a4632db6/attachment-0002.jpg l. From richard.wilbur at gmail.com Wed Aug 30 01:54:56 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 29 Aug 2017 18:54:56 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Luke, Thank you ever so much for the clarification regarding perspective. Comments inline below. On Aug 22, 2017, at 12:25, Luke Kenneth Casson Leighton wrote: > > okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i > can shorten even more, there's definitely plenty of space there, big > gap. Shortening CX and TX0 is fine but I would cramp any of the clearances to make it happen. On the other hand, if you were to put them into a 45° bend from south to southeast a little sooner, we would probably have enough room to adjust the ground shield trace on the southwest and west to abide by our 15mil differential trace to "anything not in the same pair" clearance (specifically to HTXCN). > 2nd image, right end, this is where i've added intra-pair wiggles at > the 45 degree bends. i can't get away with a proper 4-turn using 45 > degrees, PADS goes "nope that's too short a trace, i'm gonna assume > you want a straight line instead" - there's probably an option > somewhere for that but i've not found it. alternatively i can add in > a (curvy) accordion.... I agree. If you don't have enough room to make a trace facet length >= 1.5 * trace width then I would also resort to an arc (curve). (Which for 5mil wide traces suggests minimum facet length of 7.5mil.) > anyway those wiggles are done by hand, some of them aren't pretty but > in mil those traces are now nearly all to within 0.01 mil. i cheat a > little and have made some of the corners in places a very very tiny > arc, where you get better fine-grain control over the amount it takes > off. Well done. > HTXCN just before the diff-pair vias at the end i'm a little concerned > about, it looks a bit too... sharp-angled to make me feel totally > comfortable... not a lot of space... i tried a single wiggle and it > went too far away from HTXCP for me to feel happy about it.... put in > two much smaller wiggles instead... > > GND i'll remove as the absolute last thing. Sounds great. Only really want to remove the ground traces that can't comply with the 15mil clearance between differential pair and anything not in the same pair. From richard.wilbur at gmail.com Wed Aug 30 02:14:42 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 29 Aug 2017 19:14:42 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: <4CEFE16B-1C8E-44F9-B6C9-4EF903923389@gmail.com> On Aug 29, 2017, at 18:54, Richard Wilbur wrote: > Shortening CX and TX0 is fine but I would cramp any of the clearances to make it happen. Sorry for any misconceptions. I meant to say: "Shortening CX and TX0 is fine but I would not cramp any of the clearances to make it happen." From lkcl at lkcl.net Wed Aug 30 02:25:57 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 30 Aug 2017 02:25:57 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <4CEFE16B-1C8E-44F9-B6C9-4EF903923389@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> <4CEFE16B-1C8E-44F9-B6C9-4EF903923389@gmail.com> Message-ID: On Wed, Aug 30, 2017 at 2:14 AM, Richard Wilbur wrote: > On Aug 29, 2017, at 18:54, Richard Wilbur wrote: >> Shortening CX and TX0 is fine but I would cramp any of the clearances to make it happen. > > Sorry for any misconceptions. I meant to say: > > "Shortening CX and TX0 is fine but I would not cramp any of the clearances to make it happen." ah! luckily that can't be done anyway :) From lkcl at lkcl.net Wed Aug 30 02:13:41 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 30 Aug 2017 02:13:41 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Aug 30, 2017 at 1:54 AM, Richard Wilbur wrote: > Luke, > > Thank you ever so much for the clarification regarding perspective. > > Comments inline below. > > On Aug 22, 2017, at 12:25, Luke Kenneth Casson Leighton wrote: >> >> okaay, wiggle-progress... 1st image is left end, i think CX and TX0 i >> can shorten even more, there's definitely plenty of space there, big >> gap. > > Shortening CX and TX0 is fine but I would cramp any > of the clearances to make it happen. there aren't any!! the GND separation vias see to that (attached). no there's not enough room to move those GND vias *in between* the VIAs, they need to be below, unfortunately. that means the diffpairs need to curve _round_ them (to the SW slightly). oops. actually it just occurred to me that i could move the HXT?P vias over by another.... 10-15 mil or so, which would mean that the corresponding HXT?N traces would be able to go straight (directly south) instead of SW, S then SE. phrrrrddhh :) > On the other hand, if you were to put them into a 45° > bend from south to southeast a little sooner, > we would probably have enough room to adjust the ground shield > trace on the southwest and west to abide by our 15mil differential > trace to "anything not in the same pair" clearance (specifically to HTXCN). well, unless i add a flood-exclusion zone (thoughts on that?) anything W or SW of HTXCN is going to get flood-filled with GND. or... i _could_ just put in a copper-to-diffpair Design Rule of "15 mil" clearance - that would keep the flood-fill away. >> anyway those wiggles are done by hand, some of them aren't pretty but >> in mil those traces are now nearly all to within 0.01 mil. i cheat a >> little and have made some of the corners in places a very very tiny >> arc, where you get better fine-grain control over the amount it takes >> off. > > Well done. ... i'm getting used to it.... >> HTXCN just before the diff-pair vias at the end i'm a little concerned >> about, it looks a bit too... sharp-angled to make me feel totally >> comfortable... not a lot of space... i tried a single wiggle and it >> went too far away from HTXCP for me to feel happy about it.... put in >> two much smaller wiggles instead... >> >> GND i'll remove as the absolute last thing. > > Sounds great. Only really want to remove the ground traces > that can't comply with the 15mil clearance between differential pair and anything not in the same pair. marked in this image, i was planning to remove the GND traces that are marked with red dots.... but only after all's done because currently they help keep the inter-pair separation. does that sound sensible? l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 92784 bytes Desc: not available URL: From richard.wilbur at gmail.com Wed Aug 30 07:18:35 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 30 Aug 2017 00:18:35 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: Sent from my iPhone On Aug 29, 2017, at 19:13, Luke Kenneth Casson Leighton wrote: > On Wed, Aug 30, 2017 at 1:54 AM, Richard Wilbur > wrote: > > there aren't any!! the GND separation vias see to that (attached). > no there's not enough room to move those GND vias *in between* the > VIAs, they need to be below, unfortunately. that means the diffpairs > need to curve _round_ them (to the SW slightly). oops. > > actually it just occurred to me that i could move the HXT?P vias over > by another.... 10-15 mil or so, which would mean that the > corresponding HXT?N traces would be able to go straight (directly > south) instead of SW, S then SE. Which is an elegant way of doing some intra-pair (within the pair) skew compensation--by avoiding some the sources of skew to begin with. Sounds like a fine idea! >> On the other hand, if you were to put them into a 45° >> bend from south to southeast a little sooner, >> we would probably have enough room to adjust the ground shield >> trace on the southwest and west to abide by our 15mil differential >> trace to "anything not in the same pair" clearance (specifically to HTXCN). > > well, unless i add a flood-exclusion zone (thoughts on that?) > anything W or SW of HTXCN is going to get flood-filled with GND. Flood-exclusion zone is just the ticket if you don't have a more flexible way. In this case it would increase the maintenance costs (time and effort) of the differential pair clearance to other circuits because it has to be manually checked and moved when needed. > or... i _could_ just put in a copper-to-diffpair Design Rule of "15 > mil" clearance - that would keep the flood-fill away. I think this is the most maintainable solution. […] > ... i'm getting used to it.... "Practice makes easy." […] > marked in this image, i was planning to remove the GND traces that > are marked with red dots.... but only after all's done because > currently they help keep the inter-pair separation. > > does that sound sensible? Eminently so! From richard.wilbur at gmail.com Wed Aug 30 07:59:06 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 30 Aug 2017 00:59:06 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: I have a question about one of the traces: In the layout picture it appears that something resembling a via coincides with HTX1P following the second wiggle after the trace turns NE. If it is a via, what is it doing there? If not, what is it? I would recommend if you want to be able to solder or desolder by hand the μHDMI connector to/from the board that you use thermal relief (multiple spokes emanating from the land) when connecting ACIN-5V to pin 19. On the other hand, this solid layout does make a lower impedance connection for power and should work fine in the surface-mount oven for soldering as long as you have solder resist covering the trace outside the ESD land for pin 19. Of course, hopefully you never have need of soldering or desoldering the μHDMI connector by hand. Looks best left to the oven. From lkcl at lkcl.net Wed Aug 30 11:01:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 30 Aug 2017 11:01:45 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: On Wed, Aug 30, 2017 at 7:18 AM, Richard Wilbur wrote: >> actually it just occurred to me that i could move the HXT?P vias over >> by another.... 10-15 mil or so, which would mean that the >> corresponding HXT?N traces would be able to go straight (directly >> south) instead of SW, S then SE. > > Which is an elegant way of doing some intra-pair (within the pair) > skew compensation--by avoiding some the sources of skew > to begin with. Sounds like a fine idea! mrhm grumble i have to redo those nice length-matchings.... agaaainn aaargh :) >> or... i _could_ just put in a copper-to-diffpair Design Rule of "15 >> mil" clearance - that would keep the flood-fill away. > > I think this is the most maintainable solution. ok attached is the result of doing that. layer 1 just after the SoC the "surround" on the vias is well over 15mil away, on *all* layers... including GND. all VIAs are now avoided by the specified 15mil. ... seems a bit much, to me.... > […] >> ... i'm getting used to it.... > > "Practice makes easy." > > […] >> marked in this image, i was planning to remove the GND traces that >> are marked with red dots.... but only after all's done because >> currently they help keep the inter-pair separation. >> >> does that sound sensible? > > Eminently so! awesome. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled3.jpg Type: image/jpeg Size: 90836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled2.jpg Type: image/jpeg Size: 116902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 85498 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled4.jpg Type: image/jpeg Size: 29630 bytes Desc: not available URL: From lkcl at lkcl.net Wed Aug 30 11:07:16 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 30 Aug 2017 11:07:16 +0100 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> Message-ID: On Wed, Aug 30, 2017 at 7:59 AM, Richard Wilbur wrote: > I have a question about one of the traces: In the layout picture it appears that something resembling a via coincides with HTX1P following the second wiggle after the trace turns NE. If it is a via, what is it doing there? If not, what is it? you've lost me, sorry. i don't know if you have access to an image editor but an arrow pointing would help - i know you're using an iphone so that might be a leetle awwkward... > Of course, hopefully you never have need of soldering or desoldering the μHDMI connector by hand. Looks best left to the oven. yyeah this connector is a bitch to take off by hand. the heatgun literally melts the plastic inside the case and that's it, it's done - in the bin. with the added risk that it can strip off the pads on its way up. then when you try and put a replacement on, that melts too, the pins move off the same plane and it's game over for *that* connector, too. this is why we'll be doing a test run of some low-cost 2-layer PCBs (1in x 1in) just with the DC3 land pattern and some test jumpers, which will go through the oven to make sure that the DC3 actually sits down and all pins connect to their pads. lot less risky than $USD 2,000 for complete PCBs only to find that after 5-8 weeks yet another footprint layout doesn't work..... l. From richard.wilbur at gmail.com Wed Aug 30 21:34:07 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 30 Aug 2017 14:34:07 -0600 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> Message-ID: On Wed, Aug 23, 2017 at 5:27 AM, Luke Kenneth Casson Leighton wrote: > damn. i just noticed: the via transition here is at 90 degrees. > i've been switching off except 1 layer at a time so didn't notice. > arse. > > i'll need to shift all but the TX2 via set down a fixed amount so i > can get a second wiggle in the right-hand one one layer 1, to make the > track come in to the top right corner (1 o clock). rather than as they > do now: from right side (3 o clock). Not necessarily bad on the same scale as you might think. Our board is ~47mil thick while the copper is ~1mil thick, so when a signal plunges into a via from top to bottom it's already making a 90 degree turn into and out of the via. I'm not criticizing your attempt to straighten out some corners we have control over in the signal path, just pointing out that vias themselves present the signal with a couple 90 degree turns.