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.

Note: when creating alternate netlist files ensure the port order is identical to the base circuit. The assumption for all alternate circuits created using the methods explained above is that the alternate circuits have all the same interface as the base circuit (same input, output, inout pins, in the same order).

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.