System Modeling & HW/SW

Co-Verification

Prof. Chien-Nan Liu

TEL: 03-4227151 ext:4534
Email: [email protected]

1
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
2
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
3
Design Challenges

Reference http://www.doulos.com 4
 Silicon complexity v.s Software complexity

Silicon complexity is growing 10x Software in systems is growing faster

every 6 years than 10x every 6 years

Reference http://www.doulos.com 5
Increasing Complexity in SoC Designs

l One or more processors

l 32-bit Microcontrollers
l DSPs or specialized media processors
l On-chip memory
l Special function blocks
l Peripheral control devices
l Complex on-chip communications network (On-chip
busses)
l RTOS and embedded software which are layering
architecture
l ……

6
How to Conquer the Complexity ?
l Modeling strategies
– Using the appropriate modeling for different levels
– The consistency and accuracy of the model
l Reuse existing designs
– IP reuse
– Architecture reuse (A platform based design)
l Partition
– Based on functionality
– Hardware and software

7
Traditional System Design Flow (1/2)

l Designers partition the system into hardware and

software early in the flow
l HW and SW engineers design their respective
components in isolation
l HW and SW engineers do not talk to each other
l The system may not be the suitable solution
l Integration problems
l High cost and long iteration

8
 Traditional System Design Flow (2/2)
SystemLevel
nnSystem LevelDesign
Design
Hardwareand
nnHardware andSoftware
Software
AlgorithmDevelopment
nnAlgorithm Development
ProcessorSelection
nnProcessor Selection
Donemainly
nnDone mainlyininC/C++
C/C++
C/C++Environment
C/C++ Environment

ICDevelopment
nnIC Development Verification Process SoftwareDesign
wwSoftware Design
Hardware
nnHardware CodeDevelopment
wwCode Development
Implementation
nnImplementation RTOSdetails
wwRTOS details
Decisions
nnDecisions $$$ Donemainly
wwDone mainlyininC/C++
C/C++
Donemainly
nnDone mainlyininHDL
HDL
EDAEnvironment
EDA Environment C/C++Environment
C/C++ Environment

Reference : Synopsys
9
 Typical Project Schedule

System Design

Hardware Design

Prototype Build

Hardware Debug

Software Design

Software Coding

Software Debug

Reference : Mentor Graphic Project Complete

10
 Former Front-End Design Flow

C/C++ Convert by Hand

C/C++System
System
Level
LevelModel
Model

Verilog
Verilog
Verilog
Testbench
Testbench
Analysis
Analysis

Simulation
Simulation
Results
Results
Refine

Synthesis
Synthesis

Reference : DAC 2002 SystemC Tutorial

11
Problems with the Design Flow

C/C++ Convert by Hand

C/C++System
System
Level
LevelModel
Model

Verilog
Verilog
Verilog
Testbench
Testbench
Analysis
Analysis

Not reusable
Simulation
Simulation
Results
Results
Refine

Synthesis
Synthesis
˝ Not done by designers
˝ The netlist is not preserved

Reference : DAC 2002 SystemC Tutorial

12
Shortcoming of Current System Design
Flow
l Use natural language to describe the system
specification
– Cannot verify the desired functions directly
l Require many experts in system architecture for
the partition of software and hardware parts
– The partition may not be the optimal solution
l Hardware designers have to restart the design
process by capturing the designs using the HDLs
– May have unmatched problems
l Hardware and software integration is often painful
– Hardware and software cannot work together
– Co-verification of hardware and software is inefficient
13
Concurrent HW/SW Design
l Can provide a significant performance
improvement for embedded system design
– Allows earlier architecture closure
– Reduce risk by 80%
l Allows HW/SW engineering groups to talk
together
l Allows earlier HW/SW Integration
l Reduce design cycle
– Develop HW/SW in parallel
– 100x faster than RTL

14
Project Schedule with HW/SW Co-design

System Design

Hardware Design

Prototype Build

Hardware Debug

Software Design

Software Coding

Software Debug

Reference : Mentor Graphic

Project Complete

15
Modern System Design Flow
Specification of the System

System Level Modeling

Hardware and Software

Partitioning

Architectural Exploration

H/W Model S/W Model

H/W Design Flow S/W Development

Integration and Verification

16
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
17
Motivation to Use a Modeling Language

l The increasing system design complexity

l The demand of higher level abstraction and
modeling
l Traditional HDLs (verilog, VHDL, etc) are
suitable for system level design
– Lack of software supports
l To enable an efficient system design flow

18
Requirements of a System Design Language

l Support system models at various levels of

abstraction
l Incorporation of embedded software portions
of a complex system
– Both models and implementation-level code
l Creation of executable specifications of
design intent
l Creation of executable platform models
– Represent possible implementation architectures
on which the design intent will be mapped

19
Requirements of a System Design Language

l Fast simulation speed to enable design-space

exploration
– Both functional specification and architectural
implementation alternatives
l Constructs allowing the separation of system
function from system communications
– In order to allow flexible adaptation and reuse of both
models and implementation
l Based on a well-established programming language
– In order to capitalize on the extensive infrastructure of
capture, compilation, and debugging tools already available

20
Model Accuracy Requirements
l Structural accuracy
l Timing accuracy
l Functional accuracy
l Data organization accuracy
l Communication protocol accuracy

21
System Level Language
SystemC

Cynlib

C/C++ Based SoC++

Handel-C
A/RT
(Library)

VHDL/Verilog VHDL+
Replacements System
System-Level Modeling
Verilog
Language

Higher-level Languages SDL

SLDL
Entirely New Languages
SUPERLOG

Java-Based Java
22
Language Use
C/C++ SystemC TestBuilder, Verilog SUPERLOG
2.0 OpenVer,e VHDL

Very
Embedded NO NO NO
Good Good
SW

System
Level Very
OK Excel NO Good
Design Poor

Very
Verification OK Good Excel OK
Good

RTL
Design NO Good NO Excel Excel

Reference : DAC 2002 SystemC Tutorial

23
Trend of System-Level Languages
l Extend existing design languages (ex: SystemVerilog)
– Pros:
• Familiar languages and environments to designers
• Allow descriptions of prior version of Verilog
– Cons:
• Not standardized yet
• Become more and more complex to learn
l Standard C/C++ based languages (ex: SystemC)
– Pros:
• Suitable for very abstract descriptions
• Suitable to be an executable specification
– Cons:
• A new language to learn
• Need solutions for the gap to traditional design flow
24
Evolution of Verilog Language
l Proprietary design description language developed by Gateway, 1990
– Donated to OVI(Open Verilog International) by Cadence

