Mail Archives: geda-user/2015/10/19/21:41:48
--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--
- Raw text -