[Arm-netbook] HDMI High-Frequency Layout: Recommendations
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat Aug 19 03:54:37 BST 2017
On Thu, Aug 17, 2017 at 5:20 PM, Richard Wilbur
<richard.wilbur 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.
> Sounds like just the ticket. So you have a flood-fill on the bottom layer?
> 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.
> 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
> 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
> 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?
> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 372556 bytes
Desc: not available
More information about the arm-netbook