l Verilog Hardware Description Language LRM by OVI, V2.0 1993

l IEEE Std. 1364-1995, “Verilog 1.0” (called Verilog-1995)
l Synopsys proposed Verilog-2000, including synthesizable subset
l IEEE Std. 1364-2001, “Verilog 2.0” (called Verilog-2001) (1st main enhancement)

l SystemVerilog 3.0, approved as an Accellera standard in June 2002

– add system-level architectural modeling

l SystemVerilog 3.1, approved as an Accellera standard in May, 2003

– add verification and C language integration (Not yet as standard)

l Verilog Standards Group(IEEE 1364) announced a project

authorization request for 1364-2005

25
Compatibility of SystemVerilog
ANSI C-style ports, named parameter passing,
comma-separated sensitivity lists and attributes

SystemVerilog 3.0/3.1
Verilog-1995

Verilog-
2001 earliest Verilog

initialization of variables, the semantics of "posedge" and

"negedge" constructs, record-like constructs, handling of
interfaces and various keywords
26
Enhancements in SystemVerilog
l C data types
l Interfaces to encapsulate
l Dynamic processes
l A unique top level hierarchy ($root)
l Verification functionality
l Synchronization
l Classes
l Dynamic memory
l Assertion mechanism
l ……
27
Summary about SystemVerilog
l More extension in high-level abstraction to the Verilog-2001
standard
– Still no much enhancement in transaction-level abstraction
l Improves the productivity and readability of Verilog code
l Provide more concise hardware descriptions
l Extends the verification aspects of Verilog by incorporating
the capabilities of assertions
– Still no coverage construct within testbench design
l 3.0/3.1 LRM are still not very clear in more details
l Not yet simulator support
– No compiler for trying its syntax
l SV is a valuable direction to be watched
– Will it become too complex for most designers/verification
engineers’ requirement/understanding??
28
 Reference for SystemVerilog
l SystemVerilog 3.1, ballot draft: Accellera's Extensions
to Verilog? Accellera, Napa, California, April 2003.
l Verilog 2001: A Guide to the new Verilog Standard?
Stuart Sutherland, Kluwer Academic Publishers,
Boston, Massachusetts, 2001
l An overview of SystemVerilog 3.1, By Stuart
Sutherland, EEdesign, May 21, 2003
http://www.eedesign.com/story/OEG20030521S0086
URL:
1) http://www.eda.org/sv-ec/ (SystemVerilog Testbench Extension Committee)
2) http://www.eda.org/sv-ec/SV_3.1_Web/index.html (SV3.1 Web)

29
Why C/C++ Based Language for System
Modeling
l Specification between architects and
implementers is executable
l High simulation speed due to the higher level
of abstraction
l Refinement, no translation into HDL (no
“semantic gap”)
l Testbench re-use

30
Advantages of Executable Specifications
l Ensure the completeness of specification
– Even components (e.g. Peripherals) are so complex
– Create a program that behave the same way as the system
l Avoid ambiguous interpretation of the specification
– Avoids unspecified parts and inconsistencies
– IP customer can evaluate the functionality up-front
l Validate system functionality before implementation
– Create early model and validate system performance
l Refine and test the implementation of the
specification
– Test automation improves Time-to-Market

31
Can Traditional C++ Standard Be Used?

l C++ does not support

– Hardware style communication
• Signals, protocols, etc
– Notion of time
• Time sequenced operations
– Concurrency
• Hardware and systems are inherently concurrent
– Reactivity
• Hardware is inherently reactive, it responds to stimuli and is
inconstant interaction with its environments
– Hardware data types
• Bit type, bit-vector type, multi-valued logic type, signed and
unsigned integer types and fixed-point types
32
SystemC v.s SpecC
l Constructs to model system architecture
– Hardware timing
– Concurrency
– Hardware data-type (signal,etc)
l Adding these constructs to C/C++
– SystemC
• C++ Class library
• Standard C++ Compiler : bcc, msvc, gcc, etc
– SpecC
• Language extension : New keywords and syntax
• Translator for C

33
SystemC is…
l A library of C++ classes
– Processes (for concurrency)
– Clocks (for time)
– Hardware data types (bit vectors, 4-valued logic,
fixed-point types, arbitrary precision integers)
– Waiting and watching (for reactivity)
– Modules, ports, signals (for hierarchy)
– Abstract ports and protocols (abstract
communications)
• Using channel and interface classes

34
 SystemC Design Flow
C/C++ development
environment

Compiler
header files
Linker
systemC
libraries Debugger
Source file for system
and testbenches

make

Executable=simulator
Reference : DAC 2002 SystemC Tutorial
35
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
36
SystemC Language Architecture
SystemC Language Layering Architecture

Not-standard

Standard Channels for Various Methodology-Specific

Model of Computation Channels

Kahn Process Networks Master/Slave Library, etc.

Static Dataflow, etc.

Prepare to involve to SystemC Standard

Elementary Channels
Signal, Timer, Mutex, Semaphone, FIFO, etc

Core Language Data-Types

Modules 4-valued logic types (01XZ)

Ports 4-valued logic-vectors
Processes Bits and bit-vectors
Events Arbitrary-precision integers
Interfaces Fixed-point numbers
Channels C++ user-defined types

Event-Driven Simulation
Kernel

C++ Language Standard

37
System Abstraction Level (1/3)
l Untimed Functional Level (UTF)
– Refers to both the interface and functionality
– Abstract communication channels
– Processes executed in zero time but in order
– Transport of data executed in zero time
l Timed Functional Level (TF)
– Refers to both the interface and functionality
– Processes are assigned an execution time
– Transport of data is assigned a time
– Latency modeled
– “Timed” but not “clocked”
38
System Abstraction Level (2/3)
l Bus Cycle Accurate (BCA)
– Transaction Level Model (TLM)
– Model the communications between system
modules using shared resources such as busses
– Bus cycle accurate or transaction accurate
• No pin-level details
l Pin Cycle Accurate (PCA)
– Fully described by HW signals and the
communications protocol
– Pin-level details
– Clocks used for timing

