Transcript Processes

General-purpose Specification
Languages
Universität Dortmund
System modeling & design
Represent system functions while abstracting away
unnecessary details
 Software programming languages
 Hardware description languages
 Flow and state-based diagrams
No golden solution
 System heterogeneity
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 1-
Universität Dortmund
Current trends
Bridge gap between hw and sw design
 Unified design style and methodology
Need for:
 Fast simulation of complex systems
 Hardware synthesis support
 Targeted software compilation
 Hw/Sw trade-off and interface design
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 2-
Universität Dortmund
Types of Languages
Domain-specific (e.g. dataflow)
 Practical for signal processing
 Concurrency + buffered communication
Hardware
 Structural and procedural styles
 Unbuffered “wire” communication
 Discrete-event semantics
Software
 Procedural
 Some concurrency
 Memory
Hybrid
 Mixture of other ideas
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 3-
Universität Dortmund
Outline of the class
HDL-based design
 HW design flow
 Overview of VHDL
System design with SystemC
 Overview of SystemC
 SystemC based (HW/SW) design
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 4-
Universität Dortmund
System Design Methodology
System Specification
HW
SW
(HDL)
(C)
Testbench
(C)
0101011110100010
1110010100100111
1000011110101001
0001100110101011
. . .
Challenge: deal with billion transitor complexity!!
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 5-
Universität Dortmund
Hardware versus software models
Hardware:
 Parallel execution
 I/O ports, building blocks
 Exact event timing is very important
Software:
 Sequential execution (usually)
 Structural information less important
 Exact event timing is not important
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 6-
Universität Dortmund
Traditional HW Design Flow
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 7-
Universität Dortmund
In detail: synthesis flow
Design Capture
Behavioral
Design Iteration
HDL
Pre-Layout
Simulation
Logic
Synthesis
Structural
Floorplanning
Post-Layout
Simulation
Circuit
Extraction
Placement
Physical
Routing
Tape-out
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 8-
Universität Dortmund
In detail: HDL for synthesis
Technology library (eg UMC 0.18)
Design constraints
Structural RTL
(tech. Indep)
HDL Specification
Module FSM(xx,xx)
Begin
xxx
…
end
Logic Synthesis
& Optimization
HW inference
Gate netlist
Physical DA
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 9-
Universität Dortmund
Hardware Languages
Goal: specify connected gates concisely
Originally targeted at simulation
Discrete event semantics skip idle portions
Mixture of structural and procedural modeling
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 10 -
Universität Dortmund
Hardware Languages
Verilog
 Structural and procedural modeling
 Four-valued vectors
 Gate and transistor primitives
 Less flexible
 Succinct
