gEDA-dev: Broken slotting
Peter Clifton
pcjc2 at cam.ac.uk
Tue Sep 11 08:07:45 EDT 2007
On Tue, 2007-09-11 at 07:58 -0400, Stuart Brorson wrote:
> Peter --
>
> As the author of the offending code, let me say "thank you" for
> cleaning it up.
>
> My memory is faulty, but IIRC, the code was crafted to fix a bug
> having to do with spice-sdb's (actually gnetlist's) handling of
> slotted parts. The problem was that gnetlist originally couldn't deal
> with generating pinseqs for slotted parts because it only iterated
> over the first slot. Or something like that. The issue is that
> spice-sdb uses the pinseq attribute to know which pin to emit while
> generating SPICE netlists.
>
> Therefore, when you're done hacking, please rerun the test suite
> located under gnetlist/tests/spice-sdb. There are some regression
> tests specifically in there which verify that spice-sdb emits the
> correct pins for a slotted part.
>
> If you want me to do anything more -- like clean up any mess I made --
> please let me know!
I should be able to write a fix over the next day or so.
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.
I'll fix the malloc and alter the code which finds a pin with a
particular "pinseq=..." to wrap around at the number of pins on the
device. I will have to check before hand that won't mess up any other
users of the existing API - which might rely on finding the exact pinseq
attribute.
Peter
More information about the geda-dev
mailing list