modelling interconnects

7/30/2019 Modelling Interconnects

1/150

1

System Modeling & HW/SW Co-Verification

Prof. Chien-Nan LiuTEL: 03-4227151 ext:4534

Email: [email protected]


2/150

2

Outline

l Introductionl System Modeling Languagesl SystemC Overviewl Interfacesl Processesl Data-Typesl Design Examplesl

System Design Environmentsl HW/SW Co-Verificationl Conclusion


3/150

3

Outline

ll IntroductionIntroductionl System Modeling Languagesl SystemC Overviewl Interfacesl Processesl Data-Typesl Design Examplesl

System Design Environmentsl HW/SW Co-Verificationl Conclusion


4/150

4

Design Challenges

Reference http://www.doulos.com


5/150

5

Silicon complexity v.s Software complexity

Silicon complexity is growing 10xevery 6 years

Software in systems is growing faster than 10x every 6 years

Reference http://www.doulos.com


6/150

6

Increasing Complexity in SoC Designs

l One or more processorsl 32-bit Microcontrollersl DSPs or specialized media processorsl On-chip memoryl Special function blocksl Peripheral control devicesl Complex on-chip communications network (On-chip

busses)l

RTOS and embedded software which are layeringarchitecturel


7/150

7

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


8/150

8

Traditional System Design Flow (1/2)

l Designers partition the system into hardware andsoftware early in the flow

l HW and SW engineers design their respectivecomponents in isolation

l HW and SW engineers do not talk to each otherl The system may not be the suitable solutionl Integration problemsl High cost and long iteration


9/150

9

Traditional System Design Flow (2/2)

n System Level Designn Hardware and Softwaren Algorithm Developmentn Processor Selectionn Done mainly in C/C++

C/C++ Environment

n System Level Designn Hardware and Softwaren Algorithm Developmentn Processor Selectionn Done mainly in C/C++

C/C++ Environment

w Software Designw Code Developmentw RTOS details

w Done mainly in C/C++

C/C++ Environment

w Software Designw Code Developmentw RTOS detailsw Done mainly in C/C++

C/C++ Environment

n IC Developmentn Hardwaren Implementation

n Decisionsn Done mainly in HDL

EDA Environment

n IC Developmentn Hardwaren Implementationn Decisionsn Done mainly in HDL

EDA Environment

$ $ $

Verification Process

Reference : Synopsys


10/150

10

Typical Project Schedule

System Design

Hardware Debug

Software Design

Software Coding

Software Debug

Project Complete

Hardware Design

Prototype Build

Reference : Mentor Graphic


11/150

11

Former Front-End Design Flow

C/C++ SystemLevel Model


Analysis Analysis

ResultsResults

Verilog

SimulationSimulation

SynthesisSynthesis

VerilogTestbench Verilog

Testbench

Convert by Hand

Refine

Reference : DAC 2002 SystemC Tutorial


12/150

12

Problems with the Design Flow



Analysis Analysis

ResultsResults

Verilog

SimulationSimulation

SynthesisSynthesis

VerilogTestbench Verilog

Testbench

Convert by Hand

Refine

Not reusable

Not done by designers The netlist is not preserved



13/150


14/150

14

Concurrent HW/SW Design

l Can provide a significant performanceimprovement for embedded system design Allows earlier architecture closure Reduce risk by 80%

l Allows HW/SW engineering groups to talktogetherl Allows earlier HW/SW Integrationl Reduce design cycle

Develop HW/SW in parallel 100x faster than RTL


15/150

15

Project Schedule with HW/SW Co-design

System Design

Hardware Debug

Software Design

Software Coding

Software Debug

Project Complete

Hardware Design

Prototype Build

Reference : Mentor Graphic


16/150

16

Modern System Design Flow

Specification of the System

System Level Modeling

Hardware and SoftwarePartitioning

Architectural Exploration

H/W Model S/W Model

H/W Design Flow S/W Development

Integration and Verification


17/150

17

Outline

l Introductionll System Modeling LanguagesSystem Modeling Languagesl SystemC Overviewl Interfacesl Processesl Data-Typesl Design Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion


18/150

18

Motivation to Use a Modeling Language

l The increasing system design complexityl The demand of higher level abstraction and

modelingl Traditional HDLs (verilog, VHDL, etc) are

suitable for system level design Lack of software supports

l To enable an efficient system design flow