VHDL
 Structural and procedural modeling
 Few built-in types; powerful type system
 Fewer built-in features for hardware modeling
 More flexible
 Verbose
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 11 -
Universität Dortmund
Hardware methodology
Partition system into functional blocks
FSMs, datapath, combinational logic
Develop, test, and assemble
Simulate to verify correctness
Synthesize to generate netlist
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 12 -
Universität Dortmund
VHDL
HDL = hardware description language
Textual HDLs replaced graphical HDLs in the 1980‘ies
(better description of complex behavior).
VHDL = VHSIC hardware description language
VHSIC = very high speed integrated circuit
1980: Definition started by DoD in 1980
1984: first version of the language defined, based on ADA
(which in turn is based on PASCAL)
1987: revised version became IEEE standard 1076
1992: revised IEEE standard
more recently: VHDL-AMS: includes analog modeling
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 13 -
Universität Dortmund
Entities and architectures
Each design unit is called an entity.
Entities are comprised of entity declarations and one or several
architectures.
Each architecture includes a model of the entity. By default,
the most recently analyzed architecture is used. The use of
another architecture can be requested in a configuration.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 14 -
Universität Dortmund
The full adder as an example
- Entity declaration -
Entity declaration:
entity full_adder is
port(a, b, carry_in: in Bit; -- input ports
sum,carry_out: out Bit); --output ports
end full_adder;
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 15 -
Universität Dortmund
The full adder as an example
- Architectures Architecture = Architecture header + architectural bodies
architecture behavior of full_adder is
begin
sum
<= (a xor b) xor carry_in after 10 Ns;
carry_out <= (a and b) or (a and carry_in) or
(b and carry_in)
after 10 Ns;
end behavior;
Architectural bodies can be
- behavioral bodies or - structural bodies.
Bodies not referring to hardware components are called
behavioral bodies.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 16 -
Universität Dortmund
The full adder as an example
- Simulation results -
Behavioral description different from the one shown (includes 5ns delays).
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 17 -
Universität Dortmund
Structural bodies
architecture structure of full_adder is
component half_adder
port (in1,in2:in Bit; carry:out Bit; sum:out Bit);
end component;
component or_gate
port (in1, in2:in Bit; o:out Bit);
end component;
signal x, y, z: Bit;
-- local signals
begin
-- port map section
i1: half_adder port map (a, b, x, y);
i2: half_adder port map (y, carry_in, z, sum);
i3: or_gate
port map (x, z, carry_out);
end structure;
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 18 -
Universität Dortmund
VHDL processes
Processes model parallelism in hardware.
General syntax:
label:
--optional
process
declarations --optional
begin
statements --optional
end process
a <= b after 10 ns is equivalent to
process
begin
a <= b after 10 ns
end
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 19 -
Universität Dortmund
Wait-statements
Four possible kinds of wait-statements:
wait until signal list;
 wait until signal changes;
 Example: wait until a;
wait until condition;
 wait until condition is met;
 Example: wait until c='1';
wait for duration;
 wait for specified amount of time;
 Example: wait for 10 ns;
wait;
 suspend indefinitely
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 20 -
Universität Dortmund
Sensivity lists
Sensivity lists are a shorthand for a single wait on-statement at the end
of the process body:
process (x, y)
begin
prod <= x and y ;
end process;
is equivalent to
process
begin
prod <= x and y ;
wait on x,y;
end process;
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 21 -
Universität Dortmund
VHDL semantics: global control
According to the original standards document:
The execution of a model consists of an initialization phase followed by the
repetitive execution of process statements in the description of that model.
Initialization phase executes each process once.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 22 -
Universität Dortmund
VHDL semantics: initialization
At the beginning of initialization, current time, Tc is 0 ns.
 The driving value and the effective value of each explicitly declared
signal are computed, and the current value of the signal is set to the
effective value. …
 Each ... process … is executed until it suspends.
 The time of the next simulation cycle (… in this case … the 1st cycle),
Tn is calculated according to the rules of step f of the simulation cycle,
below.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 23 -
Universität Dortmund
VHDL semantics: The simulation cycle (1)
Each simulation cycle starts with setting Tc to Tn. Tn was either computed during
the initialization or during the last execution of the simulation cycle. Simulation
terminates when the current time reaches its maximum, TIME'HIGH. According
to the standard, the simulation cycle is as follows:
a) The current time, Tc is set to Tn. Stop if Tn= TIME'HIGH
and not  active drivers or process resumptions at Tn.
?
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 24 -
Universität Dortmund
VHDL semantics: The simulation cycle (2)
Each active explicit signal in the model is updated. (Events may occur as a
result.)
Previously computed entries in the queue are now assigned if their time
corresponds to the current time Tc.
New values of signals are not assigned before the next simulation cycle, at
the earliest.
Signal value changes result in events  enable the execution of processes
that are sensitive to that signal.
..
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 25 -
Universität Dortmund
VHDL semantics: The simulation cycle (3)
 P sensitive to s: if event on s in current cycle: P resumes.
