SystemC Tutorial

John Moondanos Strategic CAD Labs, INTEL Corp. & GSRC Visiting Fellow, UC Berkeley SystemC Introduction ƒ Why not leverage experience of C/C++ developers for H/W & System Level Design? ƒ But C/C++ have no ƒ notion of time ƒ No event sequencing ƒ Concurrency ƒ But H/W is inherently concurrent ƒ H/W Data Types ƒ No ‘Z’ value for tri-state buses SystemC is …

ƒ C++ Class Library use for ƒ Cycle-Accurate model for Software Algorithm ƒ Hardware Architecture ƒ Interface of SoC (System-on-Chip) ƒ System-level designs ƒ Executable Specification ƒ www.systemc.org SystemC Environment SystemC History ƒ SystemC 1.0 ƒ Provide VHDL like capabilities ƒ Simulation kernel ƒ Fixed point arithmetic data types ƒ Signals (communication channels) ƒ Modules ƒ Break down designs into smaller parts SystemC History ƒ SystemC 2.0 ƒ Complete library rewrite to upgrade into true SLDL ƒ Events as primitive behavior triggers ƒ Channels, Interfaces and Ports ƒ Much more powerful modeling for Transaction Level ƒ Future SystemC 3.0 ƒ Modeling of OSs ƒ Support of embedded S/W models Objectives of SystemC 2.0 ƒ Primary goal: Enable System-Level Modeling ƒ Systems include hardware and software ƒ Challenge: ƒ Wide range of design models of computation ƒ Wide range of design abstraction levels ƒ Wide range of design methodologies SystemC 2.0 Objectives (cont) ƒ SystemC 2.0 ƒ Introduces a small but very general purpose modeling foundation => Core Language ƒ Support for other models of computation, methodologies, etc ƒ They are built on top of the core language, hence are separate from it ƒ Even SystemC 1.0 Signals are built on top of this core in SystemC 2.0 ƒ Other library models are provided: ƒ FIFO, Timers, ... Communication and Synchronization ƒ SystemC 1.0 Modules and Processes are still useful in system design ƒ But communication and synchronization mechanisms in SystemC 1.0 (Signals) are restrictive for system-level modeling ƒ Communication using queues ƒ Synchronization (access to shared data) using mutexes SystemC Language Architecture

Core System SystemC vs. Metropolis

ƒ Constructs to model system architecture ƒ Hardware timing ƒ Concurrency ƒ Structure ƒ Adding these constructs to C ƒ SystemC ƒ C++ Class library ƒ Standard C/C++ Compiler : bcc, msvc, gcc, etc… ƒ Metropolis ƒ New keywords & Syntax ƒ Translator for SystemC ƒ Many More features… System Design Methodology

ƒ Current ƒ Manual Conversion from C to HDL Creates Errors ƒ Disconnect Between System Model and HDL Model ƒ Multiple System Tests

ƒ SystemC (Executable-Specification) ƒ Refinement Methodology ƒ Written in a Single Language Modeling Terms (I) ƒ Untimed Functional (UTF) ƒ Refers to model I/F and functionality ƒ No time used for regulating the execution ƒ Execution & data transport in 0 time ƒ Timed Functional (TF) ƒ Refers to both model I/F and functionality ƒ Time is used for the execution ƒ Latencies are modeled ƒ Data Transport takes time Modeling Terms (II) ƒ Bus Cycle Accurate (BCA) ƒ Refers to model I/F, not functionality ƒ Timing is cycle accurate, tied to some global clock ƒ Does not infer pin level detail ƒ Transactions for data transport ƒ Pin Cycle Accurate (PCA) ƒ Refers to model I/F not model functionality ƒ Timing is cycle accurate ƒ Accuracy of the I/F at the pin Level ƒ Register Transfer (RT) Accurate ƒ Refers to model functionality ƒ Everything fully timed ƒ Complete detailed Description, every bus, every bit is modeled Model Types (1)

ƒ System Architectural ƒ Executable specification for H/W & S/W ƒ Architecture Exploration, algorithm determination & proof ƒ I/Fs are UTF with no pin detail for modeling communication protocols ƒ Functionality UTF, sequential since it’s untimed ƒ System Performance ƒ Timed executable specification for bith H/W & S/W ƒ Used for time budgeting ƒ Concurrent behavior modeled ƒ Transaction Level (TLM) ƒ Typically describe H/W only ƒ Model I/Fs are TF, functionality TF as well (either not cycle accurate) ƒ Data Transfers & system Behavior modeled as transactions Model Types (2)