19/150

19

Requirements of a System Design Language

l Support system models at various levels ofabstraction

l Incorporation of embedded software portionsof a complex system Both models and implementation-level code

l Creation of executable specifications ofdesign intent

l Creation of executable platform models Represent possible implementation architectures

on which the design intent will be mapped


20/150

20

Requirements of a System Design Language

l Fast simulation speed to enable design-spaceexploration Both functional specification and architectural

implementation alternativesl Constructs allowing the separation of system

function from system communications In order to allow flexible adaptation and reuse of both

models and implementationl Based on a well-established programming language

In order to capitalize on the extensive infrastructure of capture, compilation, and debugging tools already available


21/150

21

Model Accuracy Requirements

l Structural accuracyl Timing accuracyl Functional accuracyl Data organization accuracyl Communication protocol accuracy


22/150

22

System Level Language

System-Level ModelingLanguage

C/C++ Based

Higher-level Languages

VHDL/VerilogReplacements

Entirely New Languages

Java-Based

SystemC

Cynlib

SoC++

Handel-C

A/RT(Library)

VHDL+

SDL

SLDL

SUPERLOG

Java

SystemVerilog


23/150

23

Language Use

ExcelExcelNOGoodNORTL

Design

VeryGood

OKExcelGoodOKVerification

GoodVeryPoor

NOExcelOK

SystemLevel

Design

NONONOVeryGoodGood

EmbeddedSW

SUPERLOGVerilogVHDL

TestBuilder,OpenVer,e

SystemC2.0

C/C++



24/150

24

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


25/150

25

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 integrationl Verilog Standards Group(IEEE 1364) announced a project

authorization request for 1364-2005

(Not yet as standard)


26/150

26

Compatibility of SystemVerilog

initialization of variables, the semantics of "posedge" and"negedge" constructs, record-like constructs, handling of interfaces and various keywords

SystemVerilog 3.0/3.1Verilog-1995

Verilog-2001

ANSI C-style ports, named parameter passing,

comma-separated sensitivity lists and attributes

earliest Verilog


27/150

27

Enhancements in SystemVerilog

l C data typesl Interfaces to encapsulatel Dynamic processesl A unique top level hierarchy ($root)l Verification functionalityl Synchronizationl Classesl

Dynamic memoryl Assertion mechanisml


28/150

28

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 codel Provide more concise hardware descriptions

l Extends the verification aspects of Verilog by incorporatingthe capabilities of assertions Still no coverage construct within testbench design

l 3.0/3.1 LRM are still not very clear in more detailsl Not yet simulator support

No compiler for trying its syntaxl SV is a valuable direction to be watched

Will it become too complex for most designers/verificationengineers requirement/understanding??


29/150

29

Bibliography

l SystemVerilog 3.1, ballot draft: Accellera's Extensionsto 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, 2003http://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)


30/150

30

Why C/C++ Based Language for System Modeling

l Specification between architects andimplementers is executable

l High simulation speed due to the higher levelof abstraction

l Refinement, no translation into HDL (nosemantic gap)

l Testbench re-use


31/150

31

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


32/150

32

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


33/150

33

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


34/150

34

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


35/150

35

SystemC Design Flow

Compiler

Linker

Debugger

make

Executable=simulator

Source file for systemand testbenches

systemC

header files

libraries

C/C++ developmentenvironment



36/150

36

Outline

l Introductionl System Modeling Languagesll SystemCSystemC OverviewOverviewl Interfacesl Processesl Data-Typesl Design Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion


37/150

37

SystemC Language Architecture

SystemC Language Layering Architecture

C++ Language Standard

Not-standard

Standard Channels for VariousModel of Computation

Kahn Process NetworksStatic Dataflow, etc.

Methodology-SpecificChannels

Master/Slave Library, etc.

Prepare to involve to SystemC Standard

Elementary ChannelsSignal, Timer, Mutex, Semaphone, FIFO, etc

Core Language

ModulesPortsProcessesEventsInterfaces

Channels

Event-Driven SimulationKernel

Data-Types

4-valued logic types (01XZ)4-valued logic-vectorsBits and bit-vectors

Arbitrary-precision integersFixed-point numbers

C++ user-defined types


38/150

38

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 timel 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


39/150

39


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 detailsl Pin Cycle Accurate (PCA)

Fully described by HW signals and thecommunications protocol

