XSCHEM TUTORIAL: INSTANCE BASED SELECTION OF SYMBOL IMPLEMENTATION

UP

# TUTORIAL: INSTANCE BASED SELECTION OF SYMBOL IMPLEMENTATION

It is quite common to have in a design multiple instances of the same subcircuit. Think for example of memory arrays and decoder circuits. In some cases there are numerous instances of the same identical circuit. This leads to a very large netlist and heavy simulation loads (both in time and space).
On the other hand typically only a small portion of these repetitive circuits are exercised in simulation. For example you might want to simulate the selection only of the first 2 wordlines and the last 2 wordlines in a 1024 wordlines memory array.

In these situations it might be useful to keep the full subcircuit implementation for the circuit parts that are exercised and provide a simplified subcircuit for the parts that are idle during simulation. The simplified parts may just do the 'essential work' like driving the idle value on the outputs and loading the inputs with an equivalent of the input capacitance, in order to not alter the full circuit behavior.

### schematic attribute on instance

Inside a symbol it is possible to specify an alternate `schematic` to descend into. For example if symbol `inv.sym` has attribute `schematic=inv2.sch` then xschem will descend into `inv2.sch` instead of the default `inv.sch`. See symbol_property_syntax man page. However these attributes at symbol level are applied to all instances of that symbol. To enable instance based differentiation it is now possible to use this attribute in the instance.
A `schematic=<schematic reference>` attribute attached to an instance will specify the schematic implementation to be used for that (and only that) instance of the subcircuit.
Example:
`schematic=comp_65nm_parax.sch`

The `comp_65nm_parax.sch` schematic may be something like this, that is a simplified circuit that just keeps a known value on the outputs and adds some parasitic capacitance to the inputs.

### spice_sym_def attribute on instance

A `spice_sym_def=<...text...>` attribute attached to an instance will specify some text that describes the subcircuit (it can be a simplified spice subcircuit netlist or a spice .include line that gets the subcircuit from an external file). This attribute on an instance must always be paired with a matching `schematic` attribute that specifies the subcircuit name the instance is linked to.

Another possibility is to specify these attributes so the actual netlist will be included by the simulator.
`schematic=comp_65nm_pex`
`spice_sym_def=".include /path/to/comp_65nm_pex.cir"`
When a `spice_sym_def` is specified no alternate schematic is used for this instance. The definition is provided as text (a piece of netlist, like for example a parasitic spice netlist extraction).

Putting this all together here is a schematic with 3 instances of `comp_65nm.sym`.

- `x1` is the standard instance using the default `comp_65nm.sch`
- `x2` is a simplified instance that just keeps the output low.
- `x3` uses a parasitic extraction netlist (output will move slower).

See the waveforms of the OUT, OUT2, OUT3 signals that behave accordingly.

### Automatic port order setting from provided subcircuit netlist (Spice netlists only)

If a `spice_sym_def` attribute is defined and has one of the following forms:

    spice_sym_def="
    .subckt opamp PLUS MINUS OUT VCC VSS
    ...
    ...
    ...
    .ends
    "

Or:

    spice_sym_def=".include /path/to/subckt_file"

Xschem will use the port order provided in the subckt line, either by looking directly into the attribute value or by loading the file specified by the .include line. This way there will not be inconsistencies between instance line and subckt definition in the circuit netlist. If for some reason the port list can not be read or pin names do not match xschem will use the port order drom the `.sym` file.

Note: all the above concepts are valid for VHDL, Verilog and tEDAx netlists by replacing the `spice_sym_def` attribute with `vhdl_sym_def`, `verilog_sym_def` and `tedax_sym_def` respectively.

### Instance based SPICE model

In some cases a device is specified by a model and if model parameters can not be set in the instance line we need multiple models if we want to use multiple devices with different model parameters. This can be done by specifying a model in the following way:

    type=mechanical_rotational
    format="@name @pinlist inertia@name
    .model inertia@name inertia_omega_tau J=@J"
    template="name=N1 J=1.1"

Note the model name is given as `inertia@name`, this will make each model instance have a different and unique name. This will generate an instance line:

    N1 A B C inertiaN1
    .model inertiaN1 inertia_omega_tau J=1.4

A better way hat handles also vectored instances is the following:

    type=mechanical_rotational
    format="@name @pinlist #inertia#@name
    .model #inertia#@name inertia_omega_tau J=@J"
    template="name=N1 J=1.1"

This way if you place a vectored instance name=N1[3:0] it will expand in netlist as:

    N1[3] XAA XBB XCC inertiaN1[3]
    N1[2] XAA XX XCC inertiaN1[2]
    N1[1] XAA XX XCC inertiaN1[1]
    N1[0] XAA XX XCC inertiaN1[0]
    .model inertiaN1[3] inertia_omega_tau J=1.2
    .model inertiaN1[2] inertia_omega_tau J=1.2
    .model inertiaN1[1] inertia_omega_tau J=1.2
    .model inertiaN1[0] inertia_omega_tau J=1.2

### Subcircuits with SPICE models given as parameters

In general SPICE allows parameters to be passed to subcircuits. This is the case for dimensions, like `W=2u`, `L=0.15u` that are passed to a subcircuit. The subcircuit uses these parameters (W, L) instead of numbers, making the subcircuit truly parametric. However transistor models in a subcircuit can not be passed as parameters, the following inverter instantiation is illegal:
`X1 A Y inverter W=2u L=0.15u modn=cmosn modp=cmosp`
To overcome this problem Xschem must generate multiple subcircuits. Consider the following inv3.sym symbol:

