Models, Architectures

and Languages

1
Models, Architectures, Languages
 Introduction
 Models
– State, Activity, Structure, Data, Heterogeneous
 Architectures
– Function-Architecture, Platform-Based
 Languages
– Hardware: VHDL / Verilog / SystemVerilog
– Software: C / C++ / Java
– System: SystemC / SLDL / SDL
– Verification: PSL (Sugar, OVL)

2
Models, Architectures, Languages
INTRODUCTION

3
Design Methodologies
 Capture-and-Simulate
– Schematic Capture
– Simulation
 Describe-and-Synthesize
– Hardware Description Language
– Behavioral Synthesis
– Logic Synthesis
 Specify-Explore-Refine
– Executable Specification
– Hardware-Software Partitioning
– Estimation and Exploration
– Specification Refinement

4
Motivation

5
Models & Architectures

Specification + Models
Constraints (Specification
)
Design
Process

Implementation Architectures
(Implementation)

Models are conceptual views of the system’s functionality

Architectures are abstract views of the system’s implementation
6
Behavior Vs.
Architecture Performance models:
Emb. SW, comm. and
Models of
comp. resources
Computatio
n 1
System System 2
Behavior ArchitectureHW/SW
partitioning,
Behavior
Simulation
Mapping Scheduling
3
Performance
Simulation SW estimation
Synthesis
Communication
Refinement
4
Flow To Implementation

7
Models of an Elevator Controller

8
Architectures Implementing the
Elevator Controller

9
Current Abstraction Mechanisms in
Hardware Systems
Abstraction
The level of detail contained within the system model
 A system can be modeled at
– 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.

10
 Abstractions in Modeling:
Hardware Systems

Level Behavior Structure Physical

Start here

PMS (System) Communicating Processors Cabinets, Cables

Processes Memories
Switches (PMS)

Instruction Set Input-Output Memory, Ports Board

(Algorithm) Processors Floorplan

Register- Register ALUs, Regs, ICs

Transfer Transfers Muxes, Bus Macro Cells
Work to
Logic Logic Eqns. Gates, Flip-flops Std. cell layout here

Circuit Network Eqns. Trans., Connections Transistor layout

© IEEE 1990 [McFarland90]

11
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

12
Abstractions for
Software Systems

Virtual Machine Hierarchy

 Application Programs
 Utility Programs
 Operating System
 Monitor
 Machine Language
 Microcode
 Logic Devices

13
MODELS

14
Unified HW/SW Representation

 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

15
Abstract Hardware-Software Model

Unified representation of system allows early

performance analysis

General
Performance
Evaluation

Abstract Evaluation
Identification
HW/SW of Design
of Bottlenecks
Model Alternatives

Evaluation
of HW/SW
Trade-offs

16
HW/SW System Models

 State-Oriented Models
– Finite-State Machines (FSM), Petri-Nets (PN), Hierarchical
Concurrent FSM
 Activity-Oriented Models
– Data Flow Graph, Flow-Chart
 Structure-Oriented Models
– Block Diagram, RT netlist, Gate netlist
 Data-Oriented Models
– Entity-Relationship Diagram, Jackson’s Diagram
 Heterogeneous Models
– UML (OO), CDFG, PSM, Queuing Model, Programming
Language Paradigm, Structure Chart

17
State-Oriented: Finite-State Machine
(Mealy Model)

18
State-Oriented: Finite State Machine
(Moore Model)

19
State-Oriented: Finite State Machine with
Datapath (FSMD)

20
Finite State Machines
 Merits
– Represent system’s temporal behavior explicitly

– Suitable for control-dominated systems

– Suitable for formal verification

 Demerits
– Lack of hierarchy and concurrency

– State or arc explosion when representing complex

systems

21
State-Oriented: Petri Nets

 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 Token
Places

Transition

Output
Place
22
State-Oriented: Petri Nets

23
Petri Nets
 Merits
– Good at modeling and analyzing concurrent systems

– Extensive theoretical and experimental works

– Used extensively for protocol engineering and control system

modeling

 Demerits
