On Thu, 2007-09-20 at 07:46 -0600, John Doty wrote:
> 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...
This is interesting, I've yet to fully digest if it has any other
implications than (kindof) requiring heavy symbols. (Although you could
of course add a new slotdef attribute to the schematic on top of a light
symbol).
Looking at the gnetlist test for spice-sdb's slotted components, we see
input (with lots cut out):
C 46500 48100 1 0 0 LM324_slotted-1.sym
{
device=LM324
refdes=U1
slot=1
}
C 46500 46000 1 0 0 LM324_slotted-1.sym
{
device=LM324
refdes=U1
slot=2
}
C 46500 44200 1 0 0 LM324_slotted-1.sym
{
device=LM324
refdes=U1
slot=3
}
C 46500 42100 1 0 0 LM324_slotted-1.sym
{
device=LM324
refdes=U1
slot=4
}
The netlist output expands this to:
U1.1 samenet_output_c minusin_slot1_pin_b plusin_slot1_pin3_a unknown
U1.2 samenet_output_c minusin_slot2_pin6_b plusin_slot2_pin5_a unknown
U1.3 samenet_output_c minusin_slot3_pin_b plusin_slot3_pin10_a unknown
U1.4 samenet_output_c minusin_slot4_pin13_b plusin_slot4_pin12_a unknown
So this is not slotting as we are familiar with for PCB layout. (If that
were the case, we would have a single sub-circuit model named U1 with
all the pins (ports / nodes) connected to it.
My proposal was to allow the gnetlist backends the option of mangling
the refdes name (or uref) inside gnetlist just after elements are
loaded. This would mean U1.1 and U1.2 are found explicitly in the list
of components passed to the spice-sdb backend, and it can use pinseq (if
it wants) to order the nodes for those components.
Presently, spice-sdb would just be passed a "U1", and when this is
looked up, you get the first component it finds (I'm not sure if there
is any sorting).
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!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
