6595814 Wang Modeling With SystemC

Modeling with SystemC Workshop Version 1.4

TM

An investment in continuing success! © 2000 Author: Martin Wang 3 Days SystemCTM training based on SystemC Ver. 1.0 Author: Martin Wang of SLD

Workshop Prerequisites


Familiarity with UNIX workstations running Xwindows OR Windows NT




Familiarity with vi, emacs, or other UNIX/NT text editors




Familiarity with C programming language

2 Ver 1.4

1

Workshop Target Audience


System Architects




HW Engineers responsible for board, ASIC and FPGA design




Test/Verification Engineers




Programmers, software developers System Architect

Software Developer

SystemCTM RTL Designer

Lead Architect

3 Ver 1.4

Workshop Goal

Acquire the basic skills to write, simulate and debug general Hardware Models using SystemCTM Ver 0.91

4 Ver 1.4

2

Workshop Measurable Objectives By the end of this workshop, you should be able to:




Demonstrate an applied, working knowledge of SystemCTM C++ class libraries.




Write general hardware models with SystemCTM.




Simulate and debug hardware models using SystemCTM.




Write test-benches and verify SystemCTM models.

This is not just a language class, this is an design class! 5 Ver 1.4

Agenda: Day One DAY 1

Unit

Topic

1

Why C-based Design Flow

2

SystemCTM - Introduction

3

C++ for the C Programmer

4

Datatypes for Diff Abstraction Level

5

Communication with Signals

Lab

6 Ver 1.4

3

Agenda: Day One DAY 1

Unit

Topic

6

Ports and Signals

7

Asynchronous Function Process

8

Asynchronous Thread Process

Lab

7 Ver 1.4

Agenda: Day Two DAY 2

Unit

Topic

9

Special Case: Synchronous Process

10

Process Execution Order

11

Top_Level and Testbench

12

Channels for Abstract Protocol

13

Hierarchy for Modular Design

Lab

8 Ver 1.4

4

Agenda: Day Three DAY 3

Unit

Topic

14

Global and Local Watching

15

Modeling BUS with Resolved Vector

16

Refinement

17

Functional I/F

18

Hardware/Software Co-verification

Lab

9 Ver 1.4

Agenda: Day Three DAY 3

Unit

Topic

19

System-on-a-Chip

20

Workshop Summary

21

Appendix and Labs Solutions

22

Quick Reference Guide

Lab

10 Ver 1.4

5

Agenda: Structured Labs & Exercises DAY Lab

Topic

1

Getting Started

2

Simple Arithmetic Pipeline Design

3

Simple Memory Controller

4

4x4 Multicast Helix Packet Switching

5

Multiple-Cycle RAM

6

Simple RISC CPU

Lab

11 Ver 1.4

Agenda: Labs DAY Lab

Topic

7

Image Smoother

8

Simple Arithmetic Pipeline Design II

9

Master-Slave Bus System

10

Simple FIR Filter IP

11

RSA Public-Key Crypto-system

Lab

Labs & exercises will challenge your understanding of the concepts taught Additional experimentation labs are provided for those who might finish the required labs early

12 Ver 1.4

6

Icons Used in this Workshop Icon

What it Means

Icon

What it Means

Lab Exercise

Caution

Question

Note

Hint, Tip, or Suggestion

Remember

Simulation Specific

Implementation Specific


Lab

Solutions at the end of the book 13

Ver 1.4

Abbreviations and Acronyms Acronym

Meaning

FSM

Finite State Machine

GTECH

Generic Technology

HDL

Hardware Description Language

RTL

Register Transfer Level

SOLD

Synopsys On-Line Documentation

14 Ver 1.4

7

Agenda: Day One DAY 1

Unit

Topic

1

Why C-based Design Flow

2

SystemCTM - Introduction

3

C++ for the C Programmer

4

Datatypes for Diff Abstraction Level

5

Communication with Signals

Lab

15 Ver 1.4

Today’s Market Development Times are getting shorter 1st Silicon tape-out need to be functional !

Years to 1 Million Sales Sales Volume

1 Million Units

PCS

Cellula 3G Cellul r ar

PCVCR Color TV

Cable TV Black & White TV

DVD

5

10

15

16 Ver 1.4

8

Designers Challenges Design Complexity is becoming greater Design Complexity is still increasing

System on a Chip

High level

Design Complexity

Behavioral Synthesis Cycle-Based Simulation Design Reuse Deep Submicron

Gates Logic Synthesis

Transistors ASICs Place & Route Logic Simulation

Design Productivity

Polygons SPICE Pattern Generation IC CAD

1975

1980

1985