ƒ Functional Model ƒ Above TLM, i.e. System Architectural & System Performance ƒ System Level ƒ Above RTL ƒ Behavioral Synthesis ƒ Architectural Analysis & Implementation ƒ I/F cycle accurate with pin level detail ƒ Functionality TF and not cycle accurate ƒ Bus Functional Model (BFM) ƒ Used for simulation (mainly of processors) ƒ Not meant for synthesis ƒ I/F pin cycle accurate ƒ Transactions for functionality ƒ Register Transfer Level (RTL) ƒ Verilog, VHDL ƒ Gate Level ƒ not good in SystemC Current Methodology

- Manual Conversion Creates Errors - Disconnect Between System Model and HDL Model C/C++ System Level Model - Multiple System Tests

Refine Analysis VHDL/Verilog

Result Simulation

Synthesis SystemC Methodology Using Executable Specifications

ƒ Ensure COMPLETENESS of Specification “Create a program that Behave the same way as the system” ƒ UNAMBIGUOUS Interpretation of the Specification ƒ Validate system functionality before implementation ƒ Create early model and Validate system performance ƒ Refine and Test the implementation of the Specification SystemC and User Module

User User User ModuleUser ModuleUser ..... ModuleUser Mo#1dule M#2odule Mo#Ndule #1 #2 #N

Event & Signa l I/F

C++ Class Library

Event s

Hardware Simulation Kernel (Event Scheduler)

SystemC SystemC Executable Specification Executable Specification SystemC Highlights (1) ƒ SystemC 2.0 introduces general-purpose ƒ Events ƒ Flexible, low-level synchronization primitive ƒ Used to construct other forms of synchronization ƒ Channels ƒ A container class for communication and synchronization ƒ They implement one or more interfaces ƒ Interfaces ƒ Specify a set of access methods to the channel ƒ Other comm & sync models can be built based on the above primitives ƒ Examples ƒ HW-signals, queues (FIFO, LIFO, message queues, etc) semaphores, memories and busses (both at RTL and transaction-based models) SystemC Highlights (2) ƒ Support Hardware-Software Co-Design ƒ All constructs are in a C++ environment ƒ Modules ƒ Container class includes hierarchical Modules and Processes ƒ Processes ƒ Describe functionality ƒ Almost all SLDL have been developed based on some underlying model of network of processes ƒ Ports ƒ Single-directional(in, out), Bi-directional mode A system in SystemC A system in SystemC SystemC Highlights (3)

ƒ Constructs in a C++ environment (continued) ƒ Clocks ƒ Special signal, Timekeeper of simulation and Multiple clocks, with arbitrary phase relationship ƒ Event Driven simulation ƒ High-SpeedEvent Driven simulation kernel ƒ Multiple abstraction levels ƒ Untimed from high-level functional model to detailed clock cycle accuracy RTL model ƒ Communication Protocols ƒ Debugging Supports ƒ Run-Time error check ƒ Waveform Tracing ƒ Supports VCD, WIF, ISBD Data Types

ƒ SystemC supports ƒ Native C/C++ Types ƒ SystemC Types ƒ SystemC Types ƒ Data type for system modeling ƒ 2 value (‘0’,’1’) logic/logic vector ƒ 4 value (‘0’,’1’,’Z’,’X’) logic/logic vector ƒ Arbitrary sized integer (Signed/Unsigned) ƒ Fixed Point types (Templated/Untemplated) Communication and Synchronization (cont’d)

Interfaces Module1 Module2 Channel

Events

Ports to Interfaces A Communication Modeling Example: FIFO

Write Interface Producer Consumer FIFO

Read Interface FIFO Example: Declaration of Interfaces class write_if : public sc_interface p c { FIFO public: virtual void write(char) = 0; virtual void reset() = 0; }; class read_if : public sc_interface { public: virtual void read(char&) = 0; virtual int num_available() = 0; }; Declaration of FIFO p c channel FIFO

class fifo: public sc_channel, void write(char c) { public write_if, if (fifo_full()) public read_if wait(read_event); { data[ ] = c; private: ++num_elements; enum e {max_elements=10}; write_event.notify(); char data[max_elements]; } int num_elements, first; sc_event write_event, read_event; void read(char &c) { if (fifo_empty()) bool fifo_empty() {…}; wait(write_event); bool fifo_full() {…}; c = data[first]; --num_elements; public: first = …; fifo() : num_elements(0), read_event.notify(); first(0); } Declaration of p c FIFO channel (cont’d) FIFO

void reset() { num_elements = first = 0; }

int num_available() { return num_elements; } }; // end of class declarations FIFO Example (cont’d) ƒ Any channel must ƒ be derived from sc_channel class ƒ be derived from one (or more) classes derived from sc_interface ƒ provide implementations for all pure virtual functions defined in its parent interfaces FIFO Example (cont’d)

