X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Envelope-From: paubert AT iram DOT es
Date: Mon, 27 Jul 2015 12:48:50 +0200
From: "Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pcb-rnd feature poll: please vote
Message-ID: <20150727104850.GA31438@visitor2.iram.es>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1507251201460 DOT 6924 AT igor2priv>
 <201507251534 DOT t6PFYRiK016181 AT envy DOT delorie DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1507251743490 DOT 6924 AT igor2priv>
 <201507260205 DOT t6Q257OU004585 AT envy DOT delorie DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1507260417410 DOT 6924 AT igor2priv>
 <20150727081830 DOT GC31594 AT visitor2 DOT iram DOT es>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1507271029180 DOT 6924 AT igor2priv>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1507271029180.6924@igor2priv>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -0.2 (/)
X-Spamina-Spam-Report: Content analysis details:   (-0.2 points)
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
  0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                             [score: 0.5000]
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                             See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: delorie.com]
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Mon, Jul 27, 2015 at 10:35:24AM +0200, gedau AT igor2 DOT repo DOT hu wrote:
> 
> 
> On Mon, 27 Jul 2015, Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com] wrote:
> 
> >On Sun, Jul 26, 2015 at 04:30:04AM +0200, gedau AT igor2 DOT repo DOT hu wrote:
> >>
> >>
> >>On Sat, 25 Jul 2015, DJ Delorie wrote:
> >>
> >>>If that includes specifying coordinates, then sweet :-)
> >>>
> >>>>I've just installed 20140306 (was that the last snapshot?) to test it.
> >>>>With the gtk hid, 'R' doesn't do anything. Report doesn't print length
> >>>>info either.
> >>>
> >>>Might be lesstif-only.  :Report(NetLength) for gtk.
> >>
> >>Cool, thanks! Then I modify this point to add only the differences
> >>in some details I had in mind:
> >>
> >>- handle junctions (I already have most of graph buliding/handling
> >>the code because of mincut)
> >>
> >>- because of that, more integration with the GUI: lengths printed on
> >>the traces between junctions
> >>
> >>- I am not sure yet to what extent, but try to handle some of the
> >>corner cases: don't count overlapping traces twice, take
> >>poly/via/pin as a junction
> >
> >As soon as you have a polygon in a net, defining its length becomes
> >dubious, to put it mildly.
> 
> Yup. High freq will follow paths that I won't be able to predict. My
> plan is to say the whole poly is a big junction and I calculate
> trace lengths from junction to junction.
> 
> Practical example: you have a trace between your MCU and your two
> sdram chips and the return path is on a ground plane. You can see
> the trace lengths going from the MCU to the ram chips, seeing all
> arms of the T junction. Since return path is a ground plane, you
> can't use this feature to tell anything about the "trace length" of
> the return signal.
> 
> I think it's not common to mix traces and polygons along a high
> speed trace where you want to tune the length - but I'm real novice
> in high speed design.

Correct, there are essentially two methods:

- single ended microstrip/stripline in which the length is defined
  by the net segments of the signal and return current goes through the 
  ground plane(s) more or less following the path defined by the signal 
  (except that actual current paths will be significantly wider, resulting 
  in lower effective resistance/inductance). Grounded coplanar waveguide,
  very popular with Hittite's (now Analog's) evaluation boards, is
  similar. I've never used nor seen pure coplanar used so I won't 
  comment on it.

- differential signaling, in which two parallel lines carry current in
  opposite direction (a least the AC part, differential ECL signals
  sometimes have a bias current on the signal tracks, depending on where 
  the loads are located). Both lines ideally have to have the same
  length, this is not always possible because of turns and/or location of 
  the pads (sometimes the two pins of a differential pair on a FPGA in a
  BGA package are not neighbours).


In both cases: 
- these are point to point signals and stubs are essentially prohibited, 
- line length is easy to define, it should be the distance from source
  to load, ignoring the (always short) stubs, and for differential signal, 
  the length difference between both nets should be minimized.


    Regards,
    Gabriel