1990

1995

2000

17 Ver 1.4

The Design Process Today System Level Design Hardware and Software Algorithm Development Processor Selection Done mainly in C/C++ C/C++ Environment

Refinement Manual Translation

Refinement

IC Development Hardware Implementation Decisions Done mainly in Verilog/VHDL

The Verification Process

$$

Software Code development RTOS details Done mainly in C/C++

Emulation / Prototyping

EDA Environment

C/C++ Environment

Productivity Gaps 18 Ver 1.4

9

IC Development Process The current design flow Same flow for RTL, schematic, polygons, etc Design done then captured in an EDA environment Very little, if any, “what-if” exploration

Library-based SystemDesign Methodology

Designers can end up focussing more on “data management” than “design”

19 Ver 1.4

HDL Based Flow C/C++

4. Hand over specification document

1. Conceptualize 2. Simulate in C++ 3. Write specification document

HDL

5. Understand 6. (Re)Implement in HDL 7. (Re)Verify 8. Synthesize from HDL

Problems:Written specifications are incomplete and inconsistent Translation to HDL is time consuming and error prone

20 Ver 1.4

10

C++ Based Flow C/C++

C/C++ 1. Conceptualize 2. Simulate in C++ 3. Write specification document 4. Hand over • Executable specification • Testbench • Written specification 5. Understand 6. Refine in C++ 7. Verify reusing testbenches 8. Synthesize from C++

Turning Algorithms into the Right Architectures for ASICs quicker and better 21 Ver 1.4

Why C/C++ Based Design? Specification between architect and implementer is executable High simulation speed at the higher level of abstraction Refinement, no translation into HDL (no „semantic gap“) Testbench re-use

C/C++

SoC Design

System Architect

C/C++

Software Designer

Marketing & Sales HDL

Hardware Designer

22 Ver 1.4

11

Existing Approaches are limited ... Languages such as C/C++ and Java are not created to model HW Lack of uniform modeling style Translation tools (C/C++ to HDL) No clear design methodology Sub-optimal QoR Why another translation tool?

23 Ver 1.4

Can C++ be used as is?
C++

does not support




Hardware style communication




Notion of time




Concurrency









Time sequenced operations. Hardware and systems are inherently concurrent, i.e. they operate in parallel.

Reactivity





Signals, protocols, etc.

Hardware is inherently reactive, it responds to stimuli and is in constant interaction with its environment, which requires handling of exceptions.

Hardware data types


Bit type, bit-vector type, multi-valued logic type, signed and unsigned integer types and fixed-point types.

24 Ver 1.4

12

Summary


Why

C-based Design Flow
covered HDL based flow
covered C++ Based flow
covered benefits of a C++ based flow
covered “Can C++ be used as is?”

25 Ver 1.4

Agenda: Day One DAY 1

Unit

Topic

1

Why C-based Design Flow

2

SystemCTM - Introduction

3

C++ for the C Programmer

4

Datatypes for Diff Abstraction Level

5

Communication with Signals

Lab

26 Ver 1.4

13

C++ powered by SystemCTM Purely Algorithm /Software in C++

What is SystemC ?

SystemC is a C++ Class library

HW/SW partitioning

Include any C++ programs, libraries, encapsulation ... a methodology for modeling SoC designs consisting DSPs, ASICs, IPCores, Interfaces, ...

High Level Abstract Hardware Model in SystemC

SystemC also enables Modeling at high level of abstraction e.g. communication protocols Refinement to hardware Software modeling - interrupts, exception handling System wide verification Hardware/Software co-verification IP exchange

C++ Software Model

Behavioral Level Hardware Model in SystemC

SystemC provides all the advantages of Verilog and VHDL Concurrent processes e.g. methods, threads, clocked threads Concept of a clock Wide variety of bit-true data types

C++ Software Model

SystemC IS NOT Another C++ dialect -> it is C++ Just for hardware modeling only -> you can model hardware AND software in C++ with SystemC

Register Transfer Level Hardware Model in SystemC C++ Software Model

27

C++ Programs

Ver 1.4

Short History of SystemCTM

Scenery

V0.9 Launches 9/27/1999

1997 DAC Paper

V1.0 Release 3/2000

fixed pt datatypes

HDL constructs

1997

1999

1998

2000

• Source Code • User Guide • Reference Manual • Discussion Forum • All available from http://www.SystemC.org 28 Ver 1.4

14

Getting Started with SystemC Compiler gcc native compiler Visual C++, SUN cc Debugger gdb, ddd lint, profiler, memory access checking quantify, purify www.gnu.org

29 Ver 1.4

