Mail Archives: geda-user/2015/07/27/04:53:13
--047d7b6222e4c1ddc7051bd77a94
Content-Type: text/plain; charset=UTF-8
Hi there,
my votes are:
3b, I work with RF circuitry and trace length calculation would be very
useful!
5, a little step for a more flexible component library.
2, I'm not a Windows user but in my opinion this could be a good way to
expand the gEDA community. If needed I can set a VM with Windows to test
the Win32 port.
Thank you for this nice work! :)
- Filippo -
On 27 July 2015 at 10:35, <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.
>
> Regards,
>
> Igor2
>
--047d7b6222e4c1ddc7051bd77a94
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi there,</div><div>my votes are:</div><div>3b, I wor=
k with RF circuitry and trace length calculation would be very useful!</div=
><div>5, a little step for a more flexible component library.</div><div>2, =
I'm not a Windows user but in my opinion this could be a good way to ex=
pand the gEDA community. If needed I can set a VM with Windows to test the =
Win32 port.</div><div>Thank you for this nice work! :)</div></div><div clas=
s=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><di=
v dir=3D"ltr"><div><br>- Filippo -</div></div></div></div>
<br><div class=3D"gmail_quote">On 27 July 2015 at 10:35, <span dir=3D"ltr"=
><<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu" target=3D"_blank">gedau AT igor2 DOT r=
epo.hu</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><br>
<br>
On Mon, 27 Jul 2015, Gabriel Paubert (<a href=3D"mailto:paubert AT iram DOT es" ta=
rget=3D"_blank">paubert AT iram DOT es</a>) [via <a href=3D"mailto:geda-user AT delor=
ie.com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<br>
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Jul 26, 2015 at 04:30:04AM +0200, <a href=3D"mailto:gedau AT igor2 DOT rep=
o.hu" target=3D"_blank">gedau AT igor2 DOT repo DOT hu</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<br>
On Sat, 25 Jul 2015, DJ Delorie wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
If that includes specifying coordinates, then sweet :-)<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I've just installed 20140306 (was that the last snapshot?) to test it.<=
br>
With the gtk hid, 'R' doesn't do anything. Report doesn't p=
rint length<br>
info either.<br>
</blockquote>
<br>
Might be lesstif-only.=C2=A0 :Report(NetLength) for gtk.<br>
</blockquote>
<br>
Cool, thanks! Then I modify this point to add only the differences<br>
in some details I had in mind:<br>
<br>
- handle junctions (I already have most of graph buliding/handling<br>
the code because of mincut)<br>
<br>
- because of that, more integration with the GUI: lengths printed on<br>
the traces between junctions<br>
<br>
- I am not sure yet to what extent, but try to handle some of the<br>
corner cases: don't count overlapping traces twice, take<br>
poly/via/pin as a junction<br>
</blockquote>
<br>
As soon as you have a polygon in a net, defining its length becomes<br>
dubious, to put it mildly.<br>
</blockquote>
<br></span>
Yup. High freq will follow paths that I won't be able to predict. My pl=
an is to say the whole poly is a big junction and I calculate trace lengths=
from junction to junction.<br>
<br>
Practical example: you have a trace between your MCU and your two sdram chi=
ps 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. Sin=
ce return path is a ground plane, you can't use this feature to tell an=
ything about the "trace length" of the return signal.<br>
<br>
I think it's not common to mix traces and polygons along a high speed t=
race where you want to tune the length - but I'm real novice in high sp=
eed design.<br>
<br>
Regards,<br>
<br>
Igor2<br>
</blockquote></div><br></div>
--047d7b6222e4c1ddc7051bd77a94--
- Raw text -