ƒ Note the following wait() call ƒ wait(sc_event) => dynamic sensitivity ƒ wait(time) ƒ wait(time_out, sc_event) ƒ Events ƒ are the fundamental synchronization primitive ƒ have no type, no value ƒ always cause sensitive processes to be resumed ƒ can be specified to occur: ƒ immediately/ one delta-step later/ some specific time later Completing the Comm. p c Modeling Example FIFO

SC_MODULE(producer) { SC_MODULE(consumer) { public: public: sc_port out; sc_port in;

SC_CTOR(producer) { SC_CTOR(consumer) { SC_THREAD(main); SC_THREAD(main); } }

void main() { void main() { char c; char c; while (true) { while (true) { out.write(c); in.read(c); if(…) cout<< out.reset(); } in.num_available(); } } } }; }; Completing the Comm. Modeling Example (cont’d)

p c SC_MODULE(top) { FIFO public: fifo afifo; producer *pproducer; consumer *pconsumer;

SC_CTOR(top) { pproducer=new producer(“Producer”); pproducer->out(afifo);

pconsumer=new consumer(“Consumer”); pconsumer->in(afifo); }; Completing the Comm. Modeling Example (cont’d)

ƒ Note: ƒ Producer module ƒ sc_port out; ƒ Producer can only call member functions of write_if interface ƒ Consumer module ƒ sc_port in; ƒ Consumer can only call member functions of read_if interface ƒ Producer and consumer are ƒ unaware of how the channel works ƒ just aware of their respective interfaces ƒ Channel implementation is hidden from communicating modules Completing the Comm. Modeling Example (cont’d) ƒ Advantages of separating communication from functionality ƒ Trying different communication modules ƒ Refine the FIFO into a software implementation ƒ Using queuing mechanisms of the underlying RTOS ƒ Refine the FIFO into a hardware implementation ƒ Channels can contain other channels and modules ƒ Instantiate the hw FIFO module within FIFO channel ƒ Implement read and write interface methods to properly work with the hw FIFO ƒ Refine read and write interface methods by inlining them into producer and consumer codes SystemC refinement SystemC Channel Replacement SystemC Adapter Insertion SystemC Adapter Merge SystemC scheduler ƒ Like most modeling languages SystemC has a simulation kernel, too ƒ Event Based Simulation for modeling concurrency ƒ Processes executed & their outputs updated based on events ƒ Processes are scheduled based on their sensitivity to events ƒ Similarity with key VHDL simulation kernel aspects is evident SystemC & VHDL Similarities

SC_THREAD(proc_1); sensitive << Trig.pos( ); SC_THREAD(proc_2); sensitive << Trig.pos( );

ƒ Which process should go first? ƒ Does it actually matter? ƒ On sc_signals follows VHDL paradigm ƒ Process execution and signal update done in 2 phases, order of processes does not matter ƒ Concept of delta cycles ƒ Simulation is deterministic ƒ But SystemC can model concurrency, time & communication in other ways as well SystemC & non Determinism ƒ Delta Cycle = Evaluation Phase + Update Phase ƒ Presence of 2 phases guarantees determinism ƒ But for modeling S/W we need non- determinism ƒ Employ the notify( ) method of an sc_event (see previous producer/consumer example) SystemC Scheduler & Events ƒ notify() with no arguments ƒ Called Immediate Notification ƒ Processes sensitive to this event will run in current evaluation phase ƒ notify(0) ƒ Processes sensitive to this event will run in evaluation phase of next delta cycle ƒ notify(t) with t>0 ƒ Processes sensitive to this event will run during the evaluation phase of some future simulator time SystemC Simulator Kernel

1. Init: execute all processes in unspecified order 2. Evaluate: Select a ready to run process & resume its execution. May result in more processes ready for execution due to Immediate Notification 3. Repeat 2 until no more processes to run 4. Update Phase 5. If 2 or 4 resulted in delta event notifications, go back to 2 6. No more events, simulation is finished for current time 7. Advance to next simulation time that has pending events. If none, exit 8. Go back to step 2 Metropolis vs. SystemC

ƒ Metro more general model of computation ƒ Different operational & denotational semantics ƒ Metro Formal Semantics & tools ƒ Metro Quantity Managers ƒ For performance analysis ƒ For modeling of Operating Systems References ƒ www.doulos.com ƒ www.forteds.com