X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 27 Jul 2015 10:35:24 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] pcb-rnd feature poll: please vote In-Reply-To: <20150727081830.GC31594@visitor2.iram.es> Message-ID: References: <201507251534 DOT t6PFYRiK016181 AT envy DOT delorie DOT com> <201507260205 DOT t6Q257OU004585 AT envy DOT delorie DOT com> <20150727081830 DOT GC31594 AT visitor2 DOT iram DOT es> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 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. Regards, Igor2