First example Compiler version which gcc, gcc -v which architecture is used autoconf helps installation ./configure; gmake Makefiles control what is included compile directives libraries include files

30 Ver 1.4

15

Books/Training Nothing replaces hands-on experience! Books Kernigham/Ritchie; The C programming language Stroustrup; The C++ Programming language Lippman; C++ primer man pages web sources

31 Ver 1.4

Compile SystemC and Run the executable! your standard C/C++ development environment

class library and simulation kernel

linker debugger

.......

libraries

Interface

compiler

....

header files

DSP

IP-Core ASIC

source files for system and testbenches

„make“ e l tab n“ ecuicatio x e a.out „ ecif sp executable = simulator

32 Ver 1.4

16

A SystemCTM System
System

consists of a set of concurrent processes describes functionality
Processes communicate with each other through signals and channels
Processes can be combined into modules to create hierarchy
Process

System Process 3 Process 4

signals Process 1

Process 2 channel

Process 5

Module 1

33 Ver 1.4

Simple Example - 1

main.cc a1 Stimulus Generator a2

in2

in1 in1 Adder out

re

Response Monitor

in2

clk

stimgen.cpp stimgen.h

adder.cpp adder.h

main.cpp

monitor.cpp

+

monitor.h

out

34 Ver 1.4

17

Simple Example - 2 // top level routine/level #include #include #include #include

“systemc.h” “adder.h” “stimgen.h” “monitor.h”

main.cc

int sc_main(int ac, char *av[ ]){ // Create signals sc_signal sc_signal sc_signal

to tie modules s1; s2; s3;

// Create clock sc_clock clock(“CLOCK”, 10, 0.5);

a1 Stimulus Generator a2

in1 Adder out

re

Response Monitor

in2

clk

stimgen.cpp

// Instantiate modules adder Add(“MyAdd”); Add // 3 rows, 7 columns sc_2d b (5, 10); // 5 rows, 10 columns

542 Ver 1.4

271

Appendix B: sc_2d Operators sc_2d operators:


[ ] [ ] used to access an individual element

Example: sc_2d a(10, 16); sc_bool_vector c(16); bool d; c = a[0]; d = a[7][2];

543 Ver 1.4

Appendix B: sc_2d Type Conversions


Assignment operator = is used.




Can assign one two-dimensional SystemCTM array to another, provided they have the same dimensions and same type for elements.




Can initialize with C++ one-dimensional array
Through constructor for the SystemCTM two-dimensional array
Or though assignment Assignment example: int init_array [] = { //Column numbers //0 1 2 3 4 5 6 1, 2, 3, 4, 5, 6, 7, //row 0 11, 12, 13, 14, 15, 16, 17, //row 1 111, 121, 131, 141, 151, 161, 171 //row 2 }; sc_2d actual_array(3, 7,init_array); // actual_array[0][0] = init_array[0] = 1 // actual_array[0][6] = init_array[6] = 7 // actual_array[1][2] = init_array[9] = 13 // actual_array[2][6] = init_array[20] = 171

544 Ver 1.4

272

Appendix C Debugging

Appendix C: Debugging with SystemCTM - 1 Debugging. You determine what is going wrong in your simulation. Debugging consists of:
Controlling the execution of your simulation
Examining values of key data during the course of simulation Use a debugger tool for source-level debugging:
Unix: gdb, xgdb, dbx
NT: Visual C++ development environment Use "print" I/O statements in your code
SystemCTM provides useful data Trace waveforms for post-simulation viewing

Tip: To enable source-level debugging, compile with the -g option in gcc

546 Ver 1.4

273

Appendix C: Debugging with SystemCTM - 2 Controlling the execution of the simulation: SystemCTM is different from normal, sequential programming
Single-stepping from the beginning is not productive
You don't know the actual order in which your processes will execute Tips:






Set breakpoints in processes (first executable statement inside the while loop)
For asynchronous blocks, at first executable statement Single-step within processes Step over calls to SystemCTM built-in functions

proc1::entry() { // Declarations, initialization while (true) { val = some_func(in_sig); out_sig.write(val); wait(); }

Set breakpoint here }

Step OVER

547 Ver 1.4

Appendix C: Debugging with SystemCTM - 3 Examining data values: While single-stepping, use the print command in the debugger
gdb is C++ savvy Use C++ I/O to print out data values
SystemCTM data types know how to display themselves using C++ I/O
If you must use C-style I/O, SystemCTM data types have a to_string() method proc1::entry() { while (true) { val = some_func(in_sig); printf("proc1(%s): in_sig = %s\n", sc_time_stamp(), in_sig.to_string()); cout