– “Flat Model” that becomes incomprehensible when system
complexity increases

24
State-Oriented:
Hierarchical Concurrent FSM

25
Hierarchical Concurrent FSM
 Merits
– Support both hierarchy and concurrency

– Good for representing complex systems

 Demerits
– Concentrate only on modeling control aspects and not data
and activities

26
Activity-Oriented:
Data Flow Graphs (DFG)

27
Data Flow Graphs
 Merits
– Support hierarchy

– Suitable for specifying complex transformational systems

– Represent problem-inherent data dependencies

 Demerits
– Do not express control sequencing or temporal behaviors

– Weak for modeling embedded systems

28
Activity-Oriented: Flow Charts

29
Flow Charts
 Merits
– Useful to represent tasks governed by control flows

– Can impose an order to supersede natural data

dependencies

 Demerits
– Used only when the system’s computation is well known

30
Structure-Oriented:
Component Connectivity Diagrams

31
Component Connectivity Diagrams
 Merits
– Good at representing system’s structure

 Demerits
– Behavior is not explicit

 Characteristics
– Used in later phases of design

32
Data-Oriented:
Entity-Relationship Diagram

33
Entity-Relationship Diagrams
 Merits
– Provide a good view of the data in a system

– Suitable for representing complex relationships among

various kinds of data

 Demerits
– Do not describe any functional or temporal behavior of a
system

34
Data-Oriented:
Jackson’s Diagram

35
Jackson’s Diagrams
 Merits
– Suitable for representing data having a complex composite
structure

 Demerits
– Do not describe any functional or temporal behavior of the
system

36
Heterogeneous:
Control/Data Flow Graphs (CDFG)
 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 X 4 Y
Example:
+ + Control Step 1

+ Control Step 2

+ Control Step 3

37
Control/Data Flow Graphs
 Merits
– Correct the inability to represent control dependencies in DFG

– Correct the inability to represent data dependencies in CFG

 Demerits
– Low level specification (behavior not evident)

38
Heterogeneous: Structure Chart

39
Structure Charts
 Merits
– Represent both data and control

 Demerits
– Used in the preliminary stages of system design

40
Heterogeneous:
Object-Oriented Paradigms (UML, …)
 Use techniques previously applied to software to
manage complexity and change in hardware modeling
 Use OO concepts such as
– Data abstraction
– Information hiding
– Inheritance
 Use building block approach to gain OO benefits
– Higher component reuse
– Lower design cost
– Faster system design process
– Increased reliability

41
 Heterogeneous:
Object-Oriented Paradigms (UML, …)
Object-Oriented Representation

Example:

3 Levels of abstraction:

Register ALU Processor

Read Add Mult

Sub Div
Write AND Load
Shift Store

42
43
Object-Oriented Paradigms
 Merits
– Support information hiding

– Support inheritance

– Support natural concurrency

 Demerits
– Not suitable for systems with complicated transformation
functions

44
Heterogeneous:
Program State Machine (PSM)

45
Program State Machine
 Merits
– Represent a system’s state, data, control, and activities in a
single model

– Overcome the limitations of programming languages and

HCFSM models

46
Heterogeneous: Queuing Model

47
Queuing Models
 Characteristics
– Used for analyzing system’s performance

– Can find utilization, queuing length, throughput, etc.

48
Codesign Finite State Machine
(CFSM)
 CFSM is FSM extended with
– Support for data handling

– Asynchronous communication

 CFSM has
– FSM part

• Inputs, outputs, states, transition and output relation

– Data computation part

• External, instantaneous functions

49
Codesign Finite State Machine
(CFSM)
 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

 GALS model
– Globally: Scheduling mechanism

– Locally: CFSMs

50
 Network of CFSMs: Depth-1
Buffers
 Globally Asynchronous, Locally Synchronous (GALS)
model

F B=>C
C=>F

C=>G
C=>G G
F^(G==1)

C=>A
C CFSM2
CFSM1
CFSM1 CFSM2
C

C=>B
A
B
C=>B
(A==0)=>B

CFSM3

