Mail Archives: geda-user/2015/10/23/04:29:45
--089e01495336d6a4370522c16723
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-10-23 2:57 GMT+02:00 John Doty <jpd AT noqsi DOT com>:
[snip]
Along with DJ, I fear that many don=E2=80=99t use it. But there have been a=
couple
> of fixes since:
>
> ;; 2010-12-11: Fix stack overflows with large designs.
> ;; 2010-10-02: Applied patch from Karl Hammar. Do drc-matrix lower
> triangular
> ;; and let get-drc-matrixelement swap row/column if ro=
w
> < column.
>
> Yes, but nothing having to do with slotted symbols...
>
>
> Reading the designer's mind is impossible for any tool. drc2 checks, othe=
r
> than duplicated refdes/slots, can be mainly used for digital design but
> hardly help for mixed signal.
>
>
> I wonder how many users are making single-supply digital MSI circuits any
> more? These days, my pure logic tends to collapse into an FPGA, and my
> digital DRC concerns wind up being 2.5V logic versus 3.3V logic and
> electromagnetic fanout issues on unterminated logic lines.
>
That's was my point. Do you know any other test our drc could run for
analog or mixed signal?
However, I'm pretty sure it can be improved, and those people who may know
> how, are those doing mixed/analog designs. Can anyone share any additiona=
l
> test? :)
>
>
>> > You are fluent in scheme. Why don't you help to improve it instead of
>> complaining about it every time?
>>
>> I posted a new approach to the duplicate refdes/pin problem today on thi=
s
>> list. I prefer to write new things rather than change old things that ar=
e
>> in use. I=E2=80=99m not smart enough to avoid breaking other people=E2=
=80=99s applications:
>> one man=E2=80=99s bug is another man=E2=80=99s feature. I=E2=80=99m sure=
drc2=E2=80=99s model of schematic
>> design fits some folk=E2=80=99s flows fine. It just doesn=E2=80=99t fit =
mine terribly well.
>> By writing something new I get to serve my interests without harming
>> anybody else=E2=80=99s.
>>
>>
> Regarding breaking any other flow, please see below.
>
> I'm ok with that. However, if we know drc2 has problems with that, I'd
> like to see it fixed.
> Why about including your backend into drc2, or making drc2 call your
> backend?
>
>
> The whole thing=E2=80=99s only five small functions. Only the top level
> (check-duplicates) has any side effects, so the others should not have
> any compatibility issues with your code. (check-duplicates) implements a
> different style of informing the user than drc2: it writes to stderr and
> then exits with an error code. To use the other functions in drc2 style,
> invoke (find-duplicates (every-connection)) and write the resulting list
> to the output file, suitably formatted.
>
Fine. We can agree on how to do it (see below), but as I haven't programmed
in scheme for years now, I would prefer if you could prepare a patch. Could
be possible?
> Using a bottom-up approach, it doesn=E2=80=99t determine a top-down reaso=
n for the
> duplicate. It could be a duplicate slot, duplicate refdes, faulty symbol,
> or maybe something I haven=E2=80=99t though of. I don=E2=80=99t expect th=
at users will have
> too much trouble here, although that is a general weakness of the bottom-=
up
> approach. Of course, the fact that it=E2=80=99s sensitive to effects rath=
er than
> causes means that I don=E2=80=99t have the burden of figuring out every p=
ossible
> cause.
>
> I=E2=80=99m thinking about a bottom-up approach to detecting missing slot
> assignments and missing parts of split symbols. The standard gEDA footpri=
nt
> names are pretty good for this purpose, as they encode the pin count in a
> regular way. Some of the symbols in the gEDA library also have pins=3D
> attributes. Since I export to Allegro, and it expects the netlister to te=
ll
> it how many pins the footprint is expected to have, I have to deal with
> this anyway. So, count pins and verify that the right number are present.
>
The main problem with that is that it's only valid for PCB workflow, and
depends on the footprint names... ;)
I'd prefer to introduce some kind of notion of package. As someone already
said, combining a light symbol schematic with some sort of package
definition before generating the netlist to other backends.
This package definition would define which symbols and how many slots for
each symbol, pin names, not connected pins... for example.
If we want to go further, voltage range, thresholds and current for each
pin, but that's another issue.
As all tests are configurable, this could be added as an additional test,
> and let the users enable/disable tests according their needs.
>
>
> Personally, I prefer a collection of simple programs to a more complicate=
d
> configurable program. I=E2=80=99m very much a disciple of Brian Kernighan=
and Rob
> Pike (see http://harmful.cat-v.org/cat-v/unix_prog_design.pdf). But
> there=E2=80=99s no reason we can=E2=80=99t have both.
>
> That's what I meant when I told "making drc2 call your backend". If we
have such "collection of simple programs", drc2 can call them. That way
users only have to worry about running drc2 and configure which tests they
want to do.
>
>
>> >
>> > One of your fears is that some change in the code break some backend.
>>
>> That=E2=80=99s part of it. But I also fear that making the core code mor=
e rigid
>> and use case oriented may paralyze future development. To be use case
>> oriented is OK for something optional like drc2, but it=E2=80=99s not OK=
for the
>> core code.
>>
>> > You know there are regression tests trying to avoid this.
>>
>> Yes, I know. It's good to have tests. However, they can=E2=80=99t check =
users=E2=80=99
>> private scripts. I=E2=80=99m not the only one who has them. They can=E2=
=80=99t check every
>> diagram and crazy symbol in use. People do all kinds of things with
>> geda-gaf, even plumbing networks! Nobody fully understands the breadth o=
f
>> geda-gaf=E2=80=99s application space. We should therefore be very, very =
cautious
>> about changing core code. Why not put the effort into new tools and scri=
pts?
>>
>
> That's a pretty well know concern. There is no need to worry about other
> unpublished backends.
> You already dig into this in another mail. What we need is a good test
> suite for the gnetlist API, in order to be sure any change to the core
> doesn't change gnetlist's behaviour.
> If the API is not changed, there is no chance to break other backends.
>
>
> Except for ambiguous cases. Those are tough. When Bas Gieltjes and I
> proposed a solution to the "attribute censorship=E2=80=9D bug, Patrick Be=
rnaud and
> Peter Brett insisted that not only should the API stay the same, but it
> should reproduce the ambiguous (but deterministic) behavior of the old AP=
I
> unless the user reconfigured it with a plugin. Thus, the bug wasn=E2=80=
=99t fixed.
> In that case, I found myself on the side of change rather than stability,
> but, of course, I can see the other side too.
>
We are not talking about changing the API, but checking it has not changed
after a modification.
>
> You have enligthened us with some backends nobody could even think about.
> I'm pretty sure you know pretty well how to use the API. Why not start
> writing an API test backend/suite?
>
>
> I will consider it. I am, however, more enthusiastic about writing new
> tools than enabling changes to old ones.
>
>
An API checking backend is a new tool! ;)
Regards,
Carlos
--089e01495336d6a4370522c16723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-10-23 2:57 GMT+02:00 John Doty <span dir=3D"ltr"><<a href=3D"ma=
ilto:jpd AT noqsi DOT com" target=3D"_blank">jpd AT noqsi DOT com</a>></span>:<div sty=
le=3D"word-wrap:break-word"><span class=3D"">[snip]</span></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wr=
ap:break-word"><div>Along with DJ, I fear that many don=E2=80=99t use it. B=
ut there have been a couple of fixes since:</div><div><br></div><div><div s=
tyle=3D"margin:0px;font-size:10px;font-family:Monaco">;;=C2=A0 2010-12-11: =
Fix stack overflows with large designs.</div><div style=3D"margin:0px;font-=
size:10px;font-family:Monaco">;;=C2=A0 2010-10-02: Applied patch from Karl =
Hammar. Do drc-matrix lower triangular</div><div style=3D"margin:0px;font-s=
ize:10px;font-family:Monaco">;;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and let get-drc-matrixelement swap row/column i=
f row < column.</div><div><br></div></div><div><span class=3D"">Yes, but=
nothing having to do with slotted symbols...<br></span></div><div><span cl=
ass=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div><br>Reading the designer's mind is =
impossible for any tool. drc2 checks, other than duplicated refdes/slots, c=
an be mainly used for digital design but hardly help for mixed signal.<br><=
/div></div></div></div></blockquote><div><br></div></span>I wonder how many=
users are making single-supply digital MSI circuits any more? These days, =
my pure logic tends to collapse into an FPGA, and my digital DRC concerns w=
ind up being 2.5V logic versus 3.3V logic and electromagnetic fanout issues=
on unterminated logic lines.<span class=3D""><br></span></div></div></bloc=
kquote><div><br></div><div>That's was my point. Do you know any other t=
est our drc could run for analog or mixed signal?<br></div><br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><=
div><span class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>However, I'm pretty su=
re it can be improved, and those people who may know how, are those doing m=
ixed/analog designs. Can anyone share any additional test? :)<br>=C2=A0<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> You are fluent in scheme. Why don't you help to improve it instead=
of complaining about it every time?<br>
<br>
</span>I posted a new approach to the duplicate refdes/pin problem today on=
this list. I prefer to write new things rather than change old things that=
are in use. I=E2=80=99m not smart enough to avoid breaking other people=E2=
=80=99s applications: one man=E2=80=99s bug is another man=E2=80=99s featur=
e. I=E2=80=99m sure drc2=E2=80=99s model of schematic design fits some folk=
=E2=80=99s flows fine. It just doesn=E2=80=99t fit mine terribly well. By w=
riting something new I get to serve my interests without harming anybody el=
se=E2=80=99s.<br>
<span><br></span></blockquote><div><br></div><div><div>Regarding breaking a=
ny other flow, please see below.<br></div><div><br></div>I'm ok with th=
at. However, if we know drc2 has problems with that, I'd like to see it=
fixed.<br></div>Why about including your backend into drc2, or making drc2=
call your backend?<br></div></div></div></blockquote><div><br></div></span=
>The whole thing=E2=80=99s only five small functions. Only the top level=C2=
=A0<span style=3D"font-family:Monaco;font-size:10px">(check-duplicates)=C2=
=A0</span>has any side effects, so the others should not have any compatibi=
lity issues with your code.=C2=A0<span style=3D"font-family:Monaco;font-siz=
e:10px">(check-duplicates)=C2=A0</span>implements a different style of info=
rming the user than drc2: it writes to stderr and then exits with an error =
code. To use the other functions in drc2 style, invoke=C2=A0<span style=3D"=
font-family:Monaco;font-size:10px">(find-duplicates (every-connection))=C2=
=A0</span>and write the resulting list to the output file, suitably formatt=
ed.=C2=A0</div></div></blockquote><div><br></div><div>Fine. We can agree on=
how to do it (see below), but as I haven't programmed in scheme for ye=
ars now, I would prefer if you could prepare a patch. Could be possible?<br=
>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div>Using a bottom-up approach, it doesn=E2=80=
=99t determine a top-down reason for the duplicate. It could be a duplicate=
slot, duplicate refdes, faulty symbol, or maybe something I haven=E2=80=99=
t though of. I don=E2=80=99t expect that users will have too much trouble h=
ere, although that is a general weakness of the bottom-up approach. Of cour=
se, the fact that it=E2=80=99s sensitive to effects rather than causes mean=
s that I don=E2=80=99t have the burden of figuring out every possible cause=
.</div><div><br></div><div>I=E2=80=99m thinking about a bottom-up approach =
to detecting missing slot assignments and missing parts of split symbols. T=
he standard gEDA footprint names are pretty good for this purpose, as they =
encode the pin count in a regular way. Some of the symbols in the gEDA libr=
ary also have pins=3D attributes. Since I export to Allegro, and it expects=
the netlister to tell it how many pins the footprint is expected to have, =
I have to deal with this anyway. So, count pins and verify that the right n=
umber are present.</div></div></blockquote><div><br></div><div>The main pro=
blem with that is that it's only valid for PCB workflow, and depends on=
the footprint names... ;)<br><br></div><div>I'd prefer to introduce so=
me kind of notion of package. As someone already said, combining a light sy=
mbol schematic with some sort of package definition before generating the n=
etlist to other backends.<br>This package definition would define which sym=
bols and how many slots for each symbol, pin names, not connected pins... f=
or example. <br>If we want to go further, voltage range, thresholds and cur=
rent for each pin, but that's another issue.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><d=
iv><span class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">As all tests are configurable, =
this could be added as an additional test, and let the users enable/disable=
tests according their needs.</div></div></div></blockquote><div><br></div>=
</span>Personally, I prefer a collection of simple programs to a more compl=
icated configurable program. I=E2=80=99m very much a disciple of Brian Kern=
ighan and Rob Pike (see=C2=A0<a href=3D"http://harmful.cat-v.org/cat-v/unix=
_prog_design.pdf" target=3D"_blank">http://harmful.cat-v.org/cat-v/unix_pro=
g_design.pdf</a>). But there=E2=80=99s no reason we can=E2=80=99t have both=
.</div><div><span class=3D""><br></span></div></div></blockquote><div>That&=
#39;s what I meant when I told "making drc2 call your backend". I=
f we have such "collection of simple programs", drc2 can call the=
m. That way users only have to worry about running drc2 and configure which=
tests they want to do.<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><span>
><br>
> One of your fears is that some change in the code break some backend.<=
br>
<br>
</span>That=E2=80=99s part of it. But I also fear that making the core code=
more rigid and use case oriented may paralyze future development. To be us=
e case oriented is OK for something optional like drc2, but it=E2=80=99s no=
t OK for the core code.<br>
<span><br>
>=C2=A0 You know there are regression tests trying to avoid this.<br>
<br>
</span>Yes, I know. It's good to have tests. However, they can=E2=80=99=
t check users=E2=80=99 private scripts. I=E2=80=99m not the only one who ha=
s them. They can=E2=80=99t check every diagram and crazy symbol in use. Peo=
ple do all kinds of things with geda-gaf, even plumbing networks! Nobody fu=
lly understands the breadth of geda-gaf=E2=80=99s application space. We sho=
uld therefore be very, very cautious about changing core code. Why not put =
the effort into new tools and scripts?<span><br></span></blockquote><div><b=
r>That's a pretty well know concern. There is no need to worry about ot=
her unpublished backends.<br>You
already dig into this in another mail. What we need is a good test=20
suite for the gnetlist API, in order to be sure any change to the core=20
doesn't change gnetlist's behaviour. <br><div>If the API is not cha=
nged, there is no chance to break other backends.<br></div></div></div></di=
v></div></blockquote><div><br></div></span>Except for ambiguous cases. Thos=
e are tough. When Bas Gieltjes and I proposed a solution to the "attri=
bute censorship=E2=80=9D bug, Patrick Bernaud and Peter Brett insisted that=
not only should the API stay the same, but it should reproduce the ambiguo=
us (but deterministic) behavior of the old API unless the user reconfigured=
it with a plugin. Thus, the bug wasn=E2=80=99t fixed. In that case, I foun=
d myself on the side of change rather than stability, but, of course, I can=
see the other side too.</div></div></blockquote><div><br></div><div>We are=
not talking about changing the API, but checking it has not changed after =
a modification. <br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div style=3D"word-wrap:break-word"><div><span class=3D""><blockquote type=
=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><div><div><br>You
have enligthened us with some backends nobody could even think about.
I'm pretty sure you know pretty well how to use the API. Why not start=
writing an API test backend/suite?<br></div></div></div></div></div></bloc=
kquote><div><br></div></span>I will consider it. I am, however, more enthus=
iastic about writing new tools than enabling changes to old ones.</div><spa=
n class=3D""></span><br></div></blockquote></div><br></div><div class=3D"gm=
ail_extra">An API checking backend is a new tool! ;)<br><br></div><div clas=
s=3D"gmail_extra">Regards,<br><br></div><div class=3D"gmail_extra">Carlos<b=
r></div></div>
--089e01495336d6a4370522c16723--
- Raw text -