39
System Abstraction Level (3/3)
l Register Transfer Accurate
– Fully timed
– Clocks used for synchronization
– Complete functional details
• Every register for every cycle
• Every bus for every cycle
• Every bit described for every cycle
– Ready to RTL HDL

40
Core Language
l Time Model
– To define time unit and its resolution
l Event-Driven Simulation Kernel
– To operate on events and switch between
processes, without knowing what the events
actually represent or what the processes do
l Modules and Ports
– To represent structural information
l Interfaces and Channels
– To describe the abstraction of communication
between the design block
41
Time Model

l Using an integer-valued time model

l 64-bit unsigned integer
l Can be increase to more than 64 bits if necessary
l Same as in Verilog and VHDL

42
Time Model (cont’)

l Time resolution
– Must be specified before any time objects (e.g
sc_time) are created
-12
– Default value is one pico-second ( 10 s )
l Time unit
SC_FS femtosecond Example for 42 picosecond

SC_PS picosecond sc_time T1(42, SC_PS)

SC_NS nenosecond
Example for resolution
SC_US microsecond
sc_set_time_resolution(10, SC_PS)
SC_MS millisecond sc_time T2(3.1416, SC_NS)
SC_SEC second
T2 would be rounded to 3140 ps
43

---12
15
93
6
Modules
l The basic building blocks for partitioning a design
l Declared with the SystemC keyword SC_MODULE
l Typically contain
– Ports that communicate with the environment
– Process that describe the functionality of the module
– Internal data and communication channels for the model
– Hierarchies (other modules)
l Modules can also Module
Ports
access a channel’s
RTL process
interface directly
Signals Sub-module

RTL process

44
 Modules - Example

SC_MODULE (FIFO) {
Load
Full //ports, process, internal data, etc
Read FIFO sc_in<bool> load;
Empty sc_in<bool> read;
Data sc_inout<int>data;
sc_out<bool> full;
sc_out<bool> empty;

SC_CTOR(FIFO){
//body of constructor;
//process declaration, sensitivities, etc.
}
};
45
Module Instantiation

Top Module

Positional
Association

Named
Association

46
Similar Control Flow Descriptions
IF

CASE

FOR

47
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
48
Data-Types
l SystemC allows users to use any C++ data types as well
as unique SystemC data types
– sc_bit – 2 value single bit type
– sc_logic – 4 value single bit type
– sc_int – 1 to 64 bit signed integer type
– sc_uint – 1 to 64 bit unsigned integer type
– sc_bigint – arbitrary sized signed integer type
– sc_biguint – arbitrary sized unsigned integer type
– sc_bv – arbitrary sized 2 value vector type
– sc_lv – arbitrary sized 4 value vector type
– sc_fixed - templated signed fixed point type
– sc_ufixed - templated unsigned fixed point type
– sc_fix - untemplated signed fixed point type
– sc_ufix - untemplated unsigned fixed point type
49
Type sc_bit

l Type sc_bit is a two-valued data type representing a single bit

l Value ’0’ = false
l Value ’1’ = true

Bitwise &(and) |(or) ^(xor) ~(not)

Assignment = &= |= ^=
Equality == !=
sc_bit operators

For Example :
sc_bit a,b; //Declaration
a = a & b;
a=a|b

50
Type sc_logic
l The sc_logic has 4 values, ’0’(false), ’1’(true), ’X’ (unknown),
and ’Z’ (high impedance or floating)
l This type can be used to model designs with multi-driver
busses, X propagation, startup values, and floating busses
l The most common type in RTL simulation

Bitwise &(and) |(or) ^(xor) ~(not)

Assignment = &= |= ^=
Equality == !=
sc_logic operators

For Example
sc_logic x; // object declaration
x = '1';// assign a 1 value
x = 'Z';// assign a Z value
51
Fixed Precision Unsigned and Signed
Integers
l The C++ int type is machine dependent, but
usually 32 bits
l SystemC integer type provides integers from 1 to
64 bits in signed and unsigned forms
l sc_int<n>
– A Fixed Precision Signed Integer
– 2’s complement notation
l sc_uint<n>
– A Fixed Precision Unsigned Integer

52
The Operators of sc_int<n> and sc_uint<n>

53
Bit Select and Part Select

54
The Examples of sc_int<n> and sc_uint<n>
sc_int<64> x; // declaration example
sc_uint<48> y;// declaration example

sc_int<16> x, y, z;
z = x & y;// perform and operation on x and y bit
// by bit
z = x >> 4;// assign x shifted right by 4 bits to z

To select on bit of an integer using the bit select operator

sc_logic mybit;
sc_uint<8> myint;
mybit = myint[7];
To select more than one bit using the range method
sc_uint<4> myrange;
sc_uint<32> myint;
myrange = myint.range(7,4);
Concatenation operation
sc_uint<4> inta;
sc_uint<4> intb;
sc_uint<8> intc;
intc = (inta, intb);
55
Arbitrary Precision Signed and Unsigned
Integer Types
l For the cases that some operands have to be larger
than 64 bits, the sc_int and sc_uint will not work
l The sc_biguint (arbitrary size unsigned integer) or
sc_bigint (arbitrary sized signed integer) can solve
this problem
l These types allow the designer to work on integers of
any size, limited only by underlying system limitations
l Arithmetic and other operators also use arbitrary
precision when performing operations
l These types execute more slowly than their fixed
precision counterparts and therefore should only be
used when necessary

56
The Operators of the sc_bigint<n> and
sc_biguint<n>
l Type sc_bigint is a 2’s complement signed integer of any size
l Type sc_biguint is an unsigned integer of any size
l The precision used for the calculations depends on the sizes
of the operands used

57
Arbitrary Length Bit Vector žÍsc_bv<n>

l The sc_bv is a 2-valued arbitrary length vector

to be used for large bit vector manipulation
l The sc_bv type will simulate faster than the
sc_lv type
– Without tri-state capability and arithmetic operations
l Type sc_biguint could also be used for these
operations, but
– It is optimized for arithmetic operations, not bit
manipulation operations
– Type sc_bv will still have faster simulation time

58
The New Operators for sc_bv<n>

l The new operators perform bit reduction

– and_reduce()
– or_reduce()
– xor_reduce()

sc_bv<64> databus;
sc_logic result;
result = databus.or_reduce();

If databus contains 1 or more 1 values the result of the reduction will be 1.