Each ... process that has resumed in the current simulation cycle is executed
until it suspends*.
*Generates future values for signal drivers.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 26 -
Universität Dortmund
VHDL semantics: The simulation cycle (4)
Time Tn of the next simulation cycle = earliest of
1. TIME'HIGH (end of simulation time).
2. The next time at which a driver becomes active
3. The next time at which a process resumes
(determined by WAIT ON statements).
Next simulation cycle (if any) will be a delta cycle if Tn = Tc.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 27 -
Universität Dortmund
-simulation cycles
…
Next simulation cycle (if any) will be a delta cycle if Tn = Tc.
Delta cycles are generated for delay-less models.
There is an arbitrary number of  cycles between any 2 physical time
instants:
In fact, simulation of delay-less hardware loops will never terminate.
1
0
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 28 -
Universität Dortmund
-simulation cycles
Simulation of an RS-Flipflop
2nd 
0000
0001
1st 
1100
0111
architecture one
of RS_Flipflop is
begin
process: (R,S,Q,nQ)
begin
Q <= R nor nQ;
nQ <= S nor Q;
end process;
end one;
0ns 0ns+ 0ns+2
R
1
1
1
S
0
0
0
Q
1
0
0
nQ 0
0
1
 cycles reflect the fact that no
real gate comes with zero delay.
 should delay-less signal
assignments be allowed at all?
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 29 -
Universität Dortmund
-simulation cycles
and deterministic simulation semantics
Semantics of
a <= b;
b <= a; ?
Separation into 2 simulation phases results
in deterministic semantics
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 30 -
Universität Dortmund
VHDL: Evaluation
Behavioral hierarchy (procedures and functions),
Structural hierarchy: through structural architectures,
but no nested processes,
No specification of non-functional properties,
No object-orientation,
Static number of processes,
Complicated simulation semantics,
Too low level for initial specification,
Good as an intermediate “Esperanto“ or ”assembly” language for
hardware generation.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 31 -
Universität Dortmund
Verilog and VHDL Compared
Structure
Hierarchy
Separate interfaces
Concurrency
Switch-level modeling
Gate-level modeling
Dataflow modeling
Procedural modeling
Verilog
l
l
l
l
l
l
l
VHDL
l
l
l
l
m
m
l
l
Type system
Event access
l
l
Local variables
Shared memory
Wires
Resolution functions
l
m
l
l
l
l
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 32 -
Universität Dortmund
Outline of the class
HDL-based design
 HW design flow
 Overview of VHDL
System design with SystemC
 Overview of SystemC
 SystemC based (HW/SW) design
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 33 -
Universität Dortmund
System Design Methodology
System Specification
HW
SW
(HDL)
(C)
Testbench
(C)
0101011110100010
1110010100100111
1000011110101001
0001100110101011
. . .
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 34 -
Universität Dortmund
Software Languages
Goal: specify machine code concisely
Sequential semantics:
Perform this operation
Change system state
Raising abstraction: symbols, expressions, control-flow,
functions, objects, templates, garbage collection
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 35 -
Universität Dortmund
Software Languages
C
 Adds types, expressions, control, functions
C++
 Adds classes, inheritance, namespaces, templates, exceptions
Java
 Adds automatic garbage collection, threads
 Removes bare pointers, multiple inheritance
Real-Time Operating Systems
 Add concurrency, timing control
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 36 -
Universität Dortmund
Software methodology
C
 Divide into (recursive) functions
C++
 Divide into objects (data and methods)
Java
 Divide into objects, threads
RTOS
 Divide into processes, assign priorities
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 37 -
Universität Dortmund
SystemC
Objectives:
 Model Hw with Sw programming language
 Achieve fast simulation
 Provide support for hw/sw system design
Requirement:
 Give hw semantics to sw models
Supported by a large consortium of semiconductor and
EDA companies
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 38 -
Universität Dortmund
SystemC
C++ class library and modeling methodology
 Hw semantics defined through the class library
Object-oriented style
 Components and encapsulation
No language restriction or addition
Some hw synthesis support
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 39 -
Universität Dortmund
SystemC features
Enable C++ without extending the language (syntax) use classes
Concurrency
Hardware Data Types
Notion of Time
Reactive Behavior
Communication
Processes
bit vectors, arbitrary precision
signed and unsigned integers,
fixed-point numbers
Clocks
Watching
Signals, protocols
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 40 -
Universität Dortmund
Model Structure
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 41 -
Universität Dortmund
SystemC Classes
Modules and Ports
SC_MODULE
in1
Modules (sc_module)
 Fundamental structural entity
