Mail Archives: geda-user/2015/10/22/20:57:48
--Apple-Mail=_E6231BA6-0B65-4338-9A55-5D5E9CAF260C
Content-Type: multipart/alternative;
boundary="Apple-Mail=_4D9C0D54-1F97-4933-92A1-274EA66793FD"
--Apple-Mail=_4D9C0D54-1F97-4933-92A1-274EA66793FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Oct 22, 2015, at 3:48 PM, Carlos Nieves (cnieves DOT mail AT gmail DOT com) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>=20
> 2015-10-22 2:01 GMT+02:00 John Doty <jpd AT noqsi DOT com>:
>=20
> On Oct 21, 2015, at 3:55 PM, Carlos Nieves (cnieves DOT mail AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
> > You know drc2 needs you to fill in some info in order to do the job =
correctly. Do you?
>=20
> Yes. But it doesn=92t understand split symbols, especially slotted =
symbols together with unslotted symbols for a single package. It assumes =
hidden pins all have pintype=3Dpwr. It doesn=92t understand that =
backplane connectors don=92t connect every signal on the backplane to =
every board.
>=20
> Yes, it doesn't. There is (a huge) room for improvement.
> For unconnected pins there is the NoConnection directive. I cant =
remember for hidden pins...
>=20
>=20
> > I agree drc2 could be better, but something is better than nothing.
>=20
> I agree, and I=92ve used it successfully for years. Thank you. It is =
*a lot* better than nothing. But if you=92re doing mixed-signal design =
using a lot of split symbols, like Kai-Martin=92s slotted+power stuff, =
and a lot of tabular connections through pins2gsch, you are far outside =
drc2=92s model of the application space.
>=20
>=20
> Last modification to drc2 was in 2006... It seems that is no so =
annoying. Otherwise someone would have fixed that. ;)
Along with DJ, I fear that many don=92t 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 =
row < column.
>=20
> Reading the designer's mind is impossible for any tool. drc2 checks, =
other 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.
>=20
> 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 =
additional test? :)
>=20
> > You are fluent in scheme. Why don't you help to improve it instead =
of complaining about it every time?
>=20
> 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=92m not smart enough to avoid breaking other people=92s=
applications: one man=92s bug is another man=92s feature. I=92m sure =
drc2=92s model of schematic design fits some folk=92s flows fine. It =
just doesn=92t fit mine terribly well. By writing something new I get to =
serve my interests without harming anybody else=92s.
>=20
>=20
> Regarding breaking any other flow, please see below.
>=20
> 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=92s 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.
Using a bottom-up approach, it doesn=92t determine a top-down reason for =
the duplicate. It could be a duplicate slot, duplicate refdes, faulty =
symbol, or maybe something I haven=92t though of. I don=92t expect that =
users will have too much trouble here, although that is a general =
weakness of the bottom-up approach. Of course, the fact that it=92s =
sensitive to effects rather than causes means that I don=92t have the =
burden of figuring out every possible cause.
I=92m thinking about a bottom-up approach to detecting missing slot =
assignments and missing parts of split symbols. The 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 library 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 =
number are present.
> 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 =
complicated configurable program. I=92m very much a disciple of Brian =
Kernighan and Rob Pike (see =
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf). But there=92s no =
reason we can=92t have both.
>=20
> >
> > One of your fears is that some change in the code break some =
backend.
>=20
> That=92s part of it. But I also fear that making the core code more =
rigid and use case oriented may paralyze future development. To be use =
case oriented is OK for something optional like drc2, but it=92s not OK =
for the core code.
>=20
> > You know there are regression tests trying to avoid this.
>=20
> Yes, I know. It's good to have tests. However, they can=92t check =
users=92 private scripts. I=92m not the only one who has them. They =
can=92t 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 of geda-gaf=92s application space. We should =
therefore be very, very cautious about changing core code. Why not put =
the effort into new tools and scripts?
>=20
> 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=94 bug, Patrick Bernaud =
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 API unless the user reconfigured it with a plugin. Thus, the bug =
wasn=92t 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.
>=20
> 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.
>=20
> Regards,
>=20
> Carlos
>=20
>=20
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_4D9C0D54-1F97-4933-92A1-274EA66793FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Oct 22, 2015, at 3:48 PM, Carlos =
Nieves (<a =
href=3D"mailto:cnieves DOT mail AT gmail DOT com">cnieves DOT mail AT gmail DOT com</a>) [via =
<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">2015-10-22 2:01 GMT+02:00 John Doty <span =
dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT com</a>></span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><span class=3D""><br>
On Oct 21, 2015, at 3:55 PM, Carlos Nieves (<a =
href=3D"mailto:cnieves DOT mail AT gmail DOT com">cnieves DOT mail AT gmail DOT com</a>) [via =
<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:<br>
<br>
> You know drc2 needs you to fill in some info in order to do the job =
correctly. Do you?<br>
<br>
</span>Yes. But it doesn=92t understand split symbols, especially =
slotted symbols together with unslotted symbols for a single package. It =
assumes hidden pins all have pintype=3Dpwr. It doesn=92t understand that =
backplane connectors don=92t connect every signal on the backplane to =
every board.<span =
class=3D""><br></span></blockquote><div><br></div><div>Yes, it doesn't. =
There is (a huge) room for improvement. <br></div><div>For unconnected =
pins there is the NoConnection directive. I cant remember for hidden =
pins...<br><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"><span class=3D""><br>
> I agree drc2 could be better, but something is better than =
nothing.<br>
<br>
</span>I agree, and I=92ve used it successfully for years. Thank you. It =
is *a lot* better than nothing. But if you=92re doing mixed-signal =
design using a lot of split symbols, like Kai-Martin=92s slotted+power =
stuff, and a lot of tabular connections through pins2gsch, you are far =
outside drc2=92s model of the application space.<br>
<span class=3D""><br></span></blockquote><div><br>Last modification to =
drc2 was in 2006... It seems that is no so annoying. Otherwise someone =
would have fixed that. =
;)<br></div></div></div></div></blockquote><div><br></div>Along with DJ, =
I fear that many don=92t use it. But there have been a couple of fixes =
since:</div><div><br></div><div><div style=3D"margin: 0px; font-size: =
10px; font-family: Monaco;">;; 2010-12-11: Fix stack overflows =
with large designs.</div><div style=3D"margin: 0px; font-size: 10px; =
font-family: Monaco;">;; 2010-10-02: Applied patch from Karl =
Hammar. Do drc-matrix lower triangular</div><div style=3D"margin: 0px; =
font-size: 10px; font-family: Monaco;">;; =
and let get-drc-matrixelement =
swap row/column if row < =
column.</div><div><br></div></div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br>Reading the designer's mind is impossible =
for any tool. drc2 checks, other than duplicated refdes/slots, can be =
mainly used for digital design but hardly help for mixed =
signal.<br></div></div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><div>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 additional test? =
:)<br> <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"><span class=3D"">
> 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=92m not smart enough to avoid breaking other people=92s=
applications: one man=92s bug is another man=92s feature. I=92m sure =
drc2=92s model of schematic design fits some folk=92s flows fine. It =
just doesn=92t fit mine terribly well. By writing something new I get to =
serve my interests without harming anybody else=92s.<br>
<span =
class=3D""><br></span></blockquote><div><br></div><div><div>Regarding =
breaking any other flow, please see below.<br></div><div><br></div>I'm =
ok with that. 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>The whole =
thing=92s only five small functions. Only the top level <span =
style=3D"font-family: Monaco; font-size: =
10px;">(check-duplicates) </span>has any side effects, so the =
others should not have any compatibility issues with your =
code. <span style=3D"font-family: Monaco; font-size: =
10px;">(check-duplicates) </span>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 <span =
style=3D"font-family: Monaco; font-size: 10px;">(find-duplicates =
(every-connection)) </span>and write the resulting list to the =
output file, suitably formatted. </div><div><br></div><div>Using a =
bottom-up approach, it doesn=92t determine a top-down reason for the =
duplicate. It could be a duplicate slot, duplicate refdes, faulty =
symbol, or maybe something I haven=92t though of. I don=92t expect that =
users will have too much trouble here, although that is a general =
weakness of the bottom-up approach. Of course, the fact that it=92s =
sensitive to effects rather than causes means that I don=92t have the =
burden of figuring out every possible =
cause.</div><div><br></div><div>I=92m thinking about a bottom-up =
approach to detecting missing slot assignments and missing parts of =
split symbols. The 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 library 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 number are =
present.</div><div><br></div><div><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>Personally, I prefer =
a collection of simple programs to a more complicated configurable =
program. I=92m very much a disciple of Brian Kernighan and Rob Pike =
(see <a =
href=3D"http://harmful.cat-v.org/cat-v/unix_prog_design.pdf">http://harmfu=
l.cat-v.org/cat-v/unix_prog_design.pdf</a>). But there=92s no reason we =
can=92t have both.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div> </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"><span class=3D"">
><br>
> One of your fears is that some change in the code break some =
backend.<br>
<br>
</span>That=92s part of it. But I also fear that making the core code =
more rigid and use case oriented may paralyze future development. To be =
use case oriented is OK for something optional like drc2, but it=92s not =
OK for the core code.<br>
<span class=3D""><br>
> 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=92t check =
users=92 private scripts. I=92m not the only one who has them. They =
can=92t 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 of geda-gaf=92s application space. We should =
therefore be very, very cautious about changing core code. Why not put =
the effort into new tools and scripts?<span =
class=3D""><br></span></blockquote><div><br>That's a pretty well know =
concern. There is no need to worry about other 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 changed, =
there is no chance to break other =
backends.<br></div></div></div></div></div></blockquote><div><br></div>Exc=
ept for ambiguous cases. Those are tough. When Bas Gieltjes and I =
proposed a solution to the "attribute censorship=94 bug, Patrick Bernaud =
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 API unless the user reconfigured it with a plugin. Thus, the bug =
wasn=92t 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.</div><div><br></div><div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><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></blockquote><div><br></di=
v>I will consider it. I am, however, more enthusiastic about writing new =
tools than enabling changes to old ones.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><div><br></div><div>Regards,<br><br></div><div>=
Carlos<br></div> <br></div></div><br></div></div>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">John =
Doty<span class=3D"Apple-converted-space"> =
<span class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_4D9C0D54-1F97-4933-92A1-274EA66793FD--
--Apple-Mail=_E6231BA6-0B65-4338-9A55-5D5E9CAF260C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWKYX7AAoJEF1Aj/0UKykRhOQP/2IsKqsb0z7khLs87AIAXzPI
S1No0py9sQ58OZrU3snP6+bdvFgN3q0itZzVUXb3i4Ew6jhlM03zf3Ken92R+yyq
dFj2pihv5AluiOjQ6mnCg6dEm/KAC4NlhMRKfIW2BPklC9uqhNYnbOacoNAGW/cL
nC68ggpzBPWDPw/UD9OsMkalvAQJgQfc9BCMwpT1fMKZLNp1yJvmimn2tq7eTvza
qrCNQIiLX3D62aCC87lDkMrBwzvEFueHPdQo3vr1lcsc7eL0MYFqPwflnps2RhLb
64v8Rq1Cf5L5kxdRhZfMxSoLfCjrEiDDjChzy/Zn7yxFfBfDRHZARwhyyHnqOsB9
dyZZ1SxBF74mpt/O3OlhN0TtYM41+uHZfF5x8I6xc4fG3VHvctyywy7s127yWEpY
WHFsIuXP3fN++FJwJLY587A17qNTJVq3Ltonybn9evS3257oKsaiMftVOeSGMOMf
TYzd0nUzkmAS/YIL402UJt3oJExrf2lVIeTREb7w8dOzpupvEZzrT5igo4uQ0wC2
vf51YTq2R9ruBF0gl9AdFAp7n+Fdaq6Mla7vFRvP5LHcTscapg20dpyFYeArxtlB
UYhKVxh3mkeIa1Fi7XLSWJPesUaqx0828dcVoDunfgP85jKBInJxrNN2I6CIfxe2
oFQFK0/2pchMJn8r9Ifs
=vhAp
-----END PGP SIGNATURE-----
--Apple-Mail=_E6231BA6-0B65-4338-9A55-5D5E9CAF260C--
- Raw text -