www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2011/10/16/18:04:10

X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
Subject: Re: [geda-help] Weeding out rounding-error dot/lines?
From: Richard Rasker <rasker AT linetec DOT nl>
To: geda-help AT delorie DOT com
In-Reply-To: <1318798816.11791.7.camel@localhost>
References: <1318794799 DOT 9014 DOT 61 DOT camel AT localhost>
<1318798816 DOT 11791 DOT 7 DOT camel AT localhost>
Organization: Linetec
Date: Mon, 17 Oct 2011 00:03:55 +0200
Message-Id: <1318802635.9014.89.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1-2.2mdv2008.1
Reply-To: geda-help AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-help AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Op zondag 16-10-2011 om 22:00 uur [tijdzone +0100], schreef Peter
Clifton:
> On Sun, 2011-10-16 at 21:53 +0200, Richard Rasker wrote:
> > Hello,
> > 
> > I'm busy with a design incorporating DDR RAM chips, where signal timing
> > and hence line length is of the essence.
> 
> As a related question, when you have curved or stepped traces - how does
> the effective electrical length compare to the actual track geometry? 
> 
> For example, a curved trace is shorter along its inner edge than on its
> centreline. Does this mean we should count the shortest possible
> "rubber-band" path within the actual track, or does the radiation
> pattern push the current to the centre of the track?
> 
> Are these effects significant enough to worry about?
> 
> How tight to you have to match the track lengths on a modern DDR chip?

Well, according to this application notes, rather tight matching is
required:

http://cache.freescale.com/files/dsp/doc/app_note/AN4054.pdf

And the designer's checklist also shows that it isn't exactly easy to
get things right:

http://www.freescale.com/files/32bit/doc/app_note/AN2910.pdf


Please note that PCB's rounding error itself doesn't introduce
significant problems in itself, and neither do the small stub lines
which appear.

Problems occur when I stretch these dots without noticing (e.g. by
dragging it along the line itself, when I actually attempt to drag the
corner point), messing up the line's length calculation. Here's an
example of what this can result in:

http://www.linetec.nl/equal_lines_different.pcb

Both lines look identical, but the length calculation shows a difference
in lenght of approximately 5 mm -- and when that happens in a DDR data
line, this can mean the difference between proper and unstable
functioning. Only when I select or drag the affected line segment, the
hidden extra line segment shows up.

> Does track inductance / capacitance to surroundings create a more
> significant delay effect?

No doubt, and that's why I'm using lines with one width, as much as
possible on one layer per function group, without layer hopping, and
with all serpentine lenght matching placed between the controller and
the memory connections etcetera etcetera. See the above application note
and checklist.

> > I already defined a key binding for reporting net length, and now I
> > found that the mil/mm rounding error sometimes causes problems in an
> > insidious way: when an extra "mini-line" (dot) is created at a via or
> > bend point, and this point is subsequently dragged along the line
> > itself, the dot gets stretched into a line.
> > I don't always notice when this happens, and the problem is that the
> > length of the inadvertently created line is added to the total line
> > length. Worst case, I end up with quite the wrong length.
> > 
> > Is there an easy way to find or eliminate these dot/lines?
> 
> I believe DJ might have had have a plugin for finding and eliminating
> short track segments, but I may also have just made that up. Finding the
> very short segments is probably easier than once they have been
> stretched of course.
> 
> I'm not certain whether these short stub tracks should be created since
> we moved to nm internal units. If they are - perhaps the underlying
> cause was not as we thought, and is still lurking.
> 
> What PCB version are you using?

I'm still on version 20100929. I have to upgrade my rather outdated
Linux distribution in order to compile the latest git version, and
that's too much hassle at the moment -- right now, my highest priority
is to get my circuit board to the manufacturer.

When matching line leghts, I just stumbled upon two lines which were
significantly longer than expected, and only then I realized what had
happened. Further investigation turned up two more lines with false
lengths, albeit still within specifications.

I just wondered if there's a way to mitigate this problem by eliminating
those little stubs. 

Anyway, thanks for your quick reply, and I'll see what I can find in
DJ's tool box.

Best regards,

Richard Rasker

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019