clk
 Contain processes
 Contain other modules
in2
(creating hierarchy)
Ports(sc_in<>,sc_out<>,sc_inout<>)
 Modules have ports
 Ports have types
 A process can be made sensitive to ports/signals
 P.Marwedel, U. Dortmund, Informatik 12, 2006
out1
out2
- 42 -
Universität Dortmund
SystemC Classes - Processes
SC_MODULE
Processes
 Functionality is described
in a process
 Processes run concurrently
in1
PROCESS
out1
clk
in2
PROCESS
out2
 Code inside a process executes sequentially
 SystemC has three different types of processes
• SC_METHOD
• SC_THREAD
• SC_CTHREAD
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 43 -
Universität Dortmund
Process types
sc_method: method process
 sensitive to a set of signals
 executed until it returns
RTL style
sc_thread: thread process
 sensitive to a set of signals
 executed until a wait()
Testbench
sc_cthread: clocked thread process
 sensitive only to one edge of clock
 execute until a wait() or a wait_until()
 watching(reset) restarts from top of process
body (reset evaluated on active edge)
Architectural
style
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 44 -
Universität Dortmund
Execution of processes
port a
process
internal
signal
sig
process
port b
module ex
Not hierarchical, communicate through signals
Execution and signal updates
 request-update semantics
1. execute all processes that can be executed
2. update the signals written by the processes
3.  other processes to be executed
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 45 -
Universität Dortmund
Channels
Primitive
 P.Marwedel, U. Dortmund, Informatik 12, 2006
Hierarchical
- 46 -
Universität Dortmund
Communication semantics
Interface Method Calls (IMC)
 Process calls an interface method of a channel
 The collection of a fixed set of communication Methods is
called an Interface (virtual object without data)
 Channels implement one or more Interfaces
 Modules can be connected via their Ports to those Channels
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 47 -
Universität Dortmund
Model types
Specification model
PE*-assembly model
Bus-arbitration model
Time-accurate communication
model
Cycle-accurate computation
model
Implementation model
TLM
* Processing elements
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 48 -
Universität Dortmund
PE-assembly & Bus-arbitration Models
Processing elements (PEs)
Message-passing channels
Abstract bus channels
Bus arbiter arbitrates bus
conflict
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 49 -
Universität Dortmund
Time-accurate Communication model
Time/cycle accurate
communication (time
constraint)
Approximate timed
computation
Protocol channel provides
functions for all
abstraction bus
transaction
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 50 -
Universität Dortmund
Cycle-accurate computation model
Modeled at register-transfer level
PE are pin accurate and execute cycle-accurately
Wrappers convert data transfer from higher level of abstraction to
lower level abstraction
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 51 -
Universität Dortmund
Successive refinements
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 52 -
Universität Dortmund
SystemC Design Vision
System Specification
HW
SW
(SystemC)
(SystemC)
Testbench
(SystemC)
0101011110100010
1110010100100111
1000011110101001
0001100110101011
. . .
SystemC as a single design language
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 53 -
Universität Dortmund
Pure SystemC Flow
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 54 -
Universität Dortmund
SystemC HDL Flow
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 55 -
Universität Dortmund
Benefits of a C/C++ Design Flow
 Productivity aspect
Specification between architect and implementer is executable
High speed and high level simulation and prototyping
Refinement, no translation into hardware
 System level aspect
Tomorrow’s systems designers will be designing mostly software
and less hardware !
Co-design, co-simulation, co-verification, co-debugging, ...
 Re-use aspect
Optimum re-use support by object-oriented techniques
Efficient testbench re-use
Especially C/C++ is widespread and commonly used !
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 56 -
Universität Dortmund
Drawbacks of a C/C++ Design Flow
 C/C++ is not created to design hardware !
 C/C++ does not support
