2023-04-13 21:01:15 +02:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<title>XSCHEM TUTORIAL: INSTANCE BASED SELECTION OF SYMBOL IMPLEMENTATION</title>
|
|
|
|
|
<link rel="stylesheet" type="text/css" href="xschem_man.css" />
|
|
|
|
|
<style type="text/css">
|
|
|
|
|
/* Local styling goes here */
|
|
|
|
|
p{padding: 15px 30px 10px;}
|
|
|
|
|
</style>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<!-- start of slide -->
|
|
|
|
|
<div class="content">
|
|
|
|
|
<!-- navigation buttons -->
|
|
|
|
|
<a href="xschem_man.html" class="home">UP</a>
|
|
|
|
|
|
|
|
|
|
<!-- slide title -->
|
|
|
|
|
<h1> TUTORIAL: INSTANCE BASED SELECTION OF SYMBOL IMPLEMENTATION</h1>
|
|
|
|
|
<p>
|
|
|
|
|
It is quite common to have in a design multiple instances of the same subcircuit.
|
|
|
|
|
Think for example of memory arrays and decoder circuits.
|
2023-04-14 15:41:00 +02:00
|
|
|
In some cases there are numerous instances of the same identical circuit. This leads to a very
|
2023-04-13 21:01:15 +02:00
|
|
|
large netlist and heavy simulation loads (both in time and space).<br>
|
|
|
|
|
On the other hand typically only a small portion of these repetitive circuits are exercised in
|
2023-04-14 15:41:00 +02:00
|
|
|
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.
|
2023-04-13 21:01:15 +02:00
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
</p>
|
|
|
|
|
<h3> schematic attribute on instance </h3>
|
|
|
|
|
<p>
|
|
|
|
|
Inside a symbol it is possible to specify an alternate <kbd>schematic</kbd> to descend into.
|
|
|
|
|
For example if symbol <kbd>inv.sym</kbd> has attribute <kbd>schematic=inv2.sch</kbd> then
|
|
|
|
|
xschem will descend into <kbd>inv2.sch</kbd> instead
|
|
|
|
|
of the default <kbd>inv.sch</kbd>.
|
|
|
|
|
See <a href="symbol_property_syntax.html">symbol_property_syntax man page</a>.
|
|
|
|
|
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.<br>
|
|
|
|
|
A <kbd>schematic=<schematic reference></kbd> attribute attached to an instance will specify the
|
|
|
|
|
schematic implementation to be used for that (and only that) instance of the subcircuit.<br>
|
|
|
|
|
Example:<br>
|
|
|
|
|
<kbd>schematic=comp_65nm_parax.sch</kbd>
|
|
|
|
|
</p>
|
|
|
|
|
<img src="instance_based_implementation_01.png">
|
|
|
|
|
<p>
|
|
|
|
|
The <kbd>comp_65nm_parax.sch</kbd> 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.
|
|
|
|
|
</p>
|
|
|
|
|
<img src="instance_based_implementation_03.png">
|
|
|
|
|
<h3> spice_sym_def attribute on instance </h3>
|
|
|
|
|
<p>
|
|
|
|
|
A <kbd>spice_sym_def=<...text...></kbd> 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 <kbd>schematic</kbd> attribute
|
|
|
|
|
that specifies the subcircuit name the instance is linked to.
|
|
|
|
|
</p>
|
|
|
|
|
<img src="instance_based_implementation_02.png">
|
|
|
|
|
<p>
|
|
|
|
|
Another possibility is to specify these attributes so the actual netlist will be included by the simulator.<br>
|
|
|
|
|
<kbd>schematic=comp_65nm_pex</kbd><br>
|
|
|
|
|
<kbd>spice_sym_def=".include /path/to/comp_65nm_pex.cir"</kbd><br>
|
|
|
|
|
<br>
|
|
|
|
|
When a <kbd>spice_sym_def</kbd> 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).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2023-04-14 15:41:00 +02:00
|
|
|
Putting this all together here is a schematic with 3 instances of <kbd>comp_65nm.sym</kbd>.
|
2023-04-13 21:01:15 +02:00
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><kbd>x1</kbd> is the standard instance using the default <kbd>comp_65nm.sch</kbd></li>
|
2023-04-13 22:25:36 +02:00
|
|
|
<li><kbd>x2</kbd> is a simplified instance that just keeps the output low.</li>
|
2023-04-13 21:04:45 +02:00
|
|
|
<li><kbd>x3</kbd> uses a parasitic extraction netlist (output will move slower).</li>
|
2023-04-13 21:01:15 +02:00
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
See the waveforms of the OUT, OUT2, OUT3 signals that behave accordingly.
|
|
|
|
|
</p>
|
|
|
|
|
<img src="instance_based_implementation_04.png">
|
|
|
|
|
|
2024-03-05 22:52:37 +01:00
|
|
|
<h3> Automatic port order setting from provided subcircuit netlist (Spice netlists only) </h3>
|
|
|
|
|
<p>
|
|
|
|
|
If a <kbd>spice_sym_def</kbd> attribute is defined and has one of the following forms:
|
|
|
|
|
</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
spice_sym_def="
|
|
|
|
|
.subckt opamp PLUS MINUS OUT VCC VSS
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
.ends
|
|
|
|
|
" </pre>
|
|
|
|
|
|
|
|
|
|
<p> Or:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
spice_sym_def=".include /path/to/subckt_file" </pre>
|
|
|
|
|
<p>
|
|
|
|
|
Xchem 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 xchem will use the port order drom the <kbd>.sym</kbd> file.
|
2023-04-13 21:01:15 +02:00
|
|
|
</p><br><br>
|
2023-04-13 22:33:56 +02:00
|
|
|
|
|
|
|
|
<p class="important">
|
|
|
|
|
Note: all the above concepts are valid for VHDL, Verilog and tEDAx netlists by replacing the
|
|
|
|
|
<kbd>spice_sym_def</kbd> attribute with <kbd>vhdl_sym_def</kbd>, <kbd>verilog_sym_def</kbd> and <kbd>tedax_sym_def</kbd>
|
|
|
|
|
respectively.
|
|
|
|
|
</p><br><br>
|
2024-02-14 10:59:40 +01:00
|
|
|
|
|
|
|
|
<h3> Instance based SPICE model </h3>
|
|
|
|
|
<p> 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:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
type=mechanical_rotational
|
|
|
|
|
format="@name @pinlist inertia@name
|
|
|
|
|
.model inertia@name inertia_omega_tau J=@J"
|
|
|
|
|
template="name=N1 J=1.1"
|
|
|
|
|
</pre>
|
|
|
|
|
<p> Note the model name is given as <kbd>inertia@name</kbd>, this will make each model instance have a
|
|
|
|
|
different and unique name. This will generate an instance line: </p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
N1 A B C inertiaN1
|
|
|
|
|
.model inertiaN1 inertia_omega_tau J=1.4
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<p> A better way hat handles also vectored instances is the following:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
type=mechanical_rotational
|
|
|
|
|
format="@name @pinlist #inertia#@name
|
|
|
|
|
.model #inertia#@name inertia_omega_tau J=@J"
|
|
|
|
|
template="name=N1 J=1.1"
|
|
|
|
|
</pre>
|
|
|
|
|
<p> This way if you place a vectored instance name=N1[3:0] it will expand in netlist as:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
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
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<h3> Subcircuits with SPICE models given as parameters </h3>
|
|
|
|
|
<p> In general SPICE allows parameters to be passed to subcircuits. This is the case for dimensions, like
|
|
|
|
|
<kbd>W=2u</kbd>, <kbd>L=0.15u</kbd> 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:<br>
|
|
|
|
|
|
|
|
|
|
<kbd>X1 A Y inverter W=2u L=0.15u modn=cmosn modp=cmosp</kbd><br>
|
|
|
|
|
To overcome this problem Xschem must generate multiple subcircuits.</br>
|
|
|
|
|
Consider the following inv3.sym symbol:</p>
|
|
|
|
|
<img src="instance_based_implementation_05.png">
|
|
|
|
|
<p> the symbol has the following attributes:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
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"
|
|
|
|
|
</pre>
|
|
|
|
|
<p> In above attributes two parameters are defined that specify transistor models, <kbd>modn</kbd> and
|
|
|
|
|
<kbd>modp</kbd>, with default values (if unspecified in instance) <kbd>xmodn</kbd> and <kbd>xmodp</kbd>.
|
|
|
|
|
The inverter subcircuit transistors will use the <kbd>@modn</kbd> and <kbd>@modp</kbd> as SPICE models:</p>
|
|
|
|
|
<img src="instance_based_implementation_06.png">
|
|
|
|
|
<p> If an inv3.sym is placed n the schematic and no <kbd>schematic=...</kbd> parameter is given
|
|
|
|
|
to create an instance based subcircuit specialization:</p>
|
|
|
|
|
<p> The following netlist will be produced:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
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
|
|
|
|
|
</pre>
|
|
|
|
|
<p> However if another instance is placed:</p>
|
|
|
|
|
<img src="instance_based_implementation_07.png">
|
|
|
|
|
<p> with following attributes: </p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
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
|
|
|
|
|
</pre>
|
|
|
|
|
<p> the following netlist is generated:</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
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
|
|
|
|
|
</pre>
|
|
|
|
|
<p> You see that a second <kbd>inv_1.sym</kbd> is generated with changed models (<kbd>yyn</kbd> and <kbd>yyp</kbd>).
|
|
|
|
|
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.
|
|
|
|
|
</p>
|
|
|
|
|
|
2024-02-16 16:44:33 +01:00
|
|
|
<h3> Another example of spice models given as parameters</h3>
|
|
|
|
|
|
|
|
|
|
<p> Consider the following symbol instance:</p>
|
|
|
|
|
<img src="instance_based_implementation_08.png">
|
|
|
|
|
<p> with the following symbol definition</p>
|
|
|
|
|
<img src="instance_based_implementation_09.png">
|
|
|
|
|
<p> And the following schematic definition. Note the <kbd>model</kbd> syntax for the p-channel transistor
|
|
|
|
|
(the n-channel transistor has a similar <kbd>model=modn@modeltag</kbd> definition):</p>
|
|
|
|
|
<img src="instance_based_implementation_10.png">
|
|
|
|
|
<p> The following netlist will be produced</p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
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
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
</pre>
|
|
|
|
|
<p> You see the <kbd>@modeltag</kbd> will be substituted looking first in the mos transistor attributes
|
2024-02-16 16:56:51 +01:00
|
|
|
(but there is no definition there), then in the containing symbol <kbd>template</kbd> attributes (and there is
|
2024-02-16 16:44:33 +01:00
|
|
|
a <kbd>modeltag=18</kbd> definition).</p>
|
|
|
|
|
<p> Now suppose you want to place another instance of <kbd>inv4.sym</kbd> 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
|
2024-02-16 16:56:51 +01:00
|
|
|
<kbd>inv4.sch</kbd> subcircuit to a new <kbd>inv_1.sch</kbd> subcircuit.
|
2024-02-16 16:44:33 +01:00
|
|
|
Therefore we give the attribute <kbd>schematic=inv4_1.sch</kbd>
|
|
|
|
|
to the second inv4 instance. We also set there a different modeltag: <kbd>modeltag=13</kbd></p>
|
|
|
|
|
<img src="instance_based_implementation_11.png">
|
|
|
|
|
<p> The netlist for this additional instance will be: </p>
|
|
|
|
|
<pre class="code">
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
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
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
</pre>
|
|
|
|
|
<p> This way it is possible from a single symbol (<kbd>inv4.sym</kbd> in the example) to netlist multiple instances of it
|
|
|
|
|
with different models, in the example using a <kbd>modeltag</kbd> variable.</p>
|
|
|
|
|
|
|
|
|
|
|
2023-04-13 21:01:15 +02:00
|
|
|
<!-- end of slide -->
|
|
|
|
|
<div class="filler"></div>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<!-- frame footer -->
|
|
|
|
|
<iframe seamless src="xschem_footer.html" class="footer_iframe" >
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
|
