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