On Wed, Oct 1, 2008 at 2:43 AM, Ales Hvezda <[EMAIL PROTECTED]> wrote:
>>Most of the lines are eye candy but the attributes special to the branch are:
>> device: used to determine if a symbol is "compatible" with a part's
>>slot (example, not special case)
>> pinnumber: gets rewritten
>> pinfunction: used as key into function->pin number map
>> slotname, slotowner: determines slot/symbol linkage
>> slotrewrite: names "magic" attribs that get "inherited" from the heavy part
>> slotmap: defines function->pin number map
>
>
> Great, thanks for posting this information. Why did you create
> the various new attributes? I wasn't planning on creating any new
> attributes and the existing slotting mechanism would stay the same
> (for the most part).
I needed the slot* attributes to be able to record the linkages
between slot and symbol. slotowner needs to be unique AND stable so I
just went for a proper UUID (falling back to a more lame PID and
time-based identifier). Granted, this is necessary as a direct result
of splitting the light and heavy bits into distinct components.
I think I invented pinfunction because JPD complained that I'd
otherwise be breaking his flow that depends on pinseq, so I rather
invented a new purpose-specific attribute instead of overloading an
existing one.
pinnumber isn't "new" - it's just that libgeda knows that this is the
attribute to fiddle through the symbolic name -> package pinout map.
device isn't special at all, just an example here of how slots and
symbols are determined to be "compatible": all attributes mentioned in
a slot definition ("S { ... }") must match those in the candidate
symbol. This is so that you can't put an opamp symbol into a 7400.
One day I want to extend the meaning of attributes from key/value
pairs to key/relation/value constraints, which will allow you to put
"hfe>=50" on a transistor symbol and have it be compatible only with
transistor slots that specify "hfe=100" or just "hfe>=70". But for
now the rule is just: ALL attributes that are in both symbol and slot,
must be equal.
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