Pin-level details Clocks used for timing


40/150

40


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


41/150

41

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 eventsactually represent or what the processes dol Modules and Ports

To represent structural informationl

Interfaces and Channels To describe the abstraction of communicationbetween the design block


42/150

42

Time Model

l Using an integer-valued time modell 64-bit unsigned integerl Can be increase to more than 64 bits if necessaryl Same as in Verilog and VHDL


43/150

43

Time Model (cont)

l Time resolution Must be specified before any time objects (e.g

sc_time) are created Default value is one pico-second ( )

l Time unit

s1210 -

femtosecondSC_FS

picosecondSC_PS

nenosecondSC_NS

microsecondSC_US

millisecondSC_MS

secondSC_SEC

Example for 42 picosecond

sc_time T1(42, SC_PS)

Example for resolution

sc_set_time_resolution(10, SC_PS)sc_time T2(3.1416, SC_NS)

T2 would be rounded to 3140 ps


44/150

44

Clock Objects

l Clock objects are special objects which generatetiming signals to synchronize events in the simulation

l Clocks order events in time so that parallel events inhardware are properly modeled by a simulator on asequential computer

l Typically clocks are created at the top level of thedesign in the testbench and passed down through themodule hierarchy to the rest of the design


45/150

45

Clock Objects (Example)

