INTRODUCTION TO CIRCUIT SIMULATION
Lecture 6.
Simulator Architectural Design
Guoyong Shi, PhD
[email protected] School of Microelectronics
Shanghai Jiao Tong University
Spring 2010
2010-9-27 Slide 1
Outline
• Basic constructs
• Model & Device Classes
• Device loading
• Object-oriented programming
• Model Compiler
2010-9-27 Lecture 06 slide 2
A Detailed Simulator Flow
Parser
Parser Prepare for Analysis
Netlist (Save
(Saveall
allckt
cktinfo
info (Create void stamps
to a symbol table;
to a symbol table; for all devices)
Check
Checkcircuit
circuitintegrity;
integrity;
Higher-level Report
Report error,etc.)
error, etc.)
Description
Language
Algorithms Run
RunAnalysis
Analysis
(Fill
(Fill stampsaccording
stamps according
to
toanalysis
analysistype)
type)
Models
Save and
Present
GUI
Simulation Result
2010-9-27 Lecture 06 slide 3
Node versus Terminal
• “Node” is a circuit
attribute:
Each node is connected
to a list of devices.
• “Terminal” is a device
De
vi c attribute:
e
vic
e Each device has a list
De
of terminals.
k • A device terminal
Node /
becomes a circuit node
Terminal De when it is connected in a
i ce vi c circuit.
e v e • Multiple device terminals
D may share the same
node.
• Each device terminal
identifies a branch
current.
2010-9-27 Lecture 06 slide 4
Node versus Device
• Each Node Object manages
a list of devices connected
to it.
De • Each Device Object
v ic
ice
e manages a list of nodes as
v
De
its terminals.
k
node • Such information is directly
De
ce v ice used in the MNA matrix
v i
De stamping.
2010-9-27 Lecture 06 slide 5
Example
class DEVICE
class RES class CAP class IND
R1 C1 L1
R2 C2 L2
R3 C3 L3
. . .
Instances Instances
. . .
2010-9-27 Lecture 06 slide 6
Simulator Construction
• The simulator should manage the following lists:
List of models
mod_inst[2]
List of devices
List of analyses device[0] analysis[0]
mod_inst[1] device[1] analysis[1]
device[3] analysis[3]
device[0] device[4]
device[1] analysis[4]
mod_inst[0] device[5]
device[3] device[6] analysis[5]
model[0] device[0] device[4] analysis[6]
model[1] device[1] device[5] device type analysis[7]
model[3] device[3] device[6] analysis[8]
model[4] device[4]
model[5] device[5] device type
analysis type
model[6] device[6]
device type
model type
2010-9-27 Lecture 06 slide 7
Model & Device Classes
Model
Model_Res Model_Cap Model_Ind
Multiple MOS models
Model_MOS1 Model_MOS3
Model_MOS2
Model_Vsrc Model_Isrc Device
······ Ind
Res Cap
MOS1 MOS3
MOS MOS2
Just need one class
for MOS device Vsrc Isrc
2010-9-27 Lecture 06 ······ slide 8
Device Instances
• Device instances are divided into two
categories:
1. Instances without models
2. Instances with models
These two types of instances are managed
by the Circuit Object.
2010-9-27 Lecture 06 slide 9
Device Instances without Model
Managed by the Circuit object Spice takes a model-driven
device instantiating strategy.
Spice creates a default model
D_type[0] Res Res for the same type devices
D_type[1] Cap without a model.
D_type[3] Ind Ind
D_type[4] This means all device instances
D_type[5] have models.
D_type[6]
D_type[7] Device instances
D_type[8] without models
Device type
2010-9-27 Lecture 06 slide 10
Device Instances with Model
Model
Model instances
Model_Res Model_Cap Model_Ind
Res Res Model_Res_Inst_1 Model_MOS1 Model_MOS3
Model_MOS2
Res Model_Res_Inst_2
Model_Vsrc Model_Isrc
Res Res Model_Res_Inst_3
Model_BSIM3
Model_BSIM1
······
Device instances with models
2010-9-27 Lecture 06 slide 11
Links among Models & Devices
mod_inst[2]
Including
device[0]
default mod_inst[1] device[1]
models device[3]
device[0] device[4]
mod_inst[0] device[1] device[5]
device[3] device[6]
model[0] device[0] device[4]
model[1] device[1] device[5] device type
model[3] device[3] device[6]
model[4] device[4]
model[5] device[5] device type
model[6] device[6]
device type
model type
2010-9-27 Lecture 06 slide 12
Model-based Device Instances
• If a device does not have a model, a default model is
created for it.
• The same type devices without model share the same
default model.
• The parameters for a default model are not assigned.
• Spice uses XXXtemp() function to evaluate the stamp,
which uses the temperature information.
If a default model, the model parameters are not used at all.
Only the lumped parameter given in the netlist is used for
evaluation.
2010-9-27 Lecture 06 slide 13
Analysis Classes
Analysis
analysis[0]
Analysis_DC Analysis_AC Analysis_Tran analysis[1]
analysis[3]
Analysis_Noise analysis[4]
Analysis_OP
Analysis_PZ analysis[5]
analysis[6]
analysis[7]
Analysis_Disto Analysis_Sens analysis[8]
arranged in list
analysis type
2010-9-27 Lecture 06 slide 14
Models and Devices
• A netlist may have a list of devices (identified by
device types)
• Each type of device may have a list of models
• Each device model may have a list of instances
ckt M_type[0] M_type[1] M_type[type]
M_inst-0 M_inst_0
D_inst_0
M_inst-1 M_inst_1
D_inst_1
D_inst_0
D_inst_2 M_inst-2
D_inst_1
M_inst_2
D_inst_0
* This data structure will be used during circuit loading!
2010-9-27 Lecture 06 slide 15
Referencing Model and Instances
• Each model instance may be linked with a list of
device instances.
• Each device instance has a back pointer pointing at
the belonging model instance.
MODEL
back link
dev inst-1 dev inst-2 ...... dev inst-k
* One model supports multiple devices.
2010-9-27 Lecture 06 slide 16
Device Loading
ckt mod type[0] mod type[1] mod type[K ]
mod inst-0 mod inst-0
dev inst-0 dev inst-0
mod inst-1 mod inst-1
dev inst-1 dev inst-1
dev inst-0 dev inst-0
dev inst-2 mod inst-2 dev inst-2 mod inst-2
dev inst-1 dev inst-1
dev inst-0 dev inst-0
Each instant is a
physical
device in circuit.
* This whole structure is scanned during
device loading.
2010-9-27 Lecture 06 slide 17
Device Models
• Semiconductor devices are described by a
set of analytical equations.
• One model may take several hundreds of
pages (BSIM3/4).
• Can be written in description language –
Verilog-AMS.
• Have to be translated into C/C++ code.
2010-9-27 Lecture 06 slide 18
Typical Modeling Flow
Repeat...
Model Parameter Extraction Device New Effect Found
Model Designer
Developer
Independent implementations
Vendor Vendor Vendor Vendor Vendor
A B C D E
Verified Design
Repeat...
New Effect Found
Foundry
2010-9-27 Lecture 06 slide 19
Model Implementation
• Refer to C implementation of model equations;
including derivative computations (Jacobian matrix, ...)
• Model implementation is more difficult, time
consuming and error-prone than model creation
(writing math eqns).
• Simulator vendors have to develop their own
implementations (IP issues)
• Model implementation is also costly.
• Designers have less control over models.
• Designers may identify flaws in models while
using simulators.
2010-9-27 Lecture 06 slide 20
Designers Want ...
• Accurate and robust models.
• Models covering all cases likely to appear in
real design.
• Models that can be simulated efficiently.
• Sometimes want to modify the model
equations in their own favor ...
2010-9-27 Lecture 06 slide 21
Model Compiler Can Help !
A Model Compiler is a CAD tool that supports automatic
implementation of compact device model.
Input in Output (ready
Model Compiler for simulator)
Compact
Description
1. Input: compact device models in a description language -
Verilog-AMS
2. Output: device code in C/C++ that can be directly compiled in
Spice-like simulators.
2010-9-27 Lecture 06 slide 22
Device Model Implementation Flow
New device & Equations
pi ler
om
Initial coding in MATLAB
odel C
M
New modification
Update new effects
Convert to C code
Install & test model in simulator
Release new simulator
Purchase by design company & qualification
2010-9-27 Designers useLecture
new models
06 slide 23
INTRODUCTION TO CIRCUIT SIMULATION
APPENDIX --
Object-Oriented Programming
2010-9-27 Slide 24
Object-Oriented Programming
• Data and functions associated with the same
object are collected in one class
So-called “encapsulation”
Provides modularity of code.
2010-9-27 Lecture 06 slide 25
Use Polymorphism
• Define object interface in the base classes
using virtual functions in C++ for
polymorphism.
• Implementation of objects defined in the
derived classes.
• Better code readability / flexibility, and
• Easier code management.
• Polymorphism is very suitable for model
interfacing and device methods.
2010-9-27 Lecture 06 slide 26
Modular Development
• Make the numerical methods, modeling, and
analysis independent from each other as
much as possible.
• Make the Solver Module independent of the
analysis algorithms; so that it is easier to
update the solver.
• Make device models Independent of the
simulator analysis engine;
2010-9-27 Lecture 06 slide 27