• Hardware style communication - Signals, protocols
• Notion of time - Clocks, time sequenced operations
• Concurrency - Hardware is inherently concurrent, operates
in parallel
• Reactivity - Hardware is inherently reactive, responds to
stimuli, interacts with its environment (requires handling of
exceptions)
• Hardware data types - Bit type, bit-vector type, multi-valued
logic types, signed and unsigned integer types, fixed-point types
 Missing links to hardware during debugging
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 57 -
Universität Dortmund
The missing link: SystemC Synthesis
SystemC is not “born” to be a language for HW
implementation (like Verilog & VHDL)
Someone does not think so (and it would be nice
if they were right)
 Basic idea: define synthesizable
SystemC subset
 Make it another refinement step
But will it succeed? Long story…
[Celoxica 2005]
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 58 -
Universität Dortmund
Open Community Licensing
How to get SystemC ?
v2.0
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 59 -
Universität Dortmund
SystemC Design Methodology
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 60 -
Universität Dortmund
Bottom-up alternatve: System Verilog
Extensions to Verilog HDL
 Modeling:
• Transaction-level modeling
– Higher abstraction level
• Direct Programming interface
– Enables calls to C/C++/SystemC
– Co-simulation Verilog/SystemC
• Interface modeling with encapsulation
– Support bus-intensive design
– IP protection by nesting modules
 Verification:
• Procedural assertions
– Built into the language
– Avoid recoding errors, increase test accuracy
Is it only syntactic sugar? Long story…
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 61 -
Universität Dortmund
SystemC contrasted
with other design languages
Requirements
Architecture
Matlab
HW/SW
Behavior
Functional
Verification
System
Verilog
Test bench
RTL
Verilog
Vera
e
Sugar
Jeda
System
C
VHDL
Gates
Transistors
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 62 -
Levels of abstraction
Universität Dortmund
System level
 The term system level is not clearly defined.
 It is used here to denote the entire embedded system
and the system into which information processing is
embedded, and possibly also the environment.
 Such models may include mechanical as well as
information processing aspects, and may be difficult to
find appropriate simulators. Solutions include VHDLAMS, SystemC or MATLAB. MATLAB and VHDL-AMS
support modeling partial differential equations.
 Challenge to model information processing parts of the
system in such a way that the simulation model can also
be used for the synthesis of the embedded system.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 64 -
Universität Dortmund
Algorithmic level
 Simulating the algorithms that we intend to use within
the embedded system.
 No reference is made to processors or instruction sets.
 Data types may still allow a higher precision than the
final implementation.
 If data types have been selected such that every bit
corresponds to exactly one bit in the final
implementation, the model is said to be bit-true.
Translating non-bit-true into bit-true models should be
done with tool support.
 May consist of single processes or of sets of
cooperating processes.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 65 -
Universität Dortmund
Algorithmic level: Example:
-MPEG-4 full motion search -
for (z=0; z<20; z++)
for (x=0; x<36; x++) {x1=4*x;
for (y=0; y<49; y++) {y1=4*y;
for (k=0; k<9; k++) {x2=x1+k-4;
for (l=0; l<9; ) {y2=y1+l-4;
for (i=0; i<4; i++) {x3=x1+i; x4=x2+i;
for (j=0; j<4;j++) {y3=y1+j; y4=y2+j;
if (x3<0 || 35<x3||y3<0||48<y3)
then_block_1; else else_block_1;
if (x4<0|| 35<x4||y4<0||48<y4)
then_block_2; else else_block_2;
}}}}}}
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 66 -
Universität Dortmund
Instruction level
Algorithms have already been compiled for the instruction set
of the processor(s) to be used. Simulations at this
level allow counting the executed number of instructions.
Variations:
 Simulation only the effect of instructions
 Transaction-level modeling: each read/write is one
transaction, instead of a set of signal assignments
 Cycle-true simulations: exact number of cycles
 Bit-true simulations: simulations using exactly the
