Mail Archives: geda-user/2015/10/19/19:41:03
> > My sample schematic would have U1-1 and U1-1.
>
> So you don't really have a refdes to start from: it doesn't identify
> the component.
Wordplay. It has a refdes. It's not unique. We do this all the time
for slotted and multi-sym parts.
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.
> You also wrote:
>
> > If the tool *requires* that each symbol be unique, then either...
> >
> > 1. It must not let the user provide non-unique symbols, or
> >
> > 2. It must produce a hard error when it detects non-unique symbols, or
> >
> > 3. It must provide some user-independent way of making the symbols unique.
> >
> > gaf currently does none of these.
>
> But that's not how geda-gaf works.
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. 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.
> Choosing refdeses is part of how the user communicates her intentions.
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?
> 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.
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.
> You also wrote:
>
> > 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.
>
> How is it hard for a user to understand that symbols need to be
> distinguishable at the schematic level?
From 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? 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).
> 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.
It's the next step that's hard - producing as-built schematics.
- Raw text -