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

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:

2015-10-22 2:01 GMT+02:00 John Doty <jpd AT noqsi DOT com>:

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:

> You know drc2 needs you to fill in some info in order to do the job = correctly. Do you?

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.

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...

> I agree drc2 could be better, but something is better than = nothing.

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.

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.

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.

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? = :)

> 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 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.

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=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://harmfu= l.cat-v.org/cat-v/unix_prog_design.pdf). But there=92s no reason we = can=92t have both.

>
> One of your fears is that some change in the code break some = backend.

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.

> You know there are regression tests trying to avoid this.

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?

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=20 suite for the gnetlist API, in order to be sure any change to the core=20= doesn't change gnetlist's behaviour.
If the API is not changed, = there is no chance to break other = backends.

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.

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.

Regards,

= Carlos

John = Doty = Noqsi = Aerospace, Ltd.

http://www.noqsi.com/

jpd AT noqsi DOT com

= --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--