int sc_main(int argc, char*argv[]) {sc_signal val;sc_signal load;sc_signal reset;sc_signal result;sc_clock ck1("ck1", 20, 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 20time units, a duty cycle of 50%, the first edge will occur at 0 time units,and the first value will be true


46/150

46

Modules

l The basic building blocks for partition a designl Modules are declared with the SystemC keyword

SC_MODULEl Typical contains

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 access a channels interfacedirectly


47/150

47

Modules -Example

FIFO

Load

Read

Data

Full

Empty

SC_MODULE (FIFO) {//ports, process, internal data, etcsc_in load;sc_in read;sc_inoutdata;sc_out full;sc_out empty;

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

}};


48/150

48

Outline

l Introductionl System Modeling Languagesl SystemC Overviewll InterfacesInterfacesl Processesl Data-Typesl Design Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion


49/150

49

Communication between Design Blocks - Channels, Interfaces, and Ports

l Traditionally, the hardware signals are used forcommunication and synchronization between processes

l The level of abstraction is too low for system design view

l Interfaces and ports describe what functions are availablein a communications package Access points

l Channels defines how these functions are performed Internal operations

Introduce InterfacesPorts

Channels


50/150

50

Example of Modules, Ports, Interfaces,and Channels

port

interface

primitive channel

Port-channel binding

Module with a port

Hierarchical channelwith a port

Module 1 Module 2HC


51/150

51

Interfaces

l The windows into channels that describe the set ofoperationsl Define sets of methods that channels must implementl Specify only the signature of each operation, namely,

the operations name, parameters, and return valuel It neither specifies how the operations are

implemented nor defines data fields


52/150

52

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

abstractionl Relationship with ports

Ports are connected to channels through interfaces

A port that is connected to a channel through an interfacesees only those channel methods that are defined by theinterface


53/150

53

Interface Examples

l All interface methods are pure virtual methods withoutany implementation

template

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

An example read interface: sc_read_if this interface provides a 'read' method


54/150

54

Interface Examples

template class sc_write_if : virtual public sc_interface

{public:// interface methodsvirtual void write( const T& ) = 0;};

An example write interface: sc_write_if this interface provides a 'write' method


55/150

55

Interface Examples

template class sc_read_write_if : public sc_read_if,public sc_write_if{};

An example read/write interface: sc_read_write_if

this defines a read/write interface by deriving fromthe read interface and write interface


56/150

56

Ports

l A port is an object through which a module canaccess a channels interface

l A port is the external interface that pass information toand from a module, and trigger actions within themodule

l A port connects to channels through interfaces


57/150

57

Ports (cont)

l A port can have three different modes of operation Input (sc_in) Output (sc_out) Inout (sc_inout)

FIFO

Load

Read

Data

Full

Empty


58/150

58

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 channels interfacemethods 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 inputb = input[2]->read(); // read from the third channel of input


59/150

59

Specialized Ports

l Specialized ports can be created by refining port baseclass sc_port or one of the predefined port types Addresses are used in addition to data

Bus interface.

Additional information on the channels status The number of samples available in a FIFO/LIFO

Higher forms of sensitivity Wait_for_request()


60/150

60

Port-less Channel Access

l In order to facilitate IP reuse and to enable toolsupport, SystemC 2.0 define the followingmandatory design style Design style for inter-module level communication

Design style for intra-module level communication


61/150

61

Port-less Channel Access (cont)

l For inter-module level communication, ports must beused 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 pointersl For intra-module level communication, direct access

to channels is allowed Without using the ports. Access a channels interface in a port-less way by

directly calling the interface methods.


62/150

62

Channels

l A channel implements one or more interfaces, andserves as a container for communication functionalityl A channel is the workhorse for holding and

transmitting datal A channel is not necessarily a point-to-point

connectionl A channel may be connected to more than two

modulesl A channel may vary widely in complexity, from

hardware signal to complex protocols with embedded

processesl SystemC 2.0 allows users to create their own channel

types


63/150

63

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


64/150

64

Primitive Channels

l The hardware signal sc_signal

l The FIFO channel sc_fifo

l The mutual-exclusion lock (mutex) sc_mutex


65/150

65

The Hardware Signal sc_signal

l The semantics are similar to the VHDL signall Sc_signal implements the interface sc_signal_inout_if

// controller.h#include "statemach.h"

SC_MODULE(controller) {sc_in clk;sc_out count;sc_in status;sc_out load;sc_out clear sc_signal lstat;sc_signal down;state_machine *s1; //state is another module

SC_CTOR(controller) {// .... other module statementss1 = new state_machine ("s1");

s1->clock(clk); // special case port to port bindings1->en(lstat); // port en bound to signal lstats1->dir(down); // port dir bound to signal downs1->st(status); // special case port to// port binding}};

The example above shows a port bound to another port(special case) and a port bound to a signal.


66/150

66

The FIFO Channel sc_fifo

l

To provide both blocking and nonblocking versions of accessl Sc_fifo implements the interfaces sc_fifo_in_if and

sc_fifo_out_if

If the FIFO is emptysuspend until more data is available

If the FIFO is fullsuspend until more space is available

Blocking version

If the FIFO is emptydo nothingIf the FIFO is full

do nothing

NonBlocking version


67/150

67

The Mutual-Exclusion Lock (Mutex) sc_mutex

l Model critical sections for accessing sharedvariables

l A process attempts to lock the mutex beforeentering a critical section

l If the mutex has already been locked by anotherprocess, it will cause the current process tosuspend


68/150

68

Channel Design Rules

sc_signal

At most one input port can be connected. At most one output port can be connected. No bi-directional ports.

sc_fifo

No more than one driver, i.e., at most one output(sc_out ) or bi-directional port ( sc_inout ) connected.

Arbitrary number of input ports ( sc_in ) can beconnected


69/150

69

Channel Attributes

l Channel attributes can be used for a per-portconfiguration of the communicationl Channel attributes are helpful especially when modules

are connected to a busl Attributes that can be used

Addresses (in case the module doesn't use specialized ports,addresses can be specified as arguments of the accessmethods)

Addressing schemes (e.g. constant address vs. auto-increment) Connect module as master or slave or master/slave

Priorities Buffer sizes


70/150

70

Channel Attributes (Example)

l

Let mod be an instance of a module and let port be a portof this module

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

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

// create a local channelmessage_queue mq;...// connect the module port to the channelmod.port( mq );...

// specify a channel attributemq.priority( mod.port, 2 );...


71/150

71

Hierarchical Channels l To model the new generation of SoC communication

infrastructures efficientlyl 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 OCBbackbone, primitive channels are not very suitable Due to the lack of processes and structures

l For modeling this type of channels, hierarchicalchannels should be used


72/150

72

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 primitivechannels we can often reduce the number of deltacycles)

When it doesnt make any sense trying to build upa channel (such as a mutex) out of processes and

other channels


73/150

73

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 underlyingstructure

When channels contain processes When channels contain other channels


74/150

74

Outline

l

Introductionl System Modeling Languagesl SystemC Overviewl Interfacesll ProcessesProcessesl Data-Typesl Design Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion


75/150

75

Processes

l Processes are the basic unit of execution within SystemCl Processes are called to simulate the behavior of the target

device or systeml Processes provide the mechanism of concurrent behavior

to model electronic systeml A process must be contained in a module


76/150

76

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 cannot not be hierarchical

No process will call another process directlyl Processes trigger other processes by assigning

new values to the hardware signals in thesensitivity list of the other process

l Processes can call methods and functions thatare not processes


77/150

77

Processes (cont)

l Three types of SystemC processes Methods SC_METHOD Threads SC_THREAD Clocked Threads SC_CTHREAD


78/150

78

Process SC_METHOD

l A method that does not have its own thread ofexecution Cannot call code with wait()

l Executed when events (value changes) occur onthe sensitivity list

l When a method process is invoked, it executesand returns control back to the simulation kerneluntil it is finished

l Users are strongly recommended not to writeinfinite loops within a method process Control will never be returned back to the simulator


79/150

79

SC_METHOD (Example)

// rcv.h#include "systemc.h"#include "frame.h"

SC_MODULE(rcv) {sc_in xin;sc_out id;

void extract_id();SC_CTOR(rcv) {SC_METHOD(extract_id);sensitive(xin);}};

// rcv.cc#include "rcv.h"#include "frame.h"void rcv::extract_id() {frame_type frame;frame = xin;if(frame.type == 1) {

id = frame.ida;} else {id = frame.idb;}}

To register the member function with the simulation kernel


80/150

80

Process SC_THREAD

l

Thread process can be suspended and reactivatedl A thread process can contain wait() functions that

suspend process execution until an event occurs onthe sensitivity list

l An event will reactivate the thread process from thestatement that was last suspended

l The process will continue to execute until the nextwait()


81/150

81

SC_THREAD (Example of a Traffic Light)

// traff.h#include "systemc.h"SC_MODULE(traff) {// input portssc_in roadsensor;sc_in clock;// output portssc_out NSred;sc_out NSyellow;sc_out NSgreen;sc_out EWred;sc_out EWyellow;sc_out EWgreen;void control_lights();int i;// Constructor SC_CTOR(traff) {SC_THREAD(control_lights); // Thread Processsensitive


82/150

82

Process SC_CTHREAD

l Clocked thread process is a special case of the thread processesl A clocked thread process is only triggered on one edge of one

clock Matches the way that hardware is typically implemented with

synthesis toolsl Clocked threads can be used to create implicit state machines

within design descriptionsl 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 theml Explicit state machine

To define the state machine states in a declaration To use a case statement to move from state to state


83/150

83

SC_CTHREAD (Example of a BUS function)

// bus.h#include "systemc.h"SC_MODULE(bus) {sc_in_clk clock;sc_in newaddr;sc_in addr;sc_in ready;sc_out data;sc_out start;sc_out datardy;sc_inout data8;sc_uint tdata;sc_uint taddr;void xfer();SC_CTOR(bus) {SC_CTHREAD(xfer, clock.pos());datardy.initialize(true); // ready to accept// new address}};// bus.cc#include "bus.h"void bus::xfer() {

while (true) {// wait for a new address to appear wait_until( newaddr.delayed() == true);// got a new address so process ittaddr = addr.read();datardy = false; // cannot accept new address nowdata8 = taddr.range(7,0);

start = true; // new addr for memory controller wait();// wait 1 clock between data transfersdata8 = taddr.range(15,8);start = false;wait();data8 = taddr.range(23,16);wait();data8 = taddr.range(31,24);wait();// now wait for ready signal from memory// controller wait_until(ready.delayed() == true);// now transfer memory data to databustdata.range(7,0) = data8.read();wait();tdata.range(15,8) = data8.read();wait();tdata.range(23,16) = data8.read();wait();tdata.range(31,24) = data8.read();data = tdata;datardy = true; // data is ready, new addresses ok

}}


84/150


85/150

85

Event Notification and Process Triggering

Process or Channel(owner or event)

Process 1 Process 2 Process 3

event

trigger trigger trigger

Notify immediately, after

delta-delay, or after time T


86/150

86

Events in Classical Hardware Modeling

l A hardware signal is responsible for notifying theevent 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 emptyto having a word written to it

An event associated with the change from being full to

having a word read from it


87/150

87

Relationship Between the Events

l An event object may also be used directly byone 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 thechange in a channel, but rather with the executionof some path in P1


88/150

88

Sensitivity

l

The sensitivity of a process defines when thisprocess will be resumed or activatedl 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


89/150

89

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 onlyuse static sensitivity lists


90/150

90

Dynamic Sensitivity

l

It is possible for a process to temporarily overrideits static sensitivity list During simulation a thread process may suspend itself

To designate a specific event E as the current event onwhich the process wishes to wait

Then, only the notification of E will cause the threadprocess to be resumed

The static sensitivity list is ignored


91/150

91

Dynamic Sensitivity wait()

To wait for a specific event E , the thread processsimply call wait() with E as argument:

wait(E)

Composite events, for use with wait only, may beformed by conjunction (AND) or disjunction (OR)

wait(E1 & E2 & E3);wait(E1 | E2 | E3);


92/150

92

Dynamic Sensitivity wait() (Cont)

The wait () function may also take as argument atime

wait (200, SC_NS);or, equivalently

sc_time t(200, SC_NS);

wait(t);

By combining time and events, we may impose atimeout on the waiting of events

wait (200, SC_NS, E);

waits for event E to occur, but if E does not occur within 200ns, the thread process will give up on thewait and resume


93/150

93

Dynamic Sensitivity next_trigger()

l Calling Next_Trigger() does not suspend the current methodprocess

l Execution of the process will be invoked only when the eventspecified 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 andits static sensitivity list will be back in effect

Special Dynamic Sensitivity for


94/150

94

Special Dynamic Sensitivity for SC_CTHREAD wait_until()

l The wait_until() method will halt the execution ofthe process until a specific event has occurred.

l This specific event is specified by the expressionto the wait_until() method.

This statement will halt execution of the process untilthe new value of roadsensor is true.

wait_until (roadsensor.delayed() == true);



95/150

95

Special Dynamic Sensitivity for SC_CTHREAD watching()

l SC_CTHREAD processes typically haveinfinite loops that will be continuously executed

l A designer typically wants some way toinitialize the behavior of the loop or jump out ofthe loop when a condition occurs

l The watching construct will monitor a specifiedcondition and transfer the control to thebeginning of the process



96/150

96

Special Dynamic Sensitivity for SC_CTHREAD watching() (Cont)

// datagen.cc#include "datagen.h"void gen_data() {if (reset == true) {data = 0;}while (true) {

data = data + 1;

wait();data = data + 2;wait();data = data + 4;wait();

}}

