[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: More on gschem, gnetlist, pots, and spice



Hi --

Well, I have thought deeply about the issue of netlisting
potentiometers using spice-sdb.  Unfortunately, it is not as
straightforward as one would like.    

The problem with potentiometers is that they are *three* terminal
devices: two ends of the resistor, and the center tap.  SPICE
resistors are *by definition* only two terminal devices.  Asd far 
as I know, SPICE itself doesn't have the concept of a pot -- 
a pot is just not a SPICE device.  Therefore, to incorporate 
pots into a spice netlister (like spice-sdb), one has at least 
two options:

1.  The netlister can break the pot into two series resistors, with
    the center tap being the node connecting the two series
    resistors.  On the surface, this seems like a good idea, because
    it gives the user what he wants.  However, it raises all kinds of
    questions:

    *  What splitting ratio should be used for the two resistors?
       (That is, if you have a 10K pot, how do you split the 10K
       between the top and bottom resistors?)  Just arbitrarily
       setting a 50/50 splitting ratio is one possiblity, but does the
       user expect this?  And why not 0/100?  Or any other value?  And 
       shouldn't the splitting ratio be configurable?

    *  How to annotate the splitting ratio into the schematic?  And what
       if it is configurable -- how to deal with it?  The obvious
       way is with a "splitting-ratio" attribute, but we've just added
       yet another attribute to the already long list of component
       attributes, and the user might not know about it, which 
       raises the issue of what it should default to . . . . .

    *  How about the refdes of the two resistors?  The netlister 
       could just give them names like R1:upper and R1:lower, so 
       it's not a big deal.  But if an error occurs during SPICE
       simulation, then the user may get an error talking about
       a refdes he has never heard of.  OK, OK  -- this is a 
       minor point.

2.  Just not do it, and force the user to use two resistors (e.g. in a
    .SUBCKT) if he wants to simulate a pot.  On one hand, this may
    seem arbitrary and non-user-friendly.  On the other hand, this has
    the benefit of non-ambiguity.  That is, the resulting netlist
    gives the user *exactly* what he has drawn in the schematic.

    With this approach, if the user really wants to use a pot in his
    schematic, he can create a .SUBCKT symbol with the two resistors,
    and incorporate that into his schematic.  The user can then attach
    a "footprint" attribute to the top level symbol so that he can
    create a layout using his schematic.


Of course, the advantage of having the pot SPICE netlistable is that
you can both SPICE-simulate and lay out the same schematic.  However,
given the above considerations, I am currently tending towards the
opinion that one should *not* make pots SPICE netlistable.  There are
plenty of other components which you can't use in SPICE -- or require a
.SUBCKT to model -- such as connectors, pushbuttons, sensors, etc.
Therefore, there is president for excluding pots from the netlister.

Therefore, I propose to *not* include pots into spice-sdb.  However, if
somebody has a smart proposal about how to handle my above issues --
and in particular has an idea about how to logically and consistently
handle the problem of setting the pot's splitting ratio -- I am very
willing to reconsider, and implement the change. 

I'd also be interested in hearing about how pots are handled in commercial
schematic capture/simulation packages, like MicroSim/Orcad, Electronics
Workbench, etc.  I don't have one of them handy right now, so I don't know
how they behave.

Finally, if we *do* decide to disallow pots from spice-sdb, I will put a
check into the dispatcher to detect VARIABLE_RESISTOR device
attributes, and issue an explicit error about this device.  The
current error you get it just the generic "I don't know what this part
is" error. 

Stuart