gEDA-dev: [Fwd: Re: Slotting problems redux]

[Peter Clifton]

And now my original email I meant to forward!

-------- Forwarded Message --------
From: Peter Clifton <pcjc2 at cam.ac.uk>
To: Stuart Brorson <sdb at cloud9.net>
Subject: Re: Slotting problems redux
Date: Thu, 20 Sep 2007 13:02:35 +0100

On Thu, 2007-09-20 at 06:58 -0400, Stuart Brorson wrote:
> Peter --
> 
> We had a discussion about the slotting issue last night while hanging
> out with the Free Doggers.  We agreed that we'd try to figure out
> exactly what bug you were seeing, and try to figure out exactly what
> problem my original pinseq patch was creating.  And then we'd fix it,
> of course.
> 
> I went back and reviewed your original post about this on geda-dev.
> I'm trying to understand precisely what has gone wrong.  Please 
> forgive my slowness.  You say:
> 
> > If you have a slotted component, it is possible to set a slot=n
> > attribute - and the component's pin numbers update.
> 
> > If I have said component with slot=1, and I change to slot=n (n != 1), 
> > I
> > see a pin number update. Once I have slot=n (n !=1), no further
> > updates
> > to the slot= attribute have any effect on the pin numbers.
> > 
> > The log window ends up with many:
> >
> > component missing pinseq= attribute
> 
> So the bug is that if you change slots on a part from, say 3 to 2,
> then the pin numbers drawn on the symbol don't update, right?

Yes, that's correct. A component with slot!=1 has the "wrong" pinseq to
find which pins to update pinnumber on. (It expects to key onto pinseq =
1 to no_pins).

> Next you say:
> 
> > The pinnumber replacement (and the whole slot update) is keyed on the
> > pinseq numbers, however this patch causes them to be re-written for
> > different lots. e.g:
> >
> > inverter with pinseq=1 and pinseq=2 for slot=1
> >
> > becomes
> >
> > pinseq=3 and pinseq=4 for slot=2
> > pinseq=5 and pinseq=6 for slot=3
> 
> The answer is: yes, this is the intended behavior of my patch.  The
> idea is that spice-sdb gets the netnames attached to pins by using
> "get-pin-attribute-by-pinseq", or some similar function, and it needs
> some way to specify not only which pin, but also which slot.
> THerefore, accessing slotted parts' pins via modulo arithmetic seemed
> like a straightforward way to do it.  As part of implementing this, I
> wrote the pinseq info back into each OBJECT since previously for slots
> 2, 3, 4.... no pinseq info was ever stored on the OBJECT, which seemed
> like an oversight.

I'm not sure if this it true - it did seem to have pinseq attributes,
presumably "inside" the symbol, on its pins.

>From memory, get-pin-attribute-by-pinseq also takes a refdes which it
uses to find the component in the first place.

I wounder if we shouldn't have mangled each slot's refdes to make it
unique at this stage - so we can just call get-pin-attribute-by-pinseq
with a unique refdes (for that slot), and a non-shifted pinseq.

As I understood the underlying problem, it's identifying all slots of a
component uniquely when they all have the same name, e.g. IC1.

> The question here is:  Does this cause any breakage of netlisters?  Or
> is it just unexpected behavior to you as you work on the code?

I've not seen any breakage from netlisters, but I've not used much other
than the PCB one and spice-sdb. (Not with slots though). The breakage
I've seen is UI breakage, but a save and re-load "cures" the problem on
the schematic page.

> Next, if the problem is that changing slots from 3 -> 2 doesn't update
> the pin numbers, then isn't the fix to locate the code which handles
> slot updates, and then figure out what's wrong there?  I could be
> wrong, of course, but it seems to me that the thing to do is make the
> slot update code understand the modulo scheme for handling pinseq
> attributes.

That was the solution I first proposed, but it wasn't clear that a more
appropriate / concise solution would be not re-writing pinseq in the
first place. I'm fairly agnostic about the whole thing. The main issue
is: does it upset any other net listers to have the pinseq on a slot
block-shifted by a multiple of its pin count. Short answer - I don't
know.

> If you agree, then I can move forward to see what type of fix to
> implement.

I was working on a fix although time has got the better of me at the
moment. Did you see my post about the using name-mangling to uniquely
identify (or combine) components? I spent more time looking at its
possible benefits in that email.

Regards,

-- 
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!)