next up previous contents index
Next: .ends Line Up: .subckt Line Previous: wrspice Mode   Contents   Index

spice3 Mode

The SPICE3 encoding is a bit more obscure. Suppose that we have the same example hierarchy as above. The line maps to

C.adder.gate.126 adder.gate.2 adder.gate.4 50fF

Again, this assumes `.' as the concatenation character, which is a bad choice for this mapping mode as we shall see. The spice3 mode was historically used with `:' or `_' as the concatenation character.

For device names, we start with the first character, add a concatenation character, then the top instance name with the `X' stripped and continue down the hierarchy. Finally, we add a concatenation character and the remainder of the original device name.

For nodes, we start with the top-level instance name with the `X' stripped, walk down the hierarchy adding contenation characters and sub-instance names (also with the `X' stripped), and finally append a concatenation character and the original node name.

For models defined in subcircuits, in the example above, the mapping is

.model adder.gate.foo nmos(...)

What if instead of Xgate and Xadder, the instance names were X0 and X1? The expansion becomes

C.1.0.126 1.0.2 1.0.4 50fF

This is very cumbersome to keep straight. Worse, if the hierarchy is only one-deep, we could get node names like ``0.1'', ``1.2'', etc. which are in some cases impossible for the parser to distinguish from a floating point value. Using a different concatenation character solves this problem, but the names are still rather opaque.


next up previous contents index
Next: .ends Line Up: .subckt Line Previous: wrspice Mode   Contents   Index
Stephen R. Whiteley 2017-10-02