If no 1 values are present the result of the reduction will be 0 indicating that
databus is all 0’s.

59
The Operators of the sc_bv<n>

60
Arbitrary Length Logic Vector žÍsc_lv<n>

l The sc_lv<n> data-type represents an arbitrary

length vector in which each bit can have one of four
values
l To supply the design that need to be modeled with tri-
state capabilities
l These values are exactly the same as the four values
of type sc_logic
l Type sc_lv<n> is just a sized array of sc_logic
objects
l The sc_lv types cannot be used in arithmetic
operations directly

61
The Operators of the sc_lv<n>

Bitwise &(and) |(or) ^(xor) ~(not)

Assignment = &= |= ^=
Equality == !=

sc_uint<16> uint16;
sc_int<16> int16;
sc_lv<16> lv16;
lv16= uint16; // convert uint to lv
int16 = lv16; // convert lv to int

To perform arithmetic functions, first assign sc_lv objects to the

appropriate SystemC integer
62
Fixed Point Types
l For a high level model, floating point numbers are
useful to model arithmetic operations
l Floating point numbers can handle a very large range
of values and are easily scaled
l Floating point data types are typically converted or
built as fixed point data types to minimize the amount
of hardware cost
l To model the behavior of fixed point hardware,
designers need bit accurate fixed point data types
l Fixed point types are also used to develop DSP
software

63
Fixed Point Types (cont’)
l There are 4 basic types used to model fixed point
types in SystemC
– sc_fixed
– sc_ufixed
– sc_fix
– sc_ufix
l Types sc_fixed and sc_fix specify a signed fixed
point data type
l Types sc_ufixed and sc_ufix specify an unsigned
fixed point data type

64
Fixed Point Types (cont’)
l Types sc_fixed and sc_ufixed uses static
arguments to specify the functionality of the type
– Static arguments must be known at compile time
l Types sc_fix and sc_ufix can use argument
types that are non-static
– Non-static arguments can be variables
– Types sc_fix and sc_ufix can use variables to
determine word length, integer word length, etc.

65
Syntax of the Fixed Point Types
sc_fixed<wl, iwl, q_mode, o_mode, n_bits> x;
sc_ufixed<wl, iwl, q_mode, o_mode, n_bits> y;
sc_fix x(list of options);
sc_ufix y(list of options);

l wl - Total word length

– Used for fixed point representation. Equivalent to the total number of
bits used in the type.
l iwl - Integer word length
– To specifies the number of bits that are to the left of the binary point (.)
in a fixed point number.
l q_mode – quantization mode.
l o_mode - overflow mode
l n_bits - number of saturated bits
– This parameter is only used for overflow mode
l x,y - object name
– The name of the fixed point object being declared.
66
Quantization Modes

67
Overflow Modes

68
The Operators of Fixed Point

69
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
70
Processes
l Processes are the basic unit of execution within
SystemC
l Processes are called to simulate the behavior of the
target device or system
l Processes provide the mechanism of concurrent
behavior to model electronic system
l A process must be contained in a module
l Processes cannot not be hierarchical
– No process will call another process directly
l Processes can call methods and functions that are
not processes
71
Processes (cont’)
l Processes have sensitivity lists
– a list of signals that cause the process to be invoked,
whenever the value of a signal in this list changes

l Processes trigger other processes by assigning new

values to the hardware signals in the sensitivity list of
the other process

72
Processes (cont’)
l Three types of SystemC processes
– Methods — SC_METHOD
– Threads — SC_THREAD
– Clocked Threads — SC_CTHREAD

73
Process — SC_METHOD
l A method that does not have its own thread of
execution
– Cannot call code with wait()
l Executed when events (value changes) occur on
the sensitivity list
l When a method process is invoked, it executes
and returns control back to the simulation kernel
until it is finished
l Users are strongly recommended not to write
infinite loops within a method process
– Control will never be returned back to the simulator

74
SC_METHOD (Example)

// rcv.h // rcv.cc
#include "systemc.h" #include "rcv.h"
#include "frame.h" #include "frame.h"
void rcv::extract_id() {
SC_MODULE(rcv) { frame_type frame;
sc_in<frame_type> xin; frame = xin;
sc_out<int> id; if(frame.type == 1) {
void extract_id(); id = frame.ida;
SC_CTOR(rcv) { } else {
SC_METHOD(extract_id); id = frame.idb;
sensitive(xin); }
} }
};

To register the member function with the simulation kernel

75
Process — SC_THREAD
l Thread process can be suspended and reactivated
l A thread process can contain wait() functions that
suspend process execution until an event occurs on
the sensitivity list
l An event will reactivate the thread process from the
statement that was last suspended
l The process will continue to execute until the next
wait()

76
SC_THREAD (Example of a Traffic Light)