51
Typical DSP Algorithm
 Traditional DSP
– Convolution/Correlation

– Filtering (FIR, IIR) 

y[n]  x[n] * h[n]   x[k ]h[n  k ]
k 
– Adaptive Filtering (Varying Coefficient)
N M 1
y[n]   ak y[n  k ]   bk x[n]
– DCT k 1 k 0

N1
(2n  1)k
x[k ] e(k ) x[n] cos[ ]
n 0 2N

52
 Specification of DSP Algorithms
 Example
– 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) x(n-1) x(n-2)

D D

a b c

y(n)

53
Graphical Representation Method 2:
Signal-Flow Graph
 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-single-
output systems)

54
Signal-Flow Graph
 Usually used for linear time-invariant DSP systems
representation
 Example:

x(n) z 1 z 1
a b c
y(n)

55
Graphical Representation Method 3:
Data-Flow Graph
 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.

x(n) D D

a b c

y(n)

56
Data-Flow Graph
 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
x(n) D D
 Fine-Grain DFG
a b c

y(n)

57
Examples of DFG
 Nodes are complex blocks (in Coarse-Grain DFGs)

Adaptive
FFT IFFT
filtering

 Nodes can describe expanders/decimators in Multi-

Rate DFGs
Decimator N samples
2 N/2 samples
 2 1

Expander N/2 samples

2 N samples
 1 2
58
Graphical Representation Method 4:
Dependence Graph
 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.

59
ARCHITECTURES

60
 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."
Galyn Fish
Director of PR, Southwest MedicalCenter
61
 System Level
Design Science
 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

62
 Separate Behavior from Micro-
architecture
System Behavior Implementation Architecture
– Functional specification of – Hardware and Software
system – Optimized Computer
– No notion of hardware or
software!
Mem
13

User/Sys External DSP

Rate
Buffer
Control
3 Sensor I/O Processor

Processor Bus
12
Synch
Control
4
MPEG DSP RAM
Rate Frame
Transport Video Video
Front Buffer Buffer
Decode 6 Output 8
End 1 Decode 2 5 7
Peripheral Control
Rate
Processor
Buffer Audio
9 Decode/ Audio System
Output 10 Decode
RAM
Mem
11

63
Example of System Behavior

Mem
13

User/Sys
Rate Control
Buffer 3 Sensor
12
Synch
Control remote
Satellite Dish 4

Rate Frame
Transport Video Video
Front Buffer Buffer
Decode 2 Decode 6 Output 8
End 1 5 7

Rate
Buffer Audio monitor
9 Decode/
Cable
Output 10

Mem
11 speakers

64
IP-Based Design of the System
Behavior
System Integration
Communication Protocol
Designed in Felix

Mem User Interface

Testbench 13 Written in C
Designed in BONeS User/Sys
Rate Control
Buffer 3 Sensor
12
Synch
Control remote
Satellite Dish 4

Rate Frame
Transport Video Video
Front Buffer Buffer
Decode 2 Decode 6 Output 8
End 1 5 7

Rate
Buffer Audio monitor
9 Decode/
Cable Output 10

Mem
Baseband Processing 11
speakers
Designed in SPW

Transport Decode Decoding Algorithms

Written in C Designed in SPW

65
The next level of Abstraction …
IP Block Performance IP Blocks
Inter IP Communication Performance Models

SDF

abstract
Wire Load

RTL
RTL SW

abstract
Gate Level Model cluster Clusters Models
Capacity Load

Transistor Model cluster

Capacity Load
abstract

cluster
abstract

1970’s 1980’s 1990’s Year 2000 + 66

IP-Based Design of the Implementation
Which Bus? PI? Which DSP
AMBA? Processor? C50?
Dedicated Bus for Can DSP be done on
DSP? Microcontroller?

Can I Buy External DSP

an MPEG2 I/O Processor
Which
Processor? Microcontroller?

Processor Bus
Which One? MPEG DSP RAM ARM? HC11?

