INTRODUCTION TO CIRCUIT SIMULATION

Lecture 6.
Simulator Architectural Design

Guoyong Shi, PhD

shiguoyong@ic.sjtu.edu.cn
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