gEDA-dev: Broken slotting
Peter Clifton
pcjc2 at cam.ac.uk
Wed Sep 12 05:01:09 EDT 2007
On Tue, 2007-09-11 at 22:52 -0400, Ales Hvezda wrote:
> > Thanks for confirming the desired behaviour. I was (and still am) a
> > little concerned about not having any "contractual" guarantee that every
> > symbol will have pinseq attributes start at "1" and end at the number of
> > pins on the device. Perhaps this is implied though, by the nature of the
>
> > slotdef attribute.
>
> From: http://geda.seul.org/wiki/geda:master_attributes_list#pinseq
>
> ...
> pinseq
>
> This attribute is used to give each pin an unique number or sequence. All pins
> must have a pinseq=# attribute attached to the pin object. This attribute
> should be hidden. This attribute is used extensively by gschem and gnetlist.
> In some backends (especially the SPICE backend), gnetlist will output pins in
> the order of increasing pin sequence. The sequence numbers start at 1 and
> should increase without skipping any numbers. This attribute is not the pin
> number (i.e. device pin numbers, like GND is 7 on TTL). For pin numbers see
> the pinnumber attribute.
> Examples: pinseq=1 pinseq=2 pinseq=3
>
> This attribute replaces the obsolete pin#=# attribute.
> ...
>
> Random question, obviously this slipped by me, but there is code that is
> changing the pinseq= number on the fly? That doesn't seem right to me.
> I always assumed pinseq= would stay constant.
>
> -Ales
Yes, the commit which broke the slot updating does that. It re-assigns
pinseq for a slotted component to be (slot-1) * num_pins higher up - so
the pinseq don't clash when you combine all the slots of one part.
This is never saved out as far as I can tel, just updated in memory when
considering the slots.
--
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!)
More information about the geda-dev
mailing list