X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 207.224.51.38
X-Authenticated-UID: jpd AT noqsi DOT com
Content-Type: multipart/signed; boundary="Apple-Mail=_1AA5568A-9BA0-4C0E-BBF7-FB64DA34A621"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] Pin mapping (separate symbols from mappings)
X-Pgp-Agent: GPGMail 2.5.2
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <201510192340.t9JNeo6n020302@envy.delorie.com>
Date: Mon, 19 Oct 2015 19:41:33 -0600
Message-Id: <D892D347-2B31-4063-9A02-0D54B358070D@noqsi.com>
References: <20151018204010 DOT 9cce6a231dcc296256e187bd AT gmail DOT com> <201510181843 DOT t9IIhmWo025346 AT envy DOT delorie DOT com> <20151018234424 DOT c0551dad9bef0859130239d9 AT gmail DOT com> <36B94694-F2AC-4A75-A8EB-40A1CE9A534C AT noqsi DOT com> <201510182225 DOT t9IMPkxK032763 AT envy DOT delorie DOT com> <20151019003814 DOT f62620bf0fec77e65104c105 AT gmail DOT com> <BED51F9A-F6FF-4A23-B18B-C2EC8BB9DAB6 AT noqsi DOT com> <201510190242 DOT t9J2gl7w009345 AT envy DOT delorie DOT com> <20151019092555 DOT 46eed4540c2d2044bbeab878 AT gmail DOT com> <1A419AED-FCCA-4B1F-8589-912435534E2E AT noqsi DOT com> <201510191647 DOT t9JGlu4j024585 AT envy DOT delorie DOT com> <041FF42A-691F-4E6B-9DEB-8C6B3C2F3E53 AT noqsi DOT com> <201510191850 DOT t9JIop8Y029095 AT envy DOT delorie DOT com> <A5C4636C-6064-4D9C-9F55-03185FE35379 AT noqsi DOT com> <201510192055 DOT t9JKt2o6005861 AT envy DOT delorie DOT com> <1E816300-E31E-4B85-B51D-7EAEC5A466BF AT noqsi DOT com> <201510192110 DOT t9JLAFKG007281 AT envy DOT delorie DOT com> <AAAC7015-AF0E-41BE-83F0-C64862CF2670 AT noqsi DOT com> <201510192340 DOT t9JNeo6n020302 AT envy DOT delorie DOT com>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


--Apple-Mail=_1AA5568A-9BA0-4C0E-BBF7-FB64DA34A621
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 19, 2015, at 5:40 PM, DJ Delorie <dj AT delorie DOT com> wrote:

>=20
>>> My sample schematic would have U1-1 and U1-1.
>>=20
>> So you don't really have a refdes to start from: it doesn't identify
>> the component.
>=20
> Wordplay.  It has a refdes.  It's not unique.  We do this all the time
> for slotted and multi-sym parts.
>=20
> And that reference was to show how easy it is for a user to
> instantiate symbols that don't have a unique identity, a problem you
> still haven't addressed.

It=92s easy to do all kinds of dysfunctional things with a power tool. =
To reliably prevent dysfunction, you have to take away the power.

>=20
>> You also wrote:
>>=20
>>> If the tool *requires* that each symbol be unique, then either...
>>>=20
>>> 1. It must not let the user provide non-unique symbols, or
>>>=20
>>> 2. It must produce a hard error when it detects non-unique symbols, =
or
>>>=20
>>> 3. It must provide some user-independent way of making the symbols =
unique.
>>>=20
>>> gaf currently does none of these.
>>=20
>> But that's not how geda-gaf works.
>=20
> That's *exactly* how geda-gaf doesn't work.  It allows the user to
> make invalid schematics and doesn't complain when it can't figure out
> what to do.

Gnet-drc2 complains *too much*. But I=92d much, much, rather have a tool =
that stupidly tries to do what I tell it to do, than a tool that gets in =
my way by trying to save me from my stupidity. My stupidity is my =
problem, not the tool=92s problem.