correct
number of bits
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 67 -
Universität Dortmund
Instruction level: example
Assembler (MIPS)
and $1,$2,$3
Simulated semantics
Reg[1]:=Reg[2]  Reg[3]
or $1,$2,$3
Reg[1]:=Reg[2]  Reg[3]
andi $1,$2,100 Reg[1]:=Reg[2]  100
sll $1,$2,10
Reg[1]:=Reg[2] << 10
srl $1,$2,10
Reg[1]:=Reg[2] >> 10
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 68 -
Universität Dortmund
Register transfer level (RTL)
At this level, we model all the components at the registertransfer level, including
- arithmetic/logic units (ALUs),
- registers,
- memories,
- muxes and
- decoders.
Models at this level are always cycle-true.
Automatic synthesis from such models is not a major
challenge.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 69 -
Universität Dortmund
Register transfer level: example (MIPS)
31:26
a1
25:21
a2
20:16
a3
0
1
Speicher
Reg
1
i3
Instruction register IR
1
Memory
0
PCSource
ALU
0
i2 a2 a1
PC
§
TargetWrite
ALUOp
ALUSelA
ALUSelB
RegWrite
RegDest
IRWrite
MemRead
B
MemWrite
PCWrite
Controller
0
T
1
0
2
4
1
15:11
25:0
sign_
extend
15:0
1
0
2
3
§ * "00“
31: 28
*
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 70 -
Universität Dortmund
Gate-level models
 Models contain gates as the basic components.
 Provide accurate information about signal transition
probabilities and can therefore also be used for power
estimations.
 Delay calculations can be more precise than for the
RTL.
Typically no information about the length of wires (still
estimates).
 Term sometimes also employed to denote Boolean
functions (No physical gates; only considering the
behavior of the gates).
Such models should be called “Boolean function
models”.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 71 -
Universität Dortmund
Gate-level models: Example
source:
http://geda.
seul.org/
screenshots/
screenshotschem2.png
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 72 -
Universität Dortmund
Switch-level models
 Switch level models use switches (transistors) as their
basic components.
 Switch level models use digital values models.
 In contrast to gate-level models, switch level models are
capable of reflecting bidirectional transfer of information.
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 73 -
Universität Dortmund
Switch level model: example
Source: http://vada1.skku.ac.kr/ClassInfo/ic/vlsicad/chap-10.pdf
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 74 -
Universität Dortmund
Circuit level models: Example
 Models Circuit theory and its components (current and
voltage sources, resistors, capacitances, inductances
and possibly macro-models of semiconductors) form
the basis of simulations at this level.
Simulations involve
partial differential
equations.
Linear if and only if the
behavior of
semiconductors is
linearized.
Ideal MOSFET
Transistor
model
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 75 -
Universität Dortmund
Circuit level models: SPICE
The most frequently used
simulator at this level is
SPICE [Vladimirescu, 1987]
and its variants.
Example:
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 76 -
Universität Dortmund
Circuit level models:
sample simulation results
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 77 -
Universität Dortmund
Device level
Simulation
of a single
device
(such as a
transistor).
Example
(SPICEsimulation
[IMEC]):
Measured and simulated currents
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 78 -
Universität Dortmund
Layout models
 Reflect the actual circuit layout,
 include geometric information,
 cannot be simulated directly:
behavior can be deduced by correlating the layout
model with a behavioral description at a higher level or
by extracting circuits from the layout.
 Length of wires and capacitances frequently extracted
from the layout, back-annotated to descriptions at
higher levels (more precision for delay and power
estimations).
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 79 -
Universität Dortmund
Layout models: Example
powhi
dout
din
powlo
© Mosis (http://www.
mosis.org/Technical/
Designsupport/
polyflowC.html);
Tool: Cadence
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 80 -
Universität Dortmund
Process models
Model of fabrication process; Example [IMEC]:
Doping as a function of the distance from the surface
Simulated
Measured
 P.Marwedel, U. Dortmund, Informatik 12, 2006
- 81 -