Peripheral Control
Processor
Audio System How fast will my
Decode User Interface
RAM
Software run? How
Much can I fit on my
Do I need a dedicated Audio Decoder?
Microcontroller?
Can decode be done on Microcontroller?

67
 Architectural Choices
Prog Mem
Flexibility

Prog M em
P P
Prog Mem
Sate llite MAC Addr General
P Unit Gen Purpose
Processor P

Satellite Satellite Software

Programmable
Processor Processor
Dedicated DSP
Hardware
Logic Reconfigurable
Processor

Direct
Mapped
Hardware

1/Efficiency (power, speed)

68
 Map Between Behavior and
Architecture
Transport Decode Implemented
as Software Task Running
on Microcontroller
Mem
13

User/Sys
Communication DSP
Rate External
Buffer
Control
3 Sensor Over Bus I/O Processor
12

Processor Bus
Synch
Control
4
MPEG DSP RAM
Rate Frame
Transport Video Video
Front Buffer Buffer
Decode 2 Decode 6 Output 8
End 1 5 7
Peripheral Control
Rate Processor
Buffer Audio
9 Decode/ Audio System
Output 10
Decode
RAM
Mem
11

Audio Decode Behavior

Implemented on
Dedicated Hardware

69
 Classic A/D, HW/SW tradeoff
Digital expanding

De-correlate
De-modulate
(spread spectrum)

e.g. Analog vs. Digital tradeoff

LO

System Chip DSP

Suppose digital limit is pushed

Custom DS 1-bit Dec. Gen 1-bit Gen 1-bit

A/D
DSP Modulator Filter DSP Modulator DSP Modulator

 RF Front End
 Can trade custom analog for hardware, even for software
– Power, area critical criteria, or easy functional modification

70
Example: Voice Mail Pager

Modulation Scheme Choice (e.g. BPSK)

f
P I

? De-correlate
De-modulate
(spread spectrum)
Gen
e.g. ? DSP
Analog vs. Digital tradeoff

 Design considerations cross design layers

 Trade-offs require systematic methodology and constraint-based hierarchical approach for
clear justification
71
 Where All is Going

Function/Arch.
Communication-based
Co-Design
Design

Convergence of Paradigms

Analog Platform
Design

Create paradigm shift- not just link methods

New levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF, interfaces, etc-
to exploit heterogeneous nature of components
Links already being forged

72
Deep Submicron Paradigm Shift

2M Transistors 40M Transistors

100M Metal 2,000M Metal
100 MHz 2 600 MHz 2
Wire RC 1 ns/cm Wire RC 6 ns/cm

Virtual Component Based Design

- Minimize Design Time
90% - Maximize IP Reuse
- Optimize System Level 90%
New
Reused
Design Cell Based Design
Design
- Minimize Area
- Maximize Performance
- Optimize Gate Level

1991 1996 200x

73
Implementation Design Trends
Platform Based
Consumer
Wireless
Automotive
EDA
Hierarchical
Microprocessors
MicroP High end servers
& W/S

Flat Layout
Net & Compute
Flat ASIC Flat ASIC+ Servers
Base stations

74
Platform-Based System Architecture
Exploration
Application Space
Function
Level of Abstraction

HW/SW

Architecture System Platform

RTL - SW

Today Tomorrow

Mask - ASM Architectural Space

Effort/Value
75
 Digital Wireless Platform

Dedicated Logic uC core

and Memory (ARM)

Java
phone
Keypad,
Logic Accelerators VM
book Display

(bit level)
Control ARQ
A
Timing
D recovery Equalizers MUD

Analog RF Adaptive
Filters Antenna
Algorithm
analog digital s

DSP core

Source: Berkeley Wireless Research Center

76
 Will the system solution match the
original system spec?
• •Limited
Limitedsynergies
synergiesbetween
betweenHW HW&&SWSW
teams
teams
Concept • •Long
Longcomplex
complexflows
flowsininwhich
whichteams
teams
donot
do notreconcile
reconcileefforts
effortsuntil
untilthe
theend
end
• •High
Highdegree
degreeofofrisk
riskthat
thatdevices
deviceswill
will
befully
be fullyfunctional
functional

