Re: gEDA-user: "Inherited" attributes view in gschem

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2009-05-31 at 10:35 -0600, John Doty wrote:
> On May 31, 2009, at 8:23 AM, Peter Clifton wrote:
> 
> > Hi guys,
> >
> This is a good idea, and should be in the next gschem.

The code is already in git (albeit not the code to mask view of the
overridden attributes within the symbol)

> It does, however, have a downside: it will tend to lead the designer  
> even more easily into the trap of attaching attributes to library  
> symbols in lieu of creating editing project symbols. It's the easy  
> way to start, but when your project grows big, it's a disaster. This  
> redesign really needs to include the "make project symbol" button.
> 
> You wouldn't spread 100 copies of the same structure declaration  
> around a big C application: it would be a maintenance nightmare. So  
> why should spreading 100 copies of the same attribute set around a  
> big design be the only easy, transparent way to define components in  
> gschem?
> 
> >
> >
> > For now, _all_ attributes inside the symbol are shown, including those
> > which are overridden by attached attributes. I have some patches which
> > form an aggregate list - where certain inherited attributes are
> > discarded from the list if they are overridden, however the correct
> > behaviour isn't entirely obvious.
> >
> > Since gEDA allows (and uses) multiple attributes with the same name
> > (net=, source=, slotdef= are some examples which spring to mind), it
> > isn't obvious what the rules for overriding or combining these
> > attributes should be.
> 
> Classify each attribute as "singular" or "plural". Make a rule that  
> "plural" attributes may not be promoted or attached to an instance.

Unfortunately, net= is plural, and it is required to allow overriding
that for power symbols etc. There are existing designs out there
(including my own) which will re-assign a power net by attaching one
"net=5V:14", to a symbol which already has "net=GND:7" and "net=VCC:14".

> For the future, maybe we should have a multiline form for attributes.  
> A singular version of source= might look like:
> 
> source=
> foo.sch
> bar.sch

Actually, "source=filename1.sch,filename2.sch,filename3.sch" is already
supported (by some of gEDA). Unfortunately the code to interpret this
attribute is repeated in various places, and each handles it slightly
differently!

> Then an attached singular source= attribute could override all  
> source= attributes in the symbol.
> 
> net= is a funny case, because it's really singular, one per pinseq.

Isn't it keyed off pinnumber, not pinseq? I was thinking this too, but
the following is also legal:

net=GND:1,5,6

If you overrode with:

net=AGND:1

Then the first attribute is still important (for pins 5 and 6). In these
cases, it is the search order which defines the mapping used.

As far as I could tell, the search order favours the first net=
attribute it finds in the attached attributes, or the LAST net=
attribute from the symbol.

Since people probably don't deliberately add clashing net= attributes, I
suspect the only thing we need to preserve is the preference for
attached attributes.


Given the above case, it became painfully clear that you can't easily
make a merged set of attributes based on including / not including those
from within the symbol.

You would have to leave all net= attributes intact, and ensure the
sort-order of the merged list still favours the priorities required.

Any checking routines to warn about clashing net= attributes would still
have to employ intelligence as to where the attributes came from to
allow attached / inherited overrides for a given pinnumber, but warn
about a clash where the errant attributes both came from the same place.


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user