// datagen.h#include "systemc.h"SC_MODULE(data_gen) {sc_in_clk clk;sc_inout data;sc_in reset;void gen_data();SC_CTOR(data_gen){

SC_CTHREAD(gen_data, clk.pos());watching(reset.delayed() == true);}};

specifies that signal reset will be watched for this process

? If signal reset changes to true, the watching expression will be true and theSystemC scheduler will halt execution of the while loop for this process

? start the execution at the first line of the process


97/150

97

Outline

l Introductionl System Modeling Languagesl SystemC Overviewl Interfaces

l Processesll Data-TypesData-Typesl Design Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion


98/150

98

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

b


99/150

99

Type sc_bit

l Type sc_bit is a two-valued data type representing a single bitl Value 0 = falsel Value 1 = true

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

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

Equality == !=

sc_bit operators

T l i


100/150

100

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 bussesl The most common type in RTL simulation

sc_logic operators

For Example

sc_logic x; // object declarationx = 1; // assign a 1 valuex = Z; // assign a Z value


Equality == !=

Fixed Precision Unsigned and Signed


101/150

101

Fixed Precision Unsigned and Signed Integers

l The C++ int type is machine dependent, butusually 32 bitsl SystemC integer type provides integers from 1 to

64 bits in signed and unsigned formsl

