models
advertisement
Models, Architectures, Languages
z
Introduction
z
Models
– State, Activity, Structure, Data, Heterogeneous
z
Architectures
– Function-Architecture, Platform-Based
z
Languages
– Hardware: VHDL / Verilog / SystemVerilog
– Software: C / C++ / Java
– System: SystemC / SLDL / SDL
– Verification: PSL (Sugar, OVL)
Fall 2002
1
Models, Architectures, Languages
INTRODUCTION
Fall, 2001
2
1
Design Methodologies
z
Capture-and-Simulate
– Schematic Capture
– Simulation
z
Describe-and-Synthesize
– Hardware Description Language
– Behavioral Synthesis
– Logic Synthesis
z
Specify-Explore-Refine
– Executable Specification
– Hardware-Software Partitioning
– Estimation and Exploration
– Specification Refinement
Fall 2002
3
Motivation
Fall 2002
4
2
Models & Architectures
Specification +
Constraints
Models
(Specificatio
n)
Design
Process
Architectures
(Implementation)
Implementation
Models are conceptual views of the system’s functionality
Architectures are abstract views of the system’s implementation
Fall 2002
5
Behavior Vs.
Architecture
Performance models:
Emb. SW, comm. and
comp. resources
Models of
Computation
1
Behavior
Simulation
Synthesis
System 2
Architecture
System
Behavior
HW/SW
partitioning,
Scheduling
Mapping
3
Performance
Simulation
Communication
Refinement
SW estimation
4
Flow To Implementation
Fall 2002
6
3
Models of an Elevator Controller
Fall 2002
7
Architectures Implementing the
Elevator Controller
Fall 2002
8
4
Current Abstraction Mechanisms in
Hardware Systems
Abstraction
The level of detail contained within the system model
z
A system can be modeled at
–
–
–
–
–
z
System Level,
Algorithm or Instruction Set Level,
Register-Transfer Level (RTL),
Logic or Gate Level,
Circuit or Schematic Level.
A model can describe a system in the
– Behavioral domain,
– Structural domain,
– Physical domain.
Fall 2002
Abstractions in Modeling:
Hardware Systems
Level
Behavior
Structure
Physical
Start here
PMS (System)
Communicating
Processes
Processors
Memories
Switches (PMS)
Instruction Set
(Algorithm)
Input-Output
Memory, Ports
Processors
Board
Floorplan
RegisterTransfer
Register
Transfers
ALUs, Regs,
Muxes, Bus
ICs
Macro Cells
Logic
Logic Eqns.
Gates, Flip-flops
Std. cell layout
Circuit
Network Eqns.
Trans., Connections
© IEEE 1990
Cabinets, Cables
Work to
here
Transistor layout
[McFarland90]
Fall 2002
5
Current Abstraction Mechanisms for
Software Systems
Virtual Machine
A software layer very close to the hardware that hides the
hardware’s details and provides an abstract and portable view
to the application programmer
Attributes
– Developer can treat it as the real machine
– A convenient set of instructions can be used by developer to
model system
– Certain design decisions are hidden from the programmer
– Operating systems are often viewed as virtual machines
Fall 2002
Abstractions for
Software Systems
Virtual Machine Hierarchy
z Application Programs
z Utility Programs
z Operating System
z Monitor
z Machine Language
z Microcode
z Logic Devices
Fall 2002
6
MODELS
Fall, 2001
13
Unified HW/SW Representation
z
Unified Representation –
– High-level system (SoC) architecture description
– Implementation (hardware or software) independent
– Delayed hardware/software partitioning
– Cross-fertilization between hardware and software
– Co-simulation environment for communication
– System-level functional verification
Fall 2002
7
Abstract Hardware-Software Model
Unified representation of system allows early
performance analysis
General
Performance
Evaluation
Identification
of Bottlenecks
Abstract
HW/SW
Model
Evaluation
of Design
Alternatives
Evaluation
of HW/SW
Trade-offs
Fall 2002
HW/SW System Models
z
State-Oriented Models
– Finite-State Machines (FSM), Petri-Nets (PN), Hierarchical
Concurrent FSM
z
Activity-Oriented Models
– Data Flow Graph, Flow-Chart
z
Structure-Oriented Models
– Block Diagram, RT netlist, Gate netlist
z
Data-Oriented Models
z
Heterogeneous Models
– Entity-Relationship Diagram, Jackson’s Diagram
– UML (OO), CDFG, PSM, Queuing Model, Programming
Language Paradigm, Structure Chart
Fall 2002
8
State-Oriented: Finite-State Machine
(Mealy Model)
Fall 2002
17
State-Oriented: Finite State Machine
(Moore Model)
Fall 2002
18
9
State-Oriented: Finite State Machine with
Datapath
Fall 2002
19
Finite State Machines
z
Merits
– Represent system’s temporal behavior explicitly
– Suitable for control-dominated systems
– Suitable for formal verification
z
Demerits
– Lack of hierarchy and concurrency
– State or arc explosion when representing complex
systems
Fall 2002
20
10
State-Oriented: Petri Nets
z
System model consisting of places, tokens, Petri Nets:
a transitions, arcs, and a marking
– Places - equivalent to conditions and hold tokens
– Tokens - represent information flow through system
– Transitions - associated with events, a “firing” of a transition
indicates that some event has occurred
– Marking - a particular placement of tokens within places of a
Petri net, representing the state of the net
Example:
Input
Places
Token
Transition
Fall 2002
Output
Place
State-Oriented: Petri Nets
Fall 2002
22
11
Petri Nets
z
Merits
– Good at modeling and analyzing concurrent systems
– Extensive theoretical and experimental works
– Used extensively for protocol engineering and control system
modeling
z
Demerits
– “Flat Model” that becomes incomprehensible when system
complexity increases
Fall 2002
23
State-Oriented:
Hierarchical Concurrent FSM
Fall 2002
24
12
Hierarchical Concurrent FSM
z
Merits
– Support both hierarchy and concurrency
– Good for representing complex systems
z
Demerits
– Concentrate only on modeling control aspects and not data
and activities
Fall 2002
25
Activity-Oriented:
Data Flow Graphs (DFG)
Fall 2002
26
13
Data Flow Graphs
z
Merits
– Support hierarchy
– Suitable for specifying complex transformational systems
– Represent problem-inherent data dependencies
z
Demerits
– Do not express control sequencing or temporal behaviors
– Weak for modeling embedded systems
Fall 2002
27
Activity-Oriented: Flow Charts
Fall 2002
28
14
Flow Charts
z
Merits
– Useful to represent tasks governed by control flows
– Can impose an order to supersede natural data dependencies
z
Demerits
– Used only when the system’s computation is well known
Fall 2002
29
Structure-Oriented:
Component Connectivity Diagrams
Fall 2002
30
15
Component Connectivity Diagrams
z
Merits
– Good at representing system’s structure
z
Demerits
– Behavior is not explicit
z
Characteristics
– Used in later phases of design
Fall 2002
31
Data-Oriented:
Entity-Relationship Diagram
Fall 2002
32
16
Entity-Relationship Diagrams
z
Merits
– Provide a good view of the data in a system
– Suitable for representing complex relationships among
various kinds of data
z
Demerits
– Do not describe any functional or temporal behavior of a
system
Fall 2002
33
Data-Oriented:
Jackson’s Diagram
Fall 2002
34
17
Jackson’s Diagrams
z
Merits
– Suitable for representing data having a complex composite
structure
z
Demerits
– Do not describe any functional or temporal behavior of the
system
Fall 2002
35
Heterogeneous:
Control/Data Flow Graphs (CDFG)
z
z
z
Graphs contain nodes corresponding to operations in
either hardware or software
Often used in high-level hardware synthesis
Can easily model data flow, control steps, and
concurrent operations because of its graphical nature
5
Example:
X 4
Y
+
+
+
Control Step 1
Control Step 2
+
Control Step 3
Fall 2002
18
Control/Data Flow Graphs
z
Merits
– Correct the inability to represent control dependencies in DFG
– Correct the inability to represent data dependencies in CFG
z
Demerits
– Low level specification (behavior not evident)
Fall 2002
37
Heterogeneous: Structure Chart
Fall 2002
38
19
Structure Charts
z
Merits
– Represent both data and control
z
Demerits
– Used in the preliminary stages of system design
Fall 2002
39
Heterogeneous:
Object-Oriented Paradigms (UML, …)
z
z
Use techniques previously applied to software to
manage complexity and change in hardware modeling
Use OO concepts such as
– Data abstraction
– Information hiding
– Inheritance
z
Use building block approach to gain OO benefits
– Higher component reuse
– Lower design cost
– Faster system design process
– Increased reliability
Fall 2002
20
Heterogeneous:
Object-Oriented Paradigms (UML, …)
Object-Oriented Representation
Example:
3 Levels of abstraction:
Register
Read
Write
ALU
Add
Sub
AND
Shift
Processor
Mult
Div
Load
Store
Fall 2002
Fall 2002
42
21
Object-Oriented Paradigms
z
Merits
– Support information hiding
– Support inheritance
– Support natural concurrency
z
Demerits
– Not suitable for systems with complicated transformation
functions
Fall 2002
43
Heterogeneous:
Program State Machine (PSM)
Fall 2002
44
22
Program State Machine
z
Merits
– Represent a system’s state, data, control, and activities in a
single model
– Overcome the limitations of programming languages and
HCFSM models
Fall 2002
45
Heterogeneous: Queuing Model
Fall 2002
46
23
Queuing Models
z
Characteristics
– Used for analyzing system’s performance
– Can find utilization, queuing length, throughput, etc.
Fall 2002
47
Codesign Finite State Machine
(CFSM)
z
CFSM is FSM extended with
– Support for data handling
– Asynchronous communication
z
CFSM has
– FSM part
• Inputs, outputs, states, transition and output relation
– Data computation part
• External, instantaneous functions
Fall 2002
48
24
Codesign Finite State Machine
(CFSM)
z
CFSM has:
– Locally synchronous behavior
• CFSM executes based on snap-shot input assignment
• Synchronous from its own perspective
– Globally asynchronous behavior
• CFSM executes in non-zero, finite amount of time
• Asynchronous from system perspective
z
GALS model
– Globally: Scheduling mechanism
– Locally: CFSMs
Fall 2002
49
Network of CFSMs: Depth-1
Buffers
z
Globally Asynchronous, Locally Synchronous (GALS)
model
F
B=>C
C=>F
G
C=>G
C=>G
CFSM1
CFSM1
C=>A
F^(G==1)
C
CFSM2
CFSM2
C
C=>B
A
B
C=>B
(A==0)=>B
CFSM3
Fall 2002
25
Typical DSP Algorithm
z
Traditional DSP
– Convolution/Correlation
– Filtering (FIR, IIR)
– Adaptive Filtering (Varying Coefficient)
– DCT
∞
y[n] = x[n] * h[n] =
∑ x[k ]h[n − k ]
k = −∞
N
M −1
k =1
k =0
y[n] = −∑ ak y[n − k ] + ∑ bk x[n]
N −1
x[k ] = e(k )∑ x[n] cos[
n =0
(2n + 1)kπ
]
2N
Fall 2002
51
Specification of DSP Algorithms
z
Example
–
z
y(n)=a*x(n)+b*x(n-1)+c*x(n-2)
Graphical Representation Method 1: Block Diagram
(Data-path architecture)
– Consists of functional blocks connected with directed edges,
which represent data flow from its input block to its output
block
x(n)
a
x(n-1)
D
b
D
x(n-2)
c
y(n)
Fall 2002
52
26
Graphical Representation Method 2:
Signal-Flow Graph
z
z
z
z
SFG: a collection of nodes and directed edges
Nodes: represent computations and/or task, sum all
incoming signals
Directed edge (j, k): denotes a linear transformation
from the input signal at node j to the output signal at
node k
Linear SFGs can be transformed into different forms
without changing the system functions.
– Flow graph reversal or transposition is one of these
transformations (Note: only applicable to single-input-singleoutput systems)
Fall 2002
53
Signal-Flow Graph
z
z
Usually used for linear time-invariant DSP systems
representation
Example:
z−1
x(n)
a
z−1
b
c
y(n)
Fall 2002
54
27
Graphical Representation Method 3:
Data-Flow Graph
z
z
DFG: nodes represent computations (or functions or
subtasks), while the directed edges represent data
paths (data communications between nodes), each
edge has a nonnegative number of delays associated
with it.
DFG captures the data-driven property of DSP
algorithm: any node can perform its computation
whenever all its input data are available.
D
x(n)
D
b
a
c
y(n)
Fall 2002
55
Data-Flow Graph
z
Each edge describes a precedence constraint
between two nodes in DFG:
– Intra-iteration precedence constraint: if the edge has zero
delays
– Inter-iteration precedence constraint: if the edge has one or
more delays (Delay here represents iteration delays.)
– DFGs and Block Diagrams
can be used to describe both
linear single-rate and nonlinear
multi-rate DSP systems
z
Fine-Grain DFG
D
x(n)
a
D
b
c
y(n)
Fall 2002
56
28
Examples of DFG
z
Nodes are complex blocks (in Coarse-Grain DFGs)
FFT
z
Adaptive
filtering
IFFT
Nodes can describe expanders/decimators in MultiRate DFGs
Decimator
Expander
N samples
N/2 samples
↓2
N/2 samples
↑2
N samples
≡
2
1
≡
1
2
Fall 2002
57
Graphical Representation Method 4:
Dependence Graph
z
z
z
z
Fall 2002
DG contains computations for all iterations in an
algorithm.
DG does not contain delay elements.
Edges represent precedence constraints among
nodes.
Mainly used for systolic array design.
58
29
ARCHITECTURES
Fall, 2001
59
Architecture Models
Southwest Medical Center
Oklahoma City, Oklahoma
"You hear the planned possibilities, but it is nothing like the visual
concept of a model. You get the impact of the complete vision."
Fall 2002
Galyn Fish
Director of PR, Southwest MedicalCenter
60
30
System Level
Design Science
z
Design Methodology:
– Top Down Aspect:
• Orthogonalization of Concerns:
– Separate Implementation from Conceptual Aspects
– Separate computation from communication
• Formalization: precise unambiguous semantics
• Abstraction: capture the desired system details (do not overspecify)
• Decomposition: partitioning the system behavior into simpler behaviors
• Successive Refinements: refine the abstraction level down to the implementation by
filling in details and passing constraints
– Bottom Up Aspect:
• IP Re-use (even at the algorithmic and functional level)
• Components of architecture from pre-existing library
Fall 2002
61
Separate Behavior from Microarchitecture
zSystem
Behavior
zImplementation
Architecture
– Functional specification of
– Hardware and Software
system
– No notion of hardware or
software!
– Optimized Computer
Mem
13
Synch
Control
4
Front
End 1
Transport
Decode 2
Rate
Buffer
5
Rate
Buffer
9
Video
Decode 6
Audio
Decode/
Output 10
MPEG
Frame
Buffer
7
DSP
Processor
External
I/O
Sensor
Video
Output 8
Peripheral
Audio
Decode
Processor Bus
Rate
Buffer
12
User/Sys
Control
3
DSP RAM
Control
Processor
System
RAM
Mem
11
Fall 2002
62
31
Example of System Behavior
Mem
13
User/Sys
Control
3
Rate
Buffer
12
Sensor
Synch
Control
4
Satellite Dish
Rate
Buffer
5
Transport
Decode 2
Front
End 1
Rate
Buffer
9
Cable
remote
Frame
Buffer
7
Video
Decode 6
Video
Output 8
monitor
Audio
Decode/
Output 10
Mem
11
speakers
Fall 2002
IP-Based Design of the System
Behavior
System Integration
Communication Protocol
Designed in Felix
User Interface
Written in C
Mem
13
Testbench
Designed in BONeS
Rate
Buffer
12
Sensor
Synch
Control
4
Satellite Dish
Front
End 1
User/Sys
Control
3
Transport
Decode 2
Rate
Buffer
5
Rate
Buffer
9
Cable
Baseband Processing
Designed in SPW
Transport Decode
Written in C
remote
Video
Decode 6
Audio
Decode/
Output 10
Mem
11
Frame
Buffer
7
Video
Output 8
monitor
speakers
Decoding Algorithms
Designed in SPW
Fall 2002
32
The next level of Abstraction …
IP Block Performance
Inter IP Communication Performance Models
abstract
SDF
Wire Load
abstract
RTL
Gate Level Model
Capacity Load
abstract
Fall 2002
1970’s
cluster
RTL
Clusters
SW
Models
cluster
abstract
Transistor Model
Capacity Load
IP Blocks
cluster
1980’s
1990’s
Year 2000 +
65
IP-Based Design of the Implementation
Which Bus? PI?
AMBA?
Dedicated Bus for
DSP?
DSP
Processor
External
I/O
MPEG
Peripheral
Audio
Decode
Do I need a dedicated Audio Decoder?
Can decode be done on Microcontroller?
Processor Bus
Can I Buy
an MPEG2
Processor?
Which One?
Which DSP
Processor? C50?
Can DSP be done on
Microcontroller?
DSP RAM
Which
Microcontroller?
ARM? HC11?
Control
Processor
System
RAM
How fast will my
User Interface
Software run? How
Much can I fit on my
Microcontroller?
Fall 2002
33
Architectural Choices
Flexibility
Prog Mem
Prog M em
µP
µP
Prog Mem
Sate llite
µP
Dedicated
Logic
Processor
Satellite Satellite
Processor Processor
MAC
Unit
Addr
Gen
General
Purpose
µP
Software
Programmable
DSP
Hardware
Reconfigurable
Processor
Direct
Mapped
Hardware
1/Efficiency (power, speed)
Fall 2002
67
Map Between Behavior and
Architecture
Transport Decode Implemented
as Software Task Running
on Microcontroller
Rate
Buffer
12
User/Sys
Control
3
Sensor
Communication
External
Over Bus
I/O
Synch
Control
4
Front
End 1
Transport
Decode 2
Rate
Buffer
5
Rate
Buffer
9
Video
Decode 6
Audio
Decode/
Output 10
MPEG
Frame
Buffer
7
Video
Output 8
Peripheral
Audio
Decode
DSP
Processor
Processor Bus
Mem
13
DSP RAM
Control
Processor
System
RAM
Mem
11
Audio Decode Behavior
Implemented on
Dedicated Hardware
Fall 2002
34
Classic A/D, HW/SW tradeoff
Digital expanding
DeDe-correlate
(spread spectrum)
e.g.
LO
DeDe-modulate
Analog vs. Digital tradeoff
System Chip DSP
Suppose digital limit is pushed
Custom
DSP
A/D
z
z
DS 11-bit
Modulator
Dec.
Filter
Gen
DSP
1-bit
Modulator
Gen
DSP
1-bit
Modulator
RF Front End
Can trade custom analog for hardware, even for software
– Power, area critical criteria, or easy functional modification
Fall 2002
Example: Voice Mail Pager
Modulation Scheme Choice (e.g. BPSK)
Q
f
P
I
?
DeDe-correlate
(spread spectrum)
e.g.
z
z
DeDe-modulate
Analog vs. Digital tradeoff
?
Gen
DSP
Design considerations cross design layers
Trade-offs require systematic methodology and constraint-based
hierarchical approach for clear justification
Fall 2002
35
Where All is Going
Function/Arch.
Co-Design
Communication-based
Design
Convergence of Paradigms
Analog Platform
Design
Create paradigm shift- not just link methods
zNew
levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF, interfaces, etc- to
exploit heterogeneous nature of components
zLinks already being forged
Fall 2002
71
Deep Submicron Paradigm Shift
2M Transistors
100M Metal
100 MHz
2
Wire RC 1 ns/cm
Virtual Component Based Design
- Minimize Design Time
- Maximize IP Reuse
- Optimize System Level
90%
New
Design
90%
Reused
Design
Cell Based Design
- Minimize Area
- Maximize Performance
- Optimize Gate Level
1991
Fall 2002
40M Transistors
2,000M Metal
2
600 MHz
Wire RC 6 ns/cm
1996
200x
72
36
Implementation Design Trends
Platform Based
Consumer
Wireless
Automotive
EDA
Hierarchical
Microprocessors
High end servers
& W/S
MicroP
Flat Layout
Flat ASIC
Flat ASIC+
Net & Compute
Servers
Base stations
Fall 2002
73
Platform-Based System Architecture
Exploration
Application Space
Level of Abstraction
Function
HW/SW
System Platform
Architecture
RTL - SW
Today
Tomorrow
Mask - ASM
Effort/Value
Fall 2002
Architectural Space
74
37
Digital Wireless Platform
Dedicated Logic
and Memory
Logic
A
D
Accelerators
(bit level)
Timing
recovery
Equalizers
Analog RF
Filters
analog
digital
uC core
(ARM)
Java
phone
book
VM
Keypad,
Display
Control
ARQ
MUD
Adaptive
Antenna
Algorith
ms
DSP core
Source: Berkeley Wireless Research Center
Fall 2002
75
Will the system solution match the
original system spec?
Limitedsynergies
synergiesbetween
betweenHW
HW&&SW
SW
• •Limited
teams
teams
Longcomplex
complexflows
flowsininwhich
whichteams
teams
• •Long
donot
notreconcile
reconcileefforts
effortsuntil
untilthe
theend
end
do
Highdegree
degreeofofrisk
riskthat
thatdevices
deviceswill
will
• •High
befully
fullyfunctional
functional
be
Concept
• Development
• Verification
• System Test
?
Software
VCXO
Tx
Optics
Synth/
MUX
Rx
CDR/
Optics DeMUX
Hardware
• IP Selection
• Design
• Verification
Clock
Select
STM
I/F
Line
STS
OHP
Cell/
I/F
STS XC SPE Data Packet
Map Framer
PP
I/F
mP
Fall 2002
76
38
EDA Challenge to Close the Gap
Level of Abstraction
Behavior
Design Entry Level
SW/HW
RTL
Industryaveraging
averaging2-3
2-3iterations
iterations
••Industry
SoCdesign
design
SoC
Needtotoidentify
identifydesign
designissues
issuesearlier
earlier
••Need
Gapbetween
betweenconcept
conceptand
andlogical
logical/ /
••Gap
Physicalimplementation
implementation
Physical
Concept to
Reality
Gap
Gate Level “Platform”
Historical EDA Focus
Silicon
Impact of Design Change
(Effort/Cost)
FallSource:
2002 GSRC
77
AMBA-Based SoC Architecture
Fall 2002
78
39
LANGUAGES
Fall, 2001
79
Languages
z
Hardware Description Languages
– VHDL / Verilog / SystemVerilog
z
Software Programming Languages
– C / C++ / Java
z
Architecture Description Languages
– EXPRESSION / MIMOLA / LISA
z
System Specification Languages
– SystemC / SLDL / SDL / Esterel
z
Verification Languages
– PSL (Sugar, OVL) / OpenVERA
Fall 2002
80
40
Hardware Description Languages
(HDL)
z
VHDL (IEEE 1076)
z
Verilog 1.0 (IEEE 1364)
z
Verilog 2.0 (IEEE 1364)
z
SystemVerilog 3.0 (to be sent for IEEE review)
z
SystemVerilog 3.1 (to be sent for IEEE review)
Fall 2002
81
SystemVerilog 3.0
z
Built-in C types
z
Synthesis improvements (avoid simulation and
synthesis mismatches)
z
Enhanced design verification
– procedural assertions
z
Improved modeling
– communication interfaces
Fall 2002
82
41
SystemVerilog 3.1
z
Testbench automation
– Data structures
– Classes
– Inter-process communication
– Randomization
z
Temporal assertions
– Monitors
– Coverage Analysis
Fall 2002
83
SystemVerilog Environment for
Ethernet MAC
Fall 2002
84
42
Architecture Description
Language in SOC Codesign Flow
Design
Specification
Estimators
Architecture
Description
Language
IP Library
M1
P2
P1
Hw/Sw Partitioning
HW
Verification
SW
VHDL, Verilog
C
Synthesis
Compiler
Cosimulation
On-Chip
Memory
Rapid design space exploration
Quality tool-kit generation
Processor
Core
Off-Chip
Memory
Synthesized
HW
Design reuse
Interface
Fall 2002
85
Architecture Description
Languages
Objectives for Embedded SOC
Support automated SW toolkit generation
exploration quality SW tools (performance estimator, profiler, …)
production quality SW tools (cycle-accurate simulator, memory-aware compiler..)
Compiler
ADL
Architecture
Description
Architecture
Model
Compiler
File
Simulator
Synthesis
Formal Verification
Specify a variety of architecture classes (VLIWs, DSP, RISC, ASIPs…)
Specify novel memory organizations
Specify pipelining and resource constraints
Fall 2002
86
43
Architecture Description Languages
z
Behavior-Centric ADLs (primarily capture Instruction Set (IS))
ISPS, nML, ISDL, SCP/ValenC, ...
good for regular architectures, provides programmer’s view
tedious for irregular architectures, hard to specify pipelining, implicit arch model
z
Structure-Centric ADLs (primarily capture architectural structure)
MIMOLA, ...
can drive code generation and architecture synthesis, can specify detailed
pipelining
hard to extract IS view
z
Mixed-Level ADLs (combine benefits of both)
LISA, RADL, FLEXWARE, MDes, …
contains detailed pipelining information
most are specific to single processor class and/or memory architecture
most generate either simulator or compiler but not both
Fall 2002
87
EXPRESSION ADL
Verification
Feedback
Processor
Libraries
ASIP
Exploration
Simulator
Toolkit
Generator
DSP
Profiler
Exploration
Compiler
VLIW
EXPRESSION
ADL
Memory Libraries
Cache
SRAM
Prefetch
Buffer
Frame
Buffer
Exploration Phase
Application
Refinement Phase
Retargetable
Compiler
Toolkit
Generator
Profiler
Retargetable
Simulator
EDO
On-chip
RD RAM
SD RAM
Feedback
Fall 2002
88
44
SystemC History
Synopsys
VSIA SLD
Data Types
Spec (draft)
Synopsys
ATG
SystemC
v0.90
Sep. 99
“Scenic”
UC
Irvine
1996
Synopsys
“Fridge”
Frontier Design
Fixed Point
Types
A/RT Library
1991
imec
1992
CoWare
SystemC
v1.0
Apr. 00
Abstract
Protocols
“N2C”
1997
SystemC
v1.1
Jun. 00
Fall 2002
89
SystemC Highlights
z
Features as a codesign language
– Modules
– Processes
– Ports
– Signals
– Rich set of port and
signal types
– Rich set of data
types
Fall 2002
– Clocks
– Cycle-based simulation
– Multiple abstraction levels
– Communication protocols
– Debugging support
– Waveform tracing
90
45
Current
System Design Methodology
C/C++
System Level Model
Refine
Analysis
Results
Manual Conversion
VHDL/Verilog
Simulation
Synthesis
Rest of Process
Fall 2002
91
Current System Design Methodology
(cont’d)
z
Problems
– Errors in manual conversion from C to HDL
– Disconnect between system model and HDL model
– Multiple system tests
Fall 2002
92
46
SystemC Design Methodology
SystemC Model
Simulation
Refinement
Synthesis
Rest of Process
Fall 2002
93
SystemC Design Methodology
(cont’d)
z
Advantages
– Refinement methodology
– Written in a single language
– Higher productivity
– Reusable testbenches
Fall 2002
94
47
SystemC Programming Model
z
Mod 1
Mod 2
z
Mod 3
A set of modules
interacting through
signals.
Module functionality is
described by
processes.
Fall 2002
95
SystemC programming model
(cont’d)
z
System (program) debug/validation
– Testbench
• Simulation, Waveform view of signals
– Normal C++ IDE facilities
• Watch, Evaluate, Breakpoint, ...
z
sc_main() function
– instantiates all modules
– initializes clocks
– initializes output waveform files
– starts simulation kernel
Fall 2002
96
48
A Simple Example:
Defining a Module
z
Complex-number Multiplier
(a+bi)*(c+di) = (ac-bd)+(ad+bc)i
a
b
c
d
SC_MODULE(cmplx_mult) {
sc_in<int> a,b;
sc_in<int> c,d;
e
Complex
Multiplier
f
(cmplx_mult)
sc_out<int> e,f;
...
}
Fall 2002
97
A Simple Example:
Defining a Module (cont’d)
SC_MODULE(cmplx_mult) {
sc_in<int> a,b;
sc_in<int> c,d;
void cmplx_mult::calc()
{
e = a*c-b*d;
f = a*d+b*c;
sc_out<int> e,f;
void calc();
}
SC_CTOR(cmplx_mult) {
SC_METHOD(calc);
sensitive<<a<<b<<c<<d;
}
}
Fall 2002
98
49
Completing the Design
M1
a
b
M2
input_gen
c
d
Complex
Multiplier
e
f
M3
display
Clk.signal()
clk
Fall 2002
99
Completing the Design:
input_gen module
SC_MODULE(input_gen) {
sc_in<bool> clk;
sc_out<int> a,b;
sc_out<int> c,d;
void
input_gen::generate()
{
int a_val=0, c_val=0;
void generate();
while (true) {
a = a_val++;
wait();
c = (c_val+=2);
wait();
}
SC_CTOR(input_gen) {
SC_THREAD(generate);
sensitive_pos(clk);
}
}
}
Fall 2002
100
50
Completing the Design:
display module
SC_MODULE(display) {
sc_in<int> e,f;
void display::show()
{
void show();
SC_CTOR(display) {
SC_METHOD(show);
sensitive<<e<<f;
}
cout<<e<<‘+’<<f<<“i\n
”;
}
}
Fall 2002
101
Putting it all together:
sc_main function
#include <systemc.h>
int sc_main()
M2.a(a); M2.b(b);
M2.c(c); M2.d(d);
M2.e(e); M2.f(f);
{
M3.e(e); M3.f(f);
input_gen M1(“I_G”);
cmplx_mult M2(“C_M”);
display
M3(“D”);
sc_signal<int>
a,b,c,d,e,f;
sc_clock
clk(“clk”,20,0.5);
sc_start(100);
return 0;
}
M1.clk(clk.signal());
M1.a(a); M1.b(b);
M1.c(c); M1.d(d);
Fall 2002
102
51
Fall 2002
103
Fall 2002
104
52
Fall 2002
105
Property Specification Language
(PSL)
z
z
z
Accellera: a non-profit organization for standardization
of design & verification languages
PSL = IBM Sugar + Verplex OVL
System Properties
– Temporal Logic for Formal Verification
z
Design Assertions
– Procedural (like SystemVerilog assertions)
– Declarative (like OVL assertion monitors)
z
For:
– Simulation-based Verification
– Static Formal Verification
– Dynamic Formal Verification
Fall 2002
106
53
