When processing circuit input that contains subcircuits, WRspice will perform ``subcircuit expansion'' whereby subcircuit calls are replaced recursively with the subcircuit body text, with the device and node names translated so as to make them unique in the overall circuit. This ``flat'' representation, which can be seen with the listing e command, is the form that is actually parsed to generate the internal circuit structure used in simulation.
Although this occurs ``behind the scenes'', if a user needs to reference nodes or devices within subcircuits, for example in a print or plot command after analysis, the user will need to know the details of the name mapping employed. The same applies when the user is preparing SPICE input, if, for example, the user wishes to use the .save keyword with a subcircuit node. In this case, the SPICE deck will fail to work as intended unless the mapping algorithm assumed by the user is actually employed by the simulator.
WRspice releases prior to 3.2.15 used the SPICE3 algorithm for generating the new node and device names. Subsequent releases have a new, simpler algorithm as the default, but support for the old algorithm is retained. The field separation character, used when creating new names, has changed twice in WRspice evolution. Thus, there is a potential compatibility issue with legacy WRspice input files that explicitly reference subcircuit nodes, and newer WRspice releases.
There are two variables which set the subcircuit mapping mode and concatenation character.
In release 3.2.15 and later the default is `.' (period), which is also used in HSPICE, and provides nice-looking listings.
In releases 3.2.5 - 3.2.14, the default was `_' (underscore).
In release 3.2.4 and earlier, and in SPICE3, the concatenation character was `:' (colon).
The format of the subcircuit node names depends on the algorithm, so SPICE input that explicitly references subcircuit node names implicitly assuming a certain mapping algorithm will require either changes to the node names, or specification of the matching algorithm and concatenation character.
These variables can be set from a .options line in SPICE input, so that the easiest way to ``fix'' an old file is to add a .options line.
For example, suppose that you run an old deck, and get warnings like ``no such vector 0:67''. From the descriptions below, one can recognize that 1) the SPICE3 mode is being used, which will always be true for old decks, and 2) the concatenation character is `:'. Thus, adding the following line to the file will fix the problem.
.options subc_catchar=: subc_catmode=spice3
When running from Xic, there should not be compatibility issues, as Xic will automatically recognize the capabilities of the connected WRspice and compensate accordingly - as long as the hypertext facility is used to define node names. This is true when point-and-click is used to generate node names. However, subcircuit node names that for some reason were entered by hand will need to be updated, or a .options line added as a spice-text label.