Hi Stuart, On Sep 20, 2007, at 4:58 AM, 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. I've seen this bug also. > > 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. Perhaps mathematically, but to me it seems like yet another weird property to add to the already inscrutable pinseq attribute. > 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. > > 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? > > 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. I think the correct fix is to retire pinseq as the sequencing mechanism for output, and instead use it consistently the way that the board netlisters use it. Have a spice-slotdef attribute similar to the slotdef attribute. Sequence the Spice pins from those numbers. I feel this would be less confusing: instead of pinseq driving two different mechanisms, it would consistently be one of the indices of a slotdef matrix, the other being the slot, of course. This can be backward compatible: fall back on pinseq if no spice-slotdef attribute is available (but please, only for unslotted components). This could also be of use to fans of heavy symbols: you could have a number of *-slotdef attributes, with * representing the footprint. Change the footprint, automagically fix the pin numbers. When netlisting for spice, force all footprints to "spice". That also would be a sensible footprint for a simulation-only symbol. Perhaps the board netlisters could ignore things with that footprint... John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