// traff.h // traff.cc
#include "systemc.h" #include "traff.h"
SC_MODULE(traff) { void traff::control_lights() {
// input ports NSred = false;
sc_in<bool> roadsensor; NSyellow = false;
sc_in<bool> clock; NSgreen = true;
// output ports EWred = true;
sc_out<bool> NSred; EWyellow = false;
sc_out<bool> NSyellow; EWgreen = false;
sc_out<bool> NSgreen; while (true) {
sc_out<bool> EWred; while (roadsensor == false)
sc_out<bool> EWyellow; wait();
sc_out<bool> EWgreen; NSgreen = false; // road sensor triggered
void control_lights(); NSyellow = true;// set NS to yellow
int i; NSred = false;
// Constructor for (i=0; i<5; i++)
SC_CTOR(traff) { wait();
SC_THREAD(control_lights);// Thread Process NSgreen = false; // yellow interval over
sensitive << roadsensor; NSyellow = false; // set NS to red
sensitive_pos << clock; NSred = true;// set EW to green
} EWgreen = true;
}; EWyellow = false;
EWred = false;
for (i= 0; i<50; i++)
wait();
.
.
.
77
Process — SC_CTHREAD
l Clocked thread process is a special case of the thread processes
l A clocked thread process is only triggered on one edge of one
clock
– Matches the way that hardware is typically implemented with
synthesis tools
l Clocked threads can be used to create implicit state machines
within design descriptions
l Implicit state machine
– The states of the system are not explicitly defined
– The states are described by sets of statements with wait() function
calls between them
l Explicit state machine
– To define the state machine states in a declaration
– To use a case statement to move from state to state
78
SC_CTHREAD (Example of a BUS function)

// bus.h start = true; // new addr for memory controller

#include "systemc.h" wait();
SC_MODULE(bus) { // wait 1 clock between data transfers
sc_in_clk clock; data8 = taddr.range(15,8);
sc_in<bool> newaddr; start = false;
sc_in<sc_uint<32> > addr; wait();
sc_in<bool> ready; data8 = taddr.range(23,16);
sc_out<sc_uint<32> > data; wait();
sc_out<bool> start; data8 = taddr.range(31,24);
sc_out<bool> datardy; wait();
sc_inout<sc_uint<8> > data8; // now wait for ready signal from memory
sc_uint<32> tdata; // controller
sc_uint<32> taddr; wait_until(ready.delayed() == true);
void xfer(); // now transfer memory data to databus
SC_CTOR(bus) { tdata.range(7,0) = data8.read();
SC_CTHREAD(xfer, clock.pos()); wait();
datardy.initialize(true); // ready to accept tdata.range(15,8) = data8.read();
// new address wait();
} tdata.range(23,16) = data8.read();
}; wait();
// bus.cc tdata.range(31,24) = data8.read();
#include "bus.h" data = tdata;
void bus::xfer() { datardy = true;// data is ready, new addresses ok
while (true) { }
// wait for a new address to appear }
wait_until( newaddr.delayed() == true);
// got a new address so process it
taddr = addr.read();
datardy = false; // cannot accept new address now
data8 = taddr.range(7,0);
79
Events

l An event is represented by class sc_event

– Determines whether and when a process’s execution should be
triggered or resumed
l An event is usually associated with some changes of
state in a process or of a channel
l The owner of the event is responsible for reporting the
change to the event object
– The act of reporting the change to the event is called notification
l The event object is responsible for keeping a list of
processes that are sensitive to it
l Thus, when notified, the event object will inform the
scheduler of which processes to trigger
80
Event Notification and Process Triggering

Process or Channel
(owner or event)

Notify immediately, after

delta-delay, or after time T

event
trigger trigger
trigger

Process 1 Process 2 Process 3

81
Events in Classical Hardware Modeling

l A hardware signal is responsible for notifying the

event whenever its value changes
– A signal of Boolean type has two additional events
• One associated with the positive edge
• One associated with the negative edge
– A more complex channel, such as a FIFO buffer
• An event associated with the change from being empty
to having a word written to it
• An event associated with the change from being full to
having a word read from it

82
Relationship Between the Events
l An event object may also be used directly by
one process P1 to control another process P2
– If P1 has access to event object E and P2 is
sensitive to or waiting on E, then P1 may trigger
the execution of P2 by notifying E
– In this case, event E is not associated with the
change in a channel, but rather with the execution
of some path in P1

83
Sensitivity
l The sensitivity of a process defines when this
process will be resumed or activated
l A process can be sensitive to a set of events.
l Whenever one of the corresponding events is
triggered, the process is resumed or activated.
l Two types
– Static Sensitivity
– Dynamic Sensitivity

84
Static Sensitivity

l Static sensitivity list

– In a module, the sensitivity lists of events are determined
before simulation begins
– The list remains the same throughout simulation
l RTL and synchronous behavioral processes only
use static sensitivity lists

85
Dynamic Sensitivity
l It is possible for a process to temporarily override
its static sensitivity list
– During simulation a thread process may suspend itself
– To designate a specific event E as the current event on
which the process wishes to wait
– Then, only the notification of E will cause the thread
process to be resumed
– The static sensitivity list is ignored

86
Dynamic Sensitivity — wait()

To wait for a specific eventE, the thread process

simply call wait() with E as argument:

wait(E)

Composite events, for use with wait only, may be

formed by conjunction A
( ND) or disjunction (OR)

wait(E1 & E2 & E3);

wait(E1 | E2 | E3);
87
Dynamic Sensitivity — wait() (Cont’)

The wait() function may also take as argument a

time
wait(200, SC_NS);
or, equivalently
sc_time t(200, SC_NS);
wait(t);

By combining time and events, we may impose a

timeout on the waiting of events

wait(200, SC_NS, E);

waits for event E to occur, but ifE does not occur

within 200ns, the thread process will give up on the
wait and resume
88
Dynamic Sensitivity — next_trigger()

l Calling Next_Trigger() does not suspend the current method

process
l Execution of the process will be invoked only when the event
specified by next_trigger() occurs.
l If an invocation of a method process does not call next_trigger(),
then the static sensitivity list will be restored

The calling will make the current method process wait on

E within a timeout of
200ns. If E occurs within 200ns, the method process will be triggered

next_trigger(200, SC_NS, E)

Otherwise, when the timeout expires, the method process will be triggered and
its static sensitivity list will be back in effect

89
Special Dynamic Sensitivity for
SC_CTHREAD — wait_until()
l The wait_until() method will halt the execution of
the process until a specific event has occurred.
l This specific event is specified by the expression
to the wait_until() method.

This statement will halt execution of the process until

the new value of roadsensor is true.
wait_until(roadsensor.delayed() == true);

90
Special Dynamic Sensitivity for
SC_CTHREAD — watching()

l SC_CTHREAD processes typically have

infinite loops that will be continuously executed
l A designer typically wants some way to
initialize the behavior of the loop or jump out of
the loop when a condition occurs
l The watching construct will monitor a specified
condition and transfer the control to the
beginning of the process

91
Special Dynamic Sensitivity for
SC_CTHREAD — watching() (Cont’)

// datagen.h // datagen.cc
#include "systemc.h" #include "datagen.h"
SC_MODULE(data_gen) { void gen_data() {
sc_in_clk clk; if (reset == true) {
sc_inout<int> data; data = 0;
sc_in<bool> reset; }
void gen_data(); while (true) {
SC_CTOR(data_gen){ data = data + 1;
SC_CTHREAD(gen_data, clk.pos()); wait();
watching(reset.delayed() == true); data = data + 2;
} wait();
}; data = data + 4;
wait();
}
}

specifies that signal reset will be watched for this process

? If signal reset changes to true, the watching expression will be true and the
SystemC scheduler will halt execution of the while loop for this process
? start the execution at the first line of the process
92
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
93
Communication between Design Blocks
- Channels, Interfaces, and Ports
l Traditionally, the hardware signals are used for
communication and synchronization between processes
l The level of abstraction is too low for system design view
Channels
Introduce Interfaces
Ports

l Interfaces and ports describe what functions are available

in a communications package
– Access points
l Channels defines how these functions are performed
– Internal operations

94
Example of Modules, Ports, Interfaces,
and Channels

port
Module with a port

interface

primitive channel
Hierarchical channel
with a port
Port-channel binding

Module 1 HC Module 2

95
Interfaces
l The “windows” into channels that describe the set of
operations
l Define sets of methods that channels must implement
l Specify only the signature of each operation, namely,
the operation’s name, parameters, and return value
l It neither specifies how the operations are
implemented nor defines data fields

96
Interfaces (cont’)
l All interfaces must be derived, directly or indirectly,
from the abstract base class : sc_interface
l The concept of interface is useful to model layered
design
– Connection between modules which are different level of
abstraction
l Relationship with ports
– Ports are connected to channels through interfaces
– A port that is connected to a channel through an interface
sees only those channel methods that are defined by the
interface

97
Interface Examples

l All interface methods are pure virtual methods without

any implementation

template <class T>

class sc_read_if
: virtual public sc_interface
{
public:
// interface methods
virtual const T& read() const = 0;
};

An example read interface: sc_read_if

this interface provides a 'read' method
98
Interface Examples

template <class T>

class sc_write_if
: virtual public sc_interface
{
public:
// interface methods
virtual void write( const T& ) = 0;
};

An example write interface: sc_write_if

this interface provides a 'write' method

99
Interface Examples

template <class T>

class sc_read_write_if
: public sc_read_if<T>,
public sc_write_if<T>
{};

An example read/write interface: sc_read_write_if

this defines a read/write interface by deriving from
the read interface and write interface

100
Ports
l A port is an object through which a module can
access a channel’s interface
l A port is the external interface that pass information to
and from a module, and trigger actions within the
module
l A port connects to channels through interfaces

101
Ports (cont’)
l A port can have three different modes of operation
– Input (sc_in<T>)
– Output (sc_out<T>)
– Inout (sc_inout<T>)

102
Ports (Cont’)
l A port of a module can be connected to
– Zero or more channels at the same level of hierarchy
– Zero or more ports of its parent module
– At least one interface or port
l sc_port allows accessing a channel’s interface
methods by using operator ž or operator [ ]
l In the following example:
– “input” is an input port of a process
– read() is an interface method of the attached channel

a = input->read();// read from the first (or only) channel of input

b = input[2]->read();// read from the third channel of input

103
Access Ports

Read/Wrire
through
methods

Hardware
types cannot
be accessed
directly

104
Specialized Ports

l Specialized ports can be created by refining port base

class sc_port or one of the predefined port types
– Addresses are used in addition to data
• Bus interface.
– Additional information on the channel’s status
• The number of samples available in a FIFO/LIFO
– Higher forms of sensitivity
• Wait_for_request()

105
Port-less Channel Access

l In order to facilitate IP reuse and to enable tool

support, SystemC 2.0 define the following
mandatory design style
– Design style for inter-module level communication
– Design style for intra-module level communication

106
Port-less Channel Access (cont’)
l For inter-module level communication, ports must be
used to connect modules to channels
– Ports are handles for communicating with the “outside
world” (channels outside the module)
– The handles allow for checking design rules and attaching
communication attributes, such as priorities
– From a software point-of-view they can be seen as a kind
of smart pointers
l For intra-module level communication, direct access
to channels is allowed
– Without using the ports.
– Access a channel’s interface in a “port-less” way by
directly calling the interface methods.
107
Channels
l A channel implements one or more interfaces, and
serves as a container for communication functionality
l A channel is the workhorse for holding and
transmitting data
l A channel is not necessarily a point-to-point
connection
l A channel may be connected to more than two
modules
l A channel may vary widely in complexity, from
hardware signal to complex protocols with embedded
processes
l SystemC 2.0 allows users to create their own channel
types
108
Channels (cont’)
l Primitive channels
– Do not exhibit any visible structure
– Do not contain processes
– Cannot (directly) access other primitive channels
l Hierarchical channels
– Basically are modules
– Can have structure
– Can contain other modules and processes
– Can (directly) access other channels

109
Primitive Channels
l The hardware signal
– sc_signal<T>
l The FIFO channel
– sc_fifo<T>
l The mutual-exclusion lock (mutex)
– sc_mutex

110
The Hardware Signal – sc_signal<T>

l The semantics are similar to the VHDL signal

l Sc_signal<T> implements the interface sc_signal_inout_if<T>

// controller.h SC_CTOR(controller) {
#include "statemach.h" // .... other module statements
s1 = new state_machine ("s1");
SC_MODULE(controller) { s1->clock(clk); // special case port to port binding
sc_in<sc_logic> clk; s1->en(lstat); // port en bound to signal lstat
sc_out<sc_logic> count; s1->dir(down); // port dir bound to signal down
sc_in<sc_logic> status; s1->st(status); // special case port to
sc_out<sc_logic> load; // port binding
sc_out<sc_logic> clear }
sc_signal<sc_logic> lstat; };
sc_signal<sc_logic> down;
state_machine *s1; //state is another module

The example above shows a port bound to another port

(special case) and a port bound to a signal.

111
The FIFO Channel – sc_fifo<T>
l To provide both blocking and nonblocking versions of access
l Sc_fifo<T> implements the interfaces sc_fifo_in_if<T> and
sc_fifo_out_if<T>

Blocking version
If the FIFO is empty
suspend until more data is available
If the FIFO is full
suspend until more space is available

NonBlocking version
If the FIFO is empty
do nothing
If the FIFO is full
do nothing
112
The Mutual-Exclusion Lock (Mutex)
– sc_mutex

l Model critical sections for accessing shared

variables
l A process attempts to lock the mutex before
entering a critical section
l If the mutex has already been locked by another
process, it will cause the current process to
suspend

113
 Channel Design Rules

sc_signal<T> Ÿ No more than one driver, i.e., at most one output

(sc_out<T> ) or bi-directional port s( c_inout<T>) connected.
Ÿ Arbitrary number of input ports sc_in<T>
( ) can be
connected
sc_fifo<T> Ÿ At most one input port can be connected.
Ÿ At most one output port can be connected.
Ÿ No bi-directional ports.

114
Channel Attributes
l Channel attributes can be used for a per-port
configuration of the communication
l Channel attributes are helpful especially when modules
are connected to a bus
l Attributes that can be used
– Addresses (in case the module doesn't use specialized ports,
addresses can be specified as arguments of the access
methods)
– Addressing schemes (e.g. constant address vs. auto-increment)
– Connect module as master or slave or master/slave
– Priorities
– Buffer sizes

115
Channel Attributes (Example)
l Let mod be an instance of a module and let port be a port
of this module
// create a local channel
message_queue mq;
...
// connect the module port to the channel
mod.port( mq );
...

l A channel attribute can now be specified, for example:

// specify a channel attribute

mq.priority( mod.port, 2 );
...

l which sets the priority attribute for mod.port to 2.

116
Hierarchical Channels
l To model the new generation of SoC communication
infrastructures efficiently
l For instance, OCB (On Chip Bus)
– The standard backbone from VSIA
– The OCB consisting of several intelligent units
• Arbiter unit
• A Control
• Programming unit
• Decode unit
l For modeling complex channels such as the OCB
backbone, primitive channels are not very suitable
– Due to the lack of processes and structures
l For modeling this type of channels, hierarchical
channels should be used
117
Primitive Channels v.s Hierarchical
Channels
l Use primitive channels
– When you need to use the request-update scheme
– When channels are atomic and cannot reasonably
be chopped into smaller pieces
– When speed is absolutely crucial (using primitive
channels we can often reduce the number of delta
cycles)
– When it doesn’t make any sense trying to build up
a channel (such as a mutex) out of processes and
other channels

118
Primitive Channels v.s Hierarchical
Channels (Cont’)

l Use hierarchical channels

– When channels are truly hierarchical and users
would want to be able to explore the underlying
structure
– When channels contain processes
– When channels contain other channels

119
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
120
Clock Objects
l Clock objects are special objects which generate
timing signals to synchronize events in the simulation
l Clocks order events in time so that parallel events in
hardware are properly modeled by a simulator on a
sequential computer
l Typically clocks are created at the top level of the
design in the testbench and passed down through the
module hierarchy to the rest of the design

121
Clock Objects (Example)

int sc_main(int argc, char*argv[]) {

sc_signal<int> val;
sc_signal<sc_logic> load;
sc_signal<sc_logic> reset;
sc_signal<int> result;
sc_time t1(20,SC_NS);
sc_clock ck1("ck1", t1, 0.5, 0, true);
filter f1("filter");
f1.clk(ck1.signal());
f1.val(val);
f1.load(load);
f1.reset(reset);
f1.out(result);
// rest of sc_main not shown

This declaration will create a clock object named ck1 with a period of 20ns,
a duty cycle of 50%, the first edge will occur at 0 time units,
and the first value will be true
122
Simulation Control

simulate for
1000ns

due to the
use of wait
123
Design Example: 4-bit LFSR

X0

D D D D
R1 R2 R3 R4

l Four files are created to describe this circuit

– LFSR.h (header file for declaration)
– LFSR.cpp (body of LFSR)
– LFSR_env.cpp (simulation environment)
– Main.cpp (top module)
124
 LFSR.h
SC_MODULE(LFSR_Gen)
#include "systemc.h"
{
SC_MODULE(LFSR) sc_out<bool> reset_n;
{
SC_CTOR(LFSR_Gen) {
sc_in<bool> clk;
SC_THREAD(Gen_proc);
sc_in<bool> reset_n;
}
sc_out<unsigned int> random;
void Gen_proc(); // body proc
SC_CTOR(LFSR) { };
SC_METHOD(LFSR_proc);
SC_MODULE(LFSR_Mon)
sensitive_pos << clk;
{
sensitive_neg << reset_n;
sc_in<unsigned int> random;
}
SC_CTOR(LFSR_Mon){
void LFSR_proc(); // body proc
SC_METHOD(Mon_proc);
sc_uint<4> Reg;
sensitive << random;
bool X0,R1,R2,R3,R4;
}
};
void Mon_proc(); // body proc
}; 125
LFSR.cpp
else {
if(R3==R4) X0=1;
#include "LFSR.h" else X0=0;
R4=R3;
void LFSR::LFSR_proc() R3=R2;
{ R2=R1;
if(reset_n.read()==false) { R1=X0;
R1=0; }
R2=0;
R3=0; Reg[0]=R1;
R4=0; Reg[1]=R2;
} Reg[2]=R3;
Reg[3]=R4;
random.write(Reg);
}
126
LFSR_env.cpp
#include "LFSR.h"
void LFSR_Gen::Gen_proc()
{
while (1) {
reset_n=1;
wait(2,SC_NS);
reset_n=0;
wait(4,SC_NS);
reset_n=1;
wait(100,SC_NS);
}
}
void LFSR_Mon::Mon_proc()
{
cout << "random= ";
cout << random << "\n";
}
127
Main.cpp
#include "LFSR.h"
int sc_main(int argc, char* argv[])
{
sc_signal<bool> reset_n;
sc_signal<unsigned int> random;
sc_time t1(2,SC_NS); // 1 cycle= 2ns
sc_clock clk("clk",t1,0.5);
LFSR_Gen M1("LFSR_Gen");
M1(reset_n);
LFSR M2("LFSR");
M2(clk,reset_n,random);
LFSR_Mon M3("LFSR_Mon");
M3(random);
sc_start(100,SC_NS);
return 0;
}
128
Running Results
random= 0
random= 1
random= 0
random= 1
random= 3
random= 7
random= 14
random= 13
random= 11
random= 6
random= 12
random= 9
random= 2
random= 5
random= 10
random= 4
random= 8
random= 0
……
129
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
130
The Supported Tools for SystemC
l Platform and Compiler
l System design environments

131
Platform and Compiler
l Typically, a compiler for C++ standard can
compile the SystemC source code well
– SystemC just a extended template
l GNU gcc for many platform
l Sun with solaris
– Forte c++
l HP
– Hp aC++
l Intel with Microsoft OS
– MS Visual C++

132
System Design Environments
l Synopsys
– CoCentric System Studio (CCSS)
l Cadence
– Signal Processing Worksystem (SPW)
l Agilent
– Advanced Design System (ADS)
l CoWare
– N2C Design System
l ……

133
CoCentric System Level Design Platform

CoCentric System Studio

C/SystemC,
Reference Performance
Design Kit Exploration

Processor Model
HW/SW Co-design

SystemC SystemC Software

Executable Synthesizable C-Code
Specification model

Chip Verification CoCentric Software

SystemC Compiler Implementation

134
CoCentric System Level Design Platform

l Algorithm libraries and Reference Design Kits

– Broadband Access: ADSL, DOCSIS cable modem
– Wireless: CDMA, Bluetooth, GSM/GPRS, PDC,
DECT, EDGE
– Digital Video: MPEG-2, MPEG-4
– Broadcast standard: DAB, DVB
– Error Correcting Coding: RS coding, Hamming
coding
– Speech Coding: ITU G.72X, GSM speech, AMR
speech

135
CoCentric System Level Design Platform

l Simulation, Debugging and Analysis

– Mixing of architectural and algorithmic models in
the same simulation
– Works with VCS, Verilog-XL, ModelSim, import
Matlab models for co-simulation
– Macro-debugging at the block level
– Micro-debugging at the source code level
– Davis
– VirSim

136
CoCentric System Level Design Platform

l Path to implementation
– Synthesizable SystemC code generated automatically

Cocentric System Studio

Executable specification
C/C++/SystemC

Cocentric SystemC Compiler

C/C++ software
Implementation flow
Design Physical
Compiler Compiler

Available System
137
Advanced Design System

Ptolemy HDL Hardware Logic

Models Simulation Emulation Synthesis

ADS
DSP Designer

C/C++ Measurement
HDL Models MATLAB
Models Instrumentation

138
Outline
l Introduction
l System Modeling Languages
l SystemC Overview
l Data-Types
l Processes
l Interfaces
l Simulation Supports
l System Design Environments
l HW/SW Co-Verification
l Conclusion
139
Traditional HW/SW Verification Flow

l Enter system integration and verification stage

until both HW/SW are finished
– Errors may happen at the beginning
l Hinges on the physical prototype like FPGA
– Chips respin waste a lot of money and time
– Error correction through redesign
l Signal visibility will be getting worse
– Change the pin assignment of the FPGA in order to get
the visibility

140
Pre-Silicon Prototype
l Virtual prototype
– Simulation environment
l Emulator
– Hundreds kilo Hz
l Rapid prototype
– Combination of FPGAs and dedicated chips that can be
interconnected to instantiate a design
– Tens mega Hz
l Roll-Your-Own (RYO) prototype
– FPGA and Board
– Tens mega Hz

141
Virtual Prototypes

l Definition
– A simulation model of a product , component, or
system
l Features
– Higher abstraction level
– Easily setup and modify
– Cost-effective
– Great observability
– Shorten design cycles

142
 Verification Speed

Algorithm Cell loss ? Bit error rate??

Level

Transaction Bus bandwidth? Cache size?

Level

RTL
Handshake? reset?

Sub bus Latency untimed

Cycle
Cycle Cycle annotation
Reference : Synopsys

143
 Verification Speed

Algorithm
Level 1000X

Transaction
Level 100X

1 10X
RTL

Sub Cycle bus Latency untimed

Reference : Synopsys
Cycle Cycle annotation

144
HW/SW Co-Simulation
l Couple a software execution environment with a
hardware simulator
l Provides complete visibility and debugger
interface into each environment
l Software normally executed on an Instruction Set
Simulator (ISS)
l A Bus Interface Model (BIM) converts abstract
software operations into detailed pin operations

145
Advantages of HW/SW Co-Simulation (1/2)

l Simulate in minutes instead of days

l Early architecture closure reduces risk by 80%
l Start software development 6 months earlier
l Simulate 100x~1000x faster than RTL
l HW designers can use the tools which are familiar
to them
l SW programmers can use all their favorite
debugger to observe software state and control
the executions

146
Advantages of HW/SW Co-Simulation (2/2)

l Software Engineers
– Simulation model replace stub code
– More time to develop & debug code
– Validate code against hardware as you develop
– Maintain software design integrity
l Hardware Engineer
– Embedded software replaces test bench
– Reduce the chance of an ASIC or Board spin
– Resolve gray areas before tape out

147
Synopsys’s SystemC Solution

l System Studio
– SystemC simulation System Studio
l SystemC Compiler DesignWare

– SystemC synthesis
l DesignWare SystemC
– AMBA/ARM SystemC Compiler
C/C++
models
Design Compiler/ Compiler
Physical Compiler

SoC
Reference : Synopsys

148
 Synopsys System Studio

Architecture
Algorithm

ARM9 / AHB

SystemC
Simulation

Hardware
Software

Debugger

Memory

Bus

Reference : Synopsys 149

 Mentor Graphic : Seamless CVE

Reference : Mentor Graphics 150

 Cadence : Incisive Platform

Unified Environment

Unified test generation

Transaction support

Verilog SystemC

Single-kernel
VHDL PSL/Sugar
architecture

AMS Algorithm

Acceleration-on-Demand

Reference : Cadence 151

Conclusions
l The system level design is a new design challenge
– Both hardware and software issues have to be considered
l High level abstraction and modeling is essential for
system design in future
– SystemC is a more mature language, but not the only one
l Co-design methodology can reduce the design cycle
– Allow earlier HW/SW integration
l Virtual co-simulation environment is required
– Reduce the cost and design cycle of hardware prototype
– Simulate 100x~1000x faster than RTL with the models of higher
level of abstraction
l A hot and hard area for designers and EDA vendors
152
References
l Book materials
– System Design with SystemC, T. Grotker, S. Liao, G. Martin, S. Swan,
Kluwer Academic Publishers.
– Surviving the SOC Revolution, H. Chang et. Al, Kluwer Academic
Publishers.
l Manual
– SystemC Version 2.0 User’s Guide
– Functional Specification for SystemC 2.0
l Slides
– SoC Design Methodology, Prof. C.W Jen
– Concept of System Level Design using Cocentric System Studio, L.F Chen
l WWW
– http://www.synopsys.com
– http://www.systemc.org
– http://www.forteds.com
– http://www.celoxica.com
– http://www.adelantetechnologies.com
– http://mint.cs.man.ac.uk/Projects/UPC/Languages/VHDL+.html
– http://eesof.tm.agilent.com/products/ads2002.html
– http://www.specc.gr.jp/eng/
– http://www.doulos.com
153
– http://www.coware.com