On Sep 20, 2007, at 8:15 AM, Peter Clifton wrote: > > 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).
A lot depends on whether we want PC-able schematics to also be simulatable. The requirements are different, so you need different attributes on your symbols. If the answer is "no", then slotting isn't needed at all for simulation schematics. If the answer is "yes", there are more problems to solve: Spice-sdb uses the device attribute to drive its refdes mangler, while PC netlisting practice is to put the part number in there. Incompatible. Simulation schematics contain additional components: parasitics, probes, loads, stimuli, simulator commands, etc. Some can simply be removed for the PC netlist. But series parasitics need to be replaced by shorts. And I'm sure that for clarity, designers don't want to see this stuff in production schematics, so automatic removal from the graphics would be nice (including, of course, removal of net segments and ground symbols that are only there to connect the simulation junk). There are probably more issues I haven't thought of yet. As a user, I'd love to be able to simulate my production schematics: right now, I have to be careful that the separate simulation and production schematics match up. But to change gEDA to make this really practical isn't trivial, and will require some serious thought. 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