• Development
• Verification
• System Test
Software
? Hardware
• IP Selection
• Design
• Verification

Clock
VCXO
Select

Tx Synth/ STM
Optics MUX I/F
Line STS
OHP Cell/
Rx CDR/ I/F STS XC SPE Data Packet
Optics DeMUX PP Map Framer
I/F

mP

77
 EDA Challenge to Close the Gap

Behavior ••Industry
Industryaveraging
averaging2-3
2-3iterations
iterations
SoCdesign
SoC design
Design Entry Level ••Need
Needtotoidentify
identifydesign
designissues
issuesearlier
earlier
Level of Abstraction

SW/HW ••Gap
Gapbetween
betweenconcept
conceptand
andlogical
logical/ /
Concept to Physicalimplementation
Physical implementation
Reality
Gap

RTL Gate Level “Platform”

Historical EDA Focus

Silicon

Impact of Design Change

(Effort/Cost)

Source: GSRC 78
AMBA-Based SoC Architecture

79
LANGUAGES

80
Languages
 Hardware Description Languages
– VHDL / Verilog / SystemVerilog
 Software Programming Languages
– C / C++ / Java
 Architecture Description Languages
– EXPRESSION / MIMOLA / LISA
 System Specification Languages
– SystemC / SLDL / SDL / Esterel
 Verification Languages
– PSL (Sugar, OVL) / OpenVERA

81
Hardware Description Languages
(HDL)
 VHDL (IEEE 1076)
 Verilog 1.0 (IEEE 1364)
 Verilog 2.0 (IEEE 1364)
 SystemVerilog 3.0 (to be sent for IEEE review)
 SystemVerilog 3.1 (to be sent for IEEE review)

82
SystemVerilog 3.0
 Built-in C types
 Synthesis improvements (avoid simulation and
synthesis mismatches)
 Enhanced design verification
– procedural assertions

 Improved modeling
– communication interfaces

83
SystemVerilog 3.1
 Testbench automation
– Data structures

– Classes

– Inter-process communication

– Randomization

 Temporal assertions
– Monitors

– Coverage Analysis

84
SystemVerilog Environment for
Ethernet MAC

85
 Architecture Description
Language in SOC Codesign Flow
Design Architecture IP Library

Specification Estimators Description

Language M1
P2
P1

Hw/Sw Partitioning

HW SW
Verification
VHDL, Verilog
C

Synthesis Compiler

Cosimulation
Rapid design space exploration

On-Chip
Memory
Processor Quality tool-kit generation
Core

Off-Chip
Memory Design reuse
Synthesized
HW Interface

86
 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

Simulator
Architecture
ADL Model
Architecture
Compiler Synthesis
Description
File
Formal Verification

 Specify a variety of architecture classes (VLIWs, DSP, RISC, ASIPs…)

 Specify novel memory organizations
 Specify pipelining and resource constraints
87
 Architecture Description Languages
 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
 Structure-Centric ADLs (primarily capture architectural structure)
MIMOLA, ...
 can drive code generation and architecture synthesis, can specify detailed
pipelining
 hard to extract IS view
 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

88
 EXPRESSION ADL

Verification Feedback

Processor
Libraries Exploration
ASIP Simulator
Toolkit Profiler
Generator
DSP Exploration
Compiler
VLIW
EXPRESSION Exploration Phase
ADL
Application
Memory Libraries Refinement Phase
Cache SRAM
Retargetable
Prefetch Frame Compiler
Toolkit
Buffer Buffer
Generator Profiler
EDO Retargetable
On-chip Simulator
RD RAM

SD RAM

Feedback

89
SystemC History
VSIA SLD
Data Types
Spec (draft)
Synopsys
Synopsys SystemC
ATG
“Scenic” v0.90
UC Sep. 99
Synopsys
Irvine
“Fridge”
1996 SystemC
Frontier Design Fixed v1.0
Apr. 00
A/RT Library Point
1991 Types
SystemC
imec CoWare Abstract
v1.1
“N2C” Protocols
1992 1997 Jun. 00
90
SystemC Highlights

 Features as a codesign language