the symbol has the following attributes:

    type=subcircuit
    format="@name @pinlist @VCCPIN @VSSPIN @symname wn=@wn lln=@lln wp=@wp lp=@lp m=@m"
    template="name=x1 m=1 modn=xmodn modp=xmodp
    + wn=10u lln=1.2u wp=10u lp=1.2u
    + VCCPIN=VCC VSSPIN=VSS"
    extra="VCCPIN VSSPIN modn modp"

In above attributes two parameters are defined that specify transistor models, `modn` and `modp`, with default values (if unspecified in instance) `xmodn` and `xmodp`. The inverter subcircuit transistors will use the `@modn` and `@modp` as SPICE models:

If an inv3.sym is placed n the schematic and no `schematic=...` parameter is given to create an instance based subcircuit specialization:

The following netlist will be produced:

    x2 LDCP3_B LDCP vcc vss inv3 wn=8.4u lln=2.4u wp=20u lp=2.4u m=1
    ...
    ...
    .subckt inv3 y a VCCPIN VSSPIN      wn=10u lln=1.2u wp=10u lp=1.2u
    *.opin y
    *.ipin a
    m2 y a VCCPIN VCCPIN xmodp w=wp l=lp ad='wp *4.6u' as='wp *4.6u' pd='wp *2+9.2u' ps='wp *2+9.2u' m=1
    m1 y a VSSPIN VSSPIN xmodn w=wn l=lln ad='wn *4.3u' as='wn *4.3u' pd='wn *2+8.6u' ps='wn *2+8.6u' m=1
    .ends

However if another instance is placed:

with following attributes:

    name=x3 m=1
    + wn=8.4u lln=2.4u wp=20u lp=2.4u
    + VCCPIN=vcc VSSPIN=vss
    schematic=@symname\_1.sch
    modn=yyn modp=yyp

the following netlist is generated:

    x3 LDCP_B LDCP vcc vss inv3_1 wn=8.4u lln=2.4u wp=20u lp=2.4u m=1
    ...
    ...
    .subckt inv3_1 y a VCCPIN VSSPIN      wn=10u lln=1.2u wp=10u lp=1.2u
    *.opin y
    *.ipin a
    m2 y a VCCPIN VCCPIN yyp w=wp l=lp ad='wp *4.6u' as='wp *4.6u' pd='wp *2+9.2u' ps='wp *2+9.2u' m=1
    m1 y a VSSPIN VSSPIN yyn w=wn l=lln ad='wn *4.3u' as='wn *4.3u' pd='wn *2+8.6u' ps='wn *2+8.6u' m=1
    .ends

You see that a second `inv_1.sym` is generated with changed models (`yyn` and `yyp`). This allows you to reuse the same symbol with different model names. Xschem does the necessary work to duplicate the subcircuit, since model names can not be set as parameters.

### Another example of spice models given as parameters

Consider the following symbol instance:

with the following symbol definition

And the following schematic definition. Note the `model` syntax for the p-channel transistor (the n-channel transistor has a similar `model=modn@modeltag` definition):

The following netlist will be produced

    ...
    ...
    x4 LDCP4_B LDCP vcc vss inv4 wn=8.4u lln=2.4u wp=20u lp=2.4u m=1
    ...
    ...
    * expanding   symbol:  inv4.sym # of pins=2
    ** sym_path: /home/schippes/.xschem/xschem_library/test_parametric_model/inv4.sym
    ** sch_path: /home/schippes/.xschem/xschem_library/test_parametric_model/inv4.sch
    .subckt inv4 y a VCCPIN VSSPIN     wn=10u lln=1.2u wp=10u lp=1.2u
    *.opin y
    *.ipin a
    m2 y a VCCPIN VCCPIN modp18 w=wp l=lp ad='wp *4.6u' as='wp *4.6u' pd='wp *2+9.2u' ps='wp *2+9.2u' m=1
    m1 y a VSSPIN VSSPIN modn18 w=wn l=lln ad='wn *4.3u' as='wn *4.3u' pd='wn *2+8.6u' ps='wn *2+8.6u' m=1
    .ends
    ...
    ...

You see the `@modeltag` will be substituted looking first in the mos transistor attributes (but there is no definition there), then in the containing symbol `template` attributes (and there is a `modeltag=18` definition).

Now suppose you want to place another instance of `inv4.sym` but with a different modeltag: Since we know that spice does not allow model names to be passed as parameters we need to specialize the `inv4.sch` subcircuit to a new `inv_1.sch` subcircuit. Therefore we give the attribute `schematic=inv4_1.sch` to the second inv4 instance. We also set there a different modeltag: `modeltag=13`

The netlist for this additional instance will be:

    ...
    ...
    x5 LDCP5_B LDCP vcc vss inv4_1 wn=8.4u lln=2.4u wp=20u lp=2.4u m=1
    ...
    ...
    * expanding   symbol:  inv4_1.sym # of pins=2
    ** sym_path: /home/schippes/.xschem/xschem_library/test_parametric_model/inv4.sym
    ** sch_path: /home/schippes/.xschem/xschem_library/test_parametric_model/inv4.sch
    .subckt inv4_1 y a VCCPIN VSSPIN     wn=10u lln=1.2u wp=10u lp=1.2u
    *.opin y
    *.ipin a
    m2 y a VCCPIN VCCPIN modp13 w=wp l=lp ad='wp *4.6u' as='wp *4.6u' pd='wp *2+9.2u' ps='wp *2+9.2u' m=1
    m1 y a VSSPIN VSSPIN modn13 w=wn l=lln ad='wn *4.3u' as='wn *4.3u' pd='wn *2+8.6u' ps='wn *2+8.6u' m=1
    .ends
    ...
    ...

This way it is possible from a single symbol (`inv4.sym` in the example) to netlist multiple instances of it with different models, in the example using a `modeltag` variable.