Mail Archives: geda-user/2015/07/27/04:34:36
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
- Raw text -