sc_int A Fixed Precision Signed Integer 2s complement notation

l sc_uint A Fixed Precision Unsigned Integer

Th O f i d i


102/150

102

The Operators of sc_int and sc_uint

The Examples of sc int and


103/150

103

p _sc_uint

sc_int x; // declaration example

sc_uint y; // declaration examplesc_int x, y, z;z = x & y; // perform and operation on x and y bit// by bitz = 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 myint;mybit = myint[7];

To select more than one bit using the range method

sc_uint myrange;sc_uint myint;myrange = myint.range(7,4);

Concatenation operationsc_uint inta;sc_uint intb;sc_uint intc;intc = (inta, intb);


104/150

The Operators of the sc bigint and


105/150

105

p _ gsc_biguint

l Type sc_bigint is a 2s complement signed integer of any sizel Type sc_biguint is an unsigned integer of any sizel The precision used for the calculations depends on the sizes

of the operands used

A bit L th Bit V t b < >


106/150

106

Arbitrary Length Bit Vector sc_bv

l

The sc_bv is a 2-valued arbitrary length vectorto be used for large bit vector manipulationl The sc_bv type will simulate faster than the

sc_lv type

Without tri-state capability and arithmetic operationsl 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

Th O t f b < >


107/150

107

The new Operators for sc_bv