– Modules
– Clocks
– Processes
– Cycle-based simulation
– Ports
– Multiple abstraction levels
– Signals
– Communication protocols
– Rich set of port and
– Debugging support
signal types
– Waveform tracing
– Rich set of data
types

91
Current
System Design Methodology

C/C++
System Level Model Manual Conversion

Refine Analysis VHDL/Verilog

Simulation
Results

Synthesis

Rest of Process
92
Current System Design Methodology
(cont’d)
 Problems
– Errors in manual conversion from C to HDL

– Disconnect between system model and HDL model

– Multiple system tests

93
SystemC Design Methodology

SystemC Model

Simulation

Refinement

Synthesis

Rest of Process

94
SystemC Design Methodology
(cont’d)
 Advantages
– Refinement methodology

– Written in a single language

– Higher productivity

– Reusable testbenches

95
SystemC Programming Model

 A set of modules
interacting through
Mod 1 Mod 2 signals.
 Module functionality is
described by
processes.
Mod 3

96
SystemC programming model
(cont’d)
 System (program) debug/validation
– Testbench
• Simulation, Waveform view of signals

– Normal C++ IDE facilities

• Watch, Evaluate, Breakpoint, ...

 sc_main() function
– instantiates all modules

– initializes clocks

– initializes output waveform files

– starts simulation kernel

97
A Simple Example:
Defining a Module
 Complex-number Multiplier
(a+bi)*(c+di) = (ac-bd)+(ad+bc)i

a SC_MODULE(cmplx_mult) {
b sc_in<int> a,b;
Complex e sc_in<int> c,d;
Multiplier f sc_out<int> e,f;
c (cmplx_mult)
d ...
}

98
A Simple Example:
Defining a Module (cont’d)

SC_MODULE(cmplx_mult) { void cmplx_mult::calc()

sc_in<int> a,b;
{
sc_in<int> c,d;
e = a*c-b*d;
sc_out<int> e,f; f = a*d+b*c;
void calc(); }
SC_CTOR(cmplx_mult) {
SC_METHOD(calc);
sensitive<<a<<b<<c<<d;
}
}

99
 Completing the Design

a
M1 b M2 M3
e
c f
Complex
input_gen d Multiplier display

Clk.signal()

clk

100
Completing the Design:
input_gen module

SC_MODULE(input_gen) { void
sc_in<bool> clk; input_gen::generate()
sc_out<int> a,b;
{
sc_out<int> c,d;
int a_val=0, c_val=0;
void generate();
while (true) {
SC_CTOR(input_gen) { a = a_val++;
wait();
SC_THREAD(generate); c = (c_val+=2);
wait();
sensitive_pos(clk); }
}
}
}

101
Completing the Design:
display module

SC_MODULE(display) { void display::show()

sc_in<int> e,f;
{
void show();
cout<<e<<‘+’<<f<<“i\
SC_CTOR(display) { n”;
SC_METHOD(show);
}
sensitive<<e<<f;
}
}

102
Putting it all together:
sc_main function

#include <systemc.h> M2.a(a); M2.b(b);

M2.c(c); M2.d(d);
int sc_main() M2.e(e); M2.f(f);
{ M3.e(e); M3.f(f);
input_gen M1(“I_G”);
cmplx_mult M2(“C_M”); sc_start(100);
display M3(“D”); return 0;
sc_signal<int> }
a,b,c,d,e,f;
sc_clock
clk(“clk”,20,0.5);
M1.clk(clk.signal());
M1.a(a); M1.b(b);
M1.c(c); M1.d(d);

103
104
105
106
Property Specification Language
(PSL)
 Accellera: a non-profit organization for standardization
of design & verification languages
 PSL = IBM Sugar + Verplex OVL
 System Properties
– Temporal Logic for Formal Verification
 Design Assertions
– Procedural (like SystemVerilog assertions)
– Declarative (like OVL assertion monitors)
 For:
– Simulation-based Verification
– Static Formal Verification
– Dynamic Formal Verification

107