>  Given that one of those three conditions must be met to
> avoid errors (unless there is a fourth way to avoid errors, which you
> haven't mentioned), then the geda-gaf problem is that it doesn't avoid
> errors.  This normally isn't a problem when we make the user
> responsible for the results, but if we want to add something that
> needs uniqueness, we can't rely on the user any more.

There are, in fact, decent ways to detect a duplicate refdes. =
Gnet-spice-noqsi can. Gnet-drc2 can too, but it=92s deaf to the signs =
that it=92s OK. So, a gnetlist plugin to implement your mapping could =
figure this out. You=92re trying to design this without an understanding =
of the gnetlist API.

>=20
>> Choosing refdeses is part of how the user communicates her =
intentions.
>=20
> And the current problem is figuring out how to defer those intentions
> until later in the design process.  Why are you so opposed to letting
> people work the way they want, instead of the fixed way geda-gaf makes
> them work now?

I=92m not. I=92m for *using* the existing capabilities of geda-gaf, =
rather than fighting them.

>=20
>> We could have better DRC: gnet-drc2 does not properly model the
>> capabilities of the kit, finding lots of errors where there are
>> none. The real errors are hidden in the spew, but should be
>> detectable with better logic.
>=20
> Sadly, most people don't run drc2.  If there are errors that cause bad
> results, gnetlist needs to detect those and not fool the user into
> thinking that everything is OK.

But the problem is that drc2 is far too sensitive. I have to fish =
through *hundreds* of false alarms to find the real errors. In the end, =
it=92s worth it, but it sure is annoying. If you forced this on users, =
and had gnetlist refuse to create the netlist, it would be a disaster. =
You say =93we should fix this=94. I say =93we should make it better=94. =
*Nobody* knows how to recognize the difference between a valid set of =
schematics and an invalid set, because in the end that lies in the mind =
of the designer. The software can give advice, but it=92s the designer=92s=
 call.

>=20
>> You also wrote:
>>=20
>>> What I want is a way to reliably map an instance of a device with =
its
>>> schematic symbol, without the user having to jump through hoops to
>>> satisfy some hidden "rule" about how to create schematics.
>>=20
>> How is it hard for a user to understand that symbols need to be
>> distinguishable at the schematic level?
>=20
> =46rom the user's point of view, they're distinguishable.  There's =
this
> one, and that one :-) Why should we force the user to decide
> packaging, slotting, and unique numbering, right at the beginning,
> when they're just tossing a design together?

I don=92t think we should. But I don=92t think it unreasonable to ask =
that the choice of refdes continue to communicate the designer=92s =
intentions.

>  Even as late as layout,
> they could change the packaging and thus change the slotting (for
> example, switching from a quad-nand to two dual-nand packages).

Certainly. And as long as the source schematics are unambiguous, the =
mapping tool should be able to cope.

>=20
>> And that when merging symbols into one package, they'll get the
>> package's refdes and their own pin numbers. I don't think it's that
>> hard.
>=20
> It's the next step that's hard - producing as-built schematics.
>=20

I don=92t think it=92s as hard as you think it is. Just a map =
{U7-1->U6-5, footprint(R6)->0805, =85}. A not terribly sophisticated =
diff of netlist and BOM could create the data. I=92ve done this stuff =
semi-automatically, I should know. It might wind up asking the user to =
draw a little if there are added components or connections.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com



--Apple-Mail=_1AA5568A-9BA0-4C0E-BBF7-FB64DA34A621
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

iQIcBAEBCgAGBQJWJZvOAAoJEF1Aj/0UKykRfLYP/1CzBs+ytZ0ghwqR2DyAPQcR
RykgA33PRD665CxIC9Gp/seiDOdPipb5DMBfeMvClgkJVsWep6q+tEIRjKQhdIRx
ybucXYfGSJcrqrh0aHe/gDHpem1cQ0At8GDWoriwgxz6HNI4rxxnXv5AHK8F6ln3
LzvElca261HP0CALUuO2uev49jZwDVfQnagAmOi8KD85rqsyqx3Q5urcfQ9Ui7A2
FMFoSZN6DR3ppYWAfr4+YsFusa6a6aC6v9Qc3G9m86OA5OIGLhZEqjEtLIRKokIj
uZCjZfXEEl6l6KH0+r4i4vTAmm/n5OA6RgjTb6qBwokda9OJItapEYCliHWMTb1e
WbUDlfP7oU49hE+KP99OC+eowcIIANCcp6amagvHz6OeSH8rorp9u2BTJhBddxQm
zWfKbJWdt6npHNHB/vfxnYN2QOZti76j748A2xNjqBnOE50PBt98yniQ5lbzkeZQ
SMsMoB+81GjTANqX1LtsVUMuls/O17Xu0VGeG9orQIeCto0+o9zBmdpMeVT7s+X0
sXm4/PkWc27kplOeQux6PSO8zdmmS0Es7ba3TP+5xn2ogga4X7FESpN/dCzuE/Mh
OBrAk59ESQrBGkAMVt4+3sV7vrgmmAhgSaXOpy6AXeJqUE2HdAAjKFdWTnuT8G7f
0Iov/V9hp77jjhB7gb6V
=m9w+
-----END PGP SIGNATURE-----

--Apple-Mail=_1AA5568A-9BA0-4C0E-BBF7-FB64DA34A621--