l The new operators perform bit reduction and_reduce() or_reduce() xor_reduce()

sc_bv 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 thatdatabus is all 0s.

Th O t f th b < >


108/150

108

The Operators of the sc_bv

Arbitrar Length Logic Vector sc l


109/150

109

Arbitrary Length Logic Vector sc_lv

l The sc_lv data-type represents an arbitrarylength vector in which each bit can have one of fourvalues

l To supply the design that need to be modeled with tri-state capabilities

l These values are exactly the same as the four valuesof type sc_logic

l Type sc_lv is just a sized array of sc_logic objects

l The sc_lv types cannot be used in arithmeticoperations directly

The Operators of the sc lv


110/150

110

The Operators of the sc_lv

sc_uint uint16;sc_int int16;sc_lv lv16;lv16= uint16; // convert uint to lvint16 = lv16; // convert lv to int


Equality == !=

To perform arithmetic functions, first assign sc_lv objects to theappropriate SystemC integer

Fixed Point Types


111/150

111

Fixed Point Types

l For a high level model, floating point numbers areuseful to model arithmetic operations

l Floating point numbers can handle a very large rangeof values and are easily scaled

l Floating point data types are typically converted or

built as fixed point data types to minimize the amountof 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 DSPsoftware

Fixed Point Types (cont)


112/150

112

Fixed Point Types (cont )

l

There are 4 basic types used to model fixed pointtypes in SystemC sc_fixed

sc_ufixed

sc_fix

sc_ufix

l Types sc_fixed and sc_fix specify a signed fixedpoint data type

l Types sc_ufixed and sc_ufix specify an unsignedfixed point data type

Fixed Point Types (cont)


113/150

113

Fixed Point Types (cont )

l

Types sc_fixed and sc_ufixed uses staticarguments to specify the functionality of the type Static arguments must be known at compile time

l Types sc_fix and sc_ufix can use argumenttypes that are non-static Non-static arguments can be variables

Types sc_fix and sc_ufix can use variables todetermine word length, integer word length, etc.

Syntax of the Fixed Point Types


114/150

114

Syntax of the Fixed Point Types

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 model n_bits - number of saturated bits

This parameter is only used for overflow model x,y - object name

The name of the fixed point object being declared.

sc_fixed x;sc_ufixed y;sc_fix x(list of options);sc_ufix y(list of options);

Quantization Modes


115/150

115

Quantization Modes

Overflow Modes


116/150

116

Overflow Modes

The Operators of Fixed Point


117/150

117

The Operators of Fixed Point

Outline


118/150

118

Outline

l Introductionl System Modeling Languagesl SystemC Overviewl Interfaces

l Processesl Data-Typesll Design ExamplesDesign Examplesl System Design Environmentsl HW/SW Co-Verificationl Conclusion

Example: Filter (Block Diagram)


119/150

119

Example: Filter (Block Diagram)

D

C0

D

C1

D

C2 C3

Y[i]=SUM (X[i-t] * C[t]) t=0 3

X[i]

Y[i]

Example: Filter (Architecture)


120/150

120

Example: Filter (Architecture)

C3

C2C1

C0

X3

X2X1

X0

Circular convolution

Xin

Xin


121/150

Example: Filter (UTF)


122/150

122

Example: Filter (UTF)

templateSC_MODULE(filter_u) {

sc_inslave in;sc_outmaster out;filter_s *component;void simulate();SC_CTOR(filter_u);

};

Example: Filter (CA)


123/150

123

Example: Filter (CA)

templateSC_MODULE(filter_c) {

sc_in in;sc_in_clk clock;sc_out out;filter_s *component;void simulate();SC_CTOR(filter_c);

};

Example: Filter (Unit Test)


124/150

124

Example: Filter (Unit Test)

typedef double signal;sc_clock c1("clock2",10);tester_c t1("tester2");t1.clock(c1.signal());t1.setup(5,DATA);

filter_c f1("filter2");f1.in(in);

monitor_c m1("monitor2");m1.clock(c1.signal());

sc_signal in;t1.out(in);signal DATA[5]={1,2,3,4,5};

sc_signal out;

f1.clock(c1.signal());f1.out(out);m1.in(out);sc_start(100);

Example: FFT (Packet)


125/150

125

Example: FFT (Packet)

templateclass fft_packet {

public:signal data[length];fft_packet(signal *data) {

for(int i=0;idata[i]=data[i];

}fft_packet() {}

};

Example: FFT (UTF)


126/150

126

Example: FFT (UTF)

templateSC_MODULE(fft_u) {

sc_inslavein;

sc_outmaster out;fft_s *component;void simulate();SC_CTOR(fft_u);

};


127/150

The Supported Tools for SystemC


128/150

128

The Supported Tools for SystemC

l Platform and Compilerl System design environments

Platform and Compiler


129/150

129

Platform and Compiler

l Typically, a compiler for C++ standard cancompile the SystemC source code well SystemC just a extended template

l GNU gcc for many platforml Sun with solaris

Forte c++l HP

Hp aC++l Intel with Microsoft OS

MS Visual C++

System Design Environments


130/150

130

Syste es g v o e ts

l Synopsys CoCentric System Studio (CCSS)

l Cadence Signal Processing Worksystem (SPW)

l

Agilent Advanced Design System (ADS)l CoWare

N2C Design Systeml

CoCentric System Level Design Platform


131/150

131

y g

CoCentric System Studio

SystemCExecutable

Specification

PerformanceExploration

HW/SW Co-design

C/SystemC,ReferenceDesign Kit

Processor Model

SystemCSynthesizable

model

SoftwareC-Code

Chip Verification CoCentricSystemC Compiler

SoftwareImplementation



132/150

132

y g

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



133/150

133

y g

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



134/150

134

y g

l Path to implementation Synthesizable SystemC code generated automatically

Cocentric System StudioExecutable specification

C/C++/SystemC

Cocentric SystemC Compiler

Design

Compiler

Physical

Compiler

C/C++ softwareImplementation flow

Available System

Advanced Design System


135/150

135

g y

ADSDSP Designer

PtolemyModels

HDLSimulation

HardwareEmulation

LogicSynthesis

C/C++

ModelsMATLABHDL Models

Measurement

Instrumentation

Outline


136/150

136

l Introductionl System Modeling Languagesl SystemC Overviewl Interfacesl

Processesl Data-Typesl Design Examplesl System Design Environmentsll HW/SW Co-VerificationHW/SW Co-Verificationl Conclusion


137/150

Pre-Silicon Prototype


138/150

138

yp

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

Virtual Prototypes


139/150

139

yp

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

Verification Speed


140/150

140

RTL

TransactionLevel

AlgorithmLevel

busCycle

Latencyannotation

untimedCycle

SubCycle

Cell loss ? Bit error rate??

Bus bandwidth? Cache size?

Handshake? reset?



141/150


142/150

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


143/150

143

l

Simulate in minutes instead of daysl Early architecture closure reduces risk by 80%l Start software development 6 months earlierl Simulate 100x~1000x faster than RTLl HW designers can use the tools which are familiar

to theml SW programmers can use all their favorite

debugger to observe software state and control

the executions


144/150

Synopsyss SystemC Solution


145/150

145

SoC

DesignWare

SystemC

Compiler

Design Compiler/Physical Compiler

System Studio

C/C++Compiler

l

System Studio SystemC simulation

l SystemC Compiler SystemC synthesis

l DesignWare

AMBA/ARM SystemCmodels


Synopsys System Studio


146/150

146

A l g o r i t h m

Debugger

Simulation

Memory

Bus S

o f t w a r e H a

r d w ar e

Ar ch i t e c t ur e

ARM9 / AHB

SystemC


Mentor Graphic : Seamless CVE


147/150

147Reference : Mentor Graphics

Cadence : Incisive Platform


148/150

148Reference : Cadence

Conclusions


149/150

149

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 forsystem 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 abstractionl A hot and hard area for designers and EDA vendors

References


150/150

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 Users 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 Chenl 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+ htmlhtt // f t gil t / d t / d 2002 ht l

modelling interconnects

Documents