SystemC Language Tutorial Bishnupriya Bhattacharya Cadence Design Systems ISCUG 2013

Agenda Introduction Core Language Constructs Other Resources Structural Elements Modules Ports Interfaces Channels Scheduling Semantics and Control Flow Events and Processes Process Control Constructs (p1666-2011) The Event Scheduler Control Flow sc_main. sc_start, sc_stop, sc_pause Data Types (Not covered) Other Resources

Agenda Introduction Core Language Constructs Other Resources Structural Elements Modules Ports Interfaces Channels Scheduling Semantics and Control Flow Events and Processes Process Control Constructs (p1666-2011) The Event Scheduler Control Flow sc_main. sc_start, sc_stop, sc_pause Data Types (Not covered) Other Resources

Standards Committee and Industry Participation IEEE 1666 standard – overseen by Accellera Systems Initiative “Accellera Systems Initiative is an independent, not-for profit organization dedicated to create, support, promote, and advance system-level design, modeling, and verification standards for use by the worldwide electronics industry.” – http://www.accellera.org/about Mission “Provide design and verification standards required by systems, semiconductor, IP, and design tool companies to enhance a front-end design automation process.” Corporate members as of this date AMD, ARM, Cadence, Freescale, Intel, Magillem, Mentor Graphics, NXP, Qualcomm, Renesas, SpringSoft, STMicroelectronics, Synopsys, TI SystemC Working Groups Analog/Mixed-signal, Configuration, Control and Inspection, Language, Synthesis, Transaction-level Modeling, Verification

What is SystemC? “SystemC is an ANSI standard C++ class library for system and hardware design for use by designers and architects who need to address complex systems that are a hybrid between hardware and software.” – IEEE Std. 1666-2011 SystemC LRM SystemC is a C++ class library that supports design and verification of hardware and software at multiple levels of abstraction SystemC provides a unified environment for architects, verification engineers and implementation engineers

Layered SystemC Architecture Layered Libraries Verification library TLM library, etc. Primitive Channels Signal, FIFO, Mutex, Semaphore, etc. Structural Elements Modules Ports Interfaces Channels Data Types 4-valued logic Bits and Bit Vectors Arbitrary Precision Integers Fixed point types Event-driven Simulation Events Processes C++ Language Standard IEEE Std. 1666-2011 includes the TLM 2.0 library. IEEE Std. 1666-2005 ISO/IEC Std. 14882-2003

Transaction Level Modeling and Verification Yet another RTL modeling language is not interesting. What makes SystemC interesting? Modeling at a higher level of abstraction increases performance SystemC facilitates transaction level modeling and verification Transaction level modeling and verification increases your productivity Less detail means higher performance and easier debug Earlier testing (before RTL) means less expensive bug fixes SystemC TLM Models popular in Virtual Platforms for SW bring up Transaction Header Payload Transactor A transactor adapts between a transaction level interface and a signal level interface

Refining the Transaction Level Model You refine the transaction level model (eventually to synthesizable RTL) while maintaining the transaction level system environment. Transaction Producer (random) Transaction-Level Model (golden) Transaction Consumer (checker) Transactor (slave) Refined Model (RTL) Transactor (master)

Agenda Introduction Core Language Constructs Other Resources Structural Elements Modules Ports Interfaces Channels Scheduling Semantics and Control Flow Events and Processes Process Control Constructs (p1666-2011) The Event Scheduler Control Flow sc_main. sc_start, sc_stop, sc_pause Data Types (Not covered) Other Resources

SystemC Structural Components Modules communicate through their ports Ports connect to channels and to ports of the parent module Processes procedurally access channel methods (read, write, etc.) Directly or through ports Processes communicate with other processes through events and variables module P p_in p_out channel process

What is a Module? The Merriam-Webster dictionary says: “...any in a series of standardized units...” A module is a special SystemC class A SystemC module may contain (instantiate) SystemC objects, such as processes, ports, channels, other modules The module is the basic building block of your simulation model module process

What is a Process? The Merriam-Webster dictionary says: “...a series of actions...” A process defines some or all of the behavior of your simulation model A SystemC process is a module class method registered as a process Define the method Register the method as a process Specify what event(s) trigger process execution The kernel schedules process execution in response to an event module process

Interfaces What is an interface? In SystemC: To paraphrase the Merriam-Webster dictionary: “A system by which independent systems interact” In SystemC: An interface defines (but does not implement) access methods All SystemC interfaces inherit the abstract sc_interface base class. A channel implements the methods of one or more interfaces A port accesses interface methods implemented by a channel interface defines access methods template <typename T> class my_interface : public sc_interface { bool read(T&) = 0; bool write(const T&) = 0; } module channel P I bind port to channel port accesses methods channel implements methods

Channels What is a channel? In SystemC: To paraphrase the Merriam-Webster dictionary: “A means of passing, transmitting, or communicating” In SystemC: An interface defines (but does not implement) a set of access methods A channel implements the methods of one or more interfaces A port accesses interface methods implemented by a channel interface defines access methods template <typename T> class my_channel : public my_interface { bool read(T&); bool write(const T&); } module channel P I bind port to channel port accesses methods channel implements methods

Ports What is a port? In SystemC: To paraphrase the Merriam-Webster dictionary: “A point of entry” In SystemC: An interface defines (but does not implement) a set of access methods A channel implements the methods of one or more interfaces A port accesses interface methods implemented by a channel class my_module : public sc_module { sc_port<my_interface> p1; SC_CTOR(my_module) { SC_THREAD(my_proc); } void my_proc() { int 17; p1->write(17); … interface defines access methods module channel P I bind port to channel port accesses methods channel implements methods

What is a Port? A port makes an external channel’s methods available to module processes In the module, define its ports sc_port<if_t<data_t> > p_out; In the module process, access channel methods through ports the pointer -> method of sc_port is overloaded to return the bound channel In the instantiating module’s constructor, bind the child module ports to channels (connect the netlist) module1_inst.p_out(channel_inst); Ports in general do not directly connect to other ports Exception: A child module port can directly connect to a port of its parent module P p_in p_out channel process

What is an export? Represented by sc_export class A port requires an interface An export provides an interface An export is a way for a module to expose an interface externally An export is bound in the constructor of its parent module module module process P E channel

Why Separate the Interface and Channel Descriptions? Separation of interface (specification) from channel (implementation) facilitates reuse by making different implementations of a channel “plug-compatible”. Abstract Channel Transaction Producer (random) Transaction Consumer (checker) Refined Channel Adapter Transaction Producer (random) Transaction Consumer (checker) Adapter P P P P

Agenda Introduction Core Language Constructs Other Resources Structural Elements Modules Ports Interfaces Channels Scheduling Semantics and Control Flow Events and Processes Process Control Constructs (p1666-2011) The Event Scheduler Control Flow sc_main, sc_start, sc_stop, sc_pause Data Types (Not covered) Other Resources

Simulation Events SystemC uses the sc_event class to represent simulation events sc_event e; e.notify() // Notification (immediate) e.notify(10, SC_NS) // Notification (delayed) e.notify(SC_ZERO_TIME) // Notification (delta)

Modeling Design Behavior with Processes You model design behavior using processes and events. Events trigger process execution Each process models a portion of the design behavior The statements of a process execute sequentially Multiple processes can execute “concurrently” using co-routine semantics A process does not pre-empt or interrupt another process A process voluntarily yields Non-deterministic order of concurrent process execution // SystemC SC_METHOD(blk); sensitive << in1; void blk(){...} // VHDL blk: process (in1) begin ... end process; // Verilog always @(in1) begin : blk ... end

Statically Registering Processes A static SystemC process is a member method of your module. You register it as a process so that the kernel can schedule it. Register it using the SC_METHOD, SC_THREAD or SC_CTHREAD macros. Place these macros in the module constructor code body. SC_MODULE(mod) { sc_signal<int> s1; SC_CTOR(mod) : s1(“s1”) { SC_METHOD(run); sensitive << s1; dont_initialize(); } void run() { cout << “received “ << s1.read() << endl; } }; SC_MODULE(mod) { sc_signal<int> s1 SC_CTOR(mod) : s1(“s1”) { SC_THREAD(run); } void run() { int i = 0; while (1) { wait(10, SC_NS) ; s1.write(i++); } } };

Specifying Process Sensitivity The simulation kernel schedules processes in response to events: Resumes thread and clocked thread processes Calls method processes Processes are sensitive to events You can specify static sensitivity as you register the process: In the module constructor for thread and method processes As a macro argument for clocked thread processes You can specify dynamic sensitivity for threads and methods inside the process function: For thread processes use wait() with appropriate arguments For method processes use next_trigger() with appropriate arguments

The Method Process Use the high-performance method process to model hardware that only reacts to transitions of its inputs. Cannot model any state information Cannot consume time Register a method process with the SC_METHOD macro. Normally first executes during the initialization phase If dont_initialize() then first executes when first triggered Thereafter executes from beginning to end upon each trigger Cannot suspend for any reason Cannot call wait() directly or indirectly SC_MODULE ( dff ) { // Declarations sc_out <bool> q; sc_in <bool> c,d,r; void dff_method() { q = r ? 0 : d ; } // Constructor SC_CTOR ( dff ) { // Process registration SC_METHOD(dff_method); sensitive << c.pos(); dont_initialize(); } } ;

The Thread Process Use the expressive power of thread process to model system or testbench behavior. Register a thread process with the SC_THREAD macro Maintains local state and context Can block and consume time Incurs context switching overhead during execution Normally first executes during the initialization phase If dont_initialize() then first executes when first triggered Can suspend for any reason Can call wait() directly or indirectly Thereafter (when triggered) executes from statement after suspension to next suspension SC_MODULE ( dff ) { // Declarations sc_out <bool> q; sc_in <bool> c,d,r; void dff_thread() { q = 0; wait(); while (true) { q = d ; wait(); } } // Constructor SC_CTOR ( dff ) { // Process registration SC_THREAD(dff_thread); sensitive << c.pos(); dont_initialize(); }} ;

The Clocked Thread Process Use the clocked thread process to behaviorally model clocked hardware Constrained version of a thread Register a clocked thread process with the SC_CTHREAD macro. Sensitive to a single event Second macro argument Does not initialize First executes when triggered Implies dont_initialize() SC_MODULE ( dff ) { // Declarations sc_out <bool> q; sc_in <bool> c,d,r; void dff_cthread() { q = 0; wait(); while (true) { q = d ; wait(); } } // Constructor SC_CTOR ( dff ) { // Process registration SC_CTHREAD(dff_cthread,c.pos()); } } ;

Dynamically Spawning a Process You can also dynamically spawn method and thread processes (but not clocked thread processes) during elaboration and even simulation! Advantages include: Can spawn any arbitrary function signature with parameters and return values The basic steps are: Insert #define SC_INCLUDE_DYNAMIC_PROCESSES Before you insert: #include "systemc.h" Optionally create an sc_spawn_options object to customize the process By default spawns and initializes a thread process with no static sensitivity Call sc_spawn() Returns an sc_process_handle to the new process instance For static processes, after registering with macro, use sc_get_current_process_handle() to obtain sc_process_handle

Using sc_spawn() The sc_spawn() method has one required and three optional arguments: Process return value (if any) Process function pointer or object (required) Process name (optional for thread process) Pointer to sc_spawn_options (optional for thread process) sc_process_handle h1, h2, h3; // spawn as thread “void func1()” h1 = sc_spawn(sc_bind(&func1)); // spawn as thread “bool mod::func2(int&)” int i; bool ret; h2 = sc_spawn(&ret, sc_bind(&mod::func2, this, sc_ref(i))); wait(h2.terminated_event()); // spawn as method named ‘my_method’ “void func3()” sc_spawn_options opt; opt.spawn_method(); opt.dont_initialize(); opt.set_sensitivity(&ev); ev is an sc_event h3 = sc_spawn(sc_bind(&func3), “my_method”, &opt); #define sc_bind boost::bind #define sc_ref(r) boost::ref(r) #define sc_cref(r) boost::cref(r)

Process Control Constructs New member methods in sc_process_handle class suspend() and resume() disable() and enable() kill() reset() – asynchronous reset sync_reset_on(), sync_reset_off() – synchronous reset throw_it() – throwing a C++ exception in a process

Suspending and Resuming a Process proc_handle.suspend() suspends process does not run again until process is resumed {new effective sensitivity} = {old effective sensitivity} && resume_event remembers effective sensitivity triggering while suspended proc_handle.resume() lifts any previous suspensions notifies resume_event has no effect if process was not suspended If effective sensitivity triggered while process was suspended, resume() will execute process 10 20 30 Clock Proc Execution Time suspend resume

Disabling and Enabling a Process suspend resume 10 20 30 Time Clock Proc Execution proc_handle.disable() disables process does not run again till process is enabled {new effective sensitivity} = NULL does not remember effective sensitivity triggering while disabled proc_handle.enable() lifts any previous disables has no effect if process was not disabled restores {old effective sensitivity} If effective sensitivity triggered while process was disabled, enable() will NOT execute process disable enable Proc Execution

Killing and Resetting a Process (Asynchronous) void run() { // init state ….. wait(); // steady state { ….. wait(); …. } } // run proc_handle.kill() terminates a process immediate, asynchronous effect an exception is thrown in the target process that unwinds its stack and exits its function control returns to the initiator process proc_handle.reset() resets a process same effect as kill in addition resets sensitivity to time 0 state => static sensitivity a thread process is re-run from the beginning until it waits or returns kill

Resetting a Thread Process (Synchronous) Timing is distinct from asynchronous reset no immediate effect proc_handle.sync_reset_on() sets process to be in reset_state such that every time its effective sensitivity triggers, process is reset proc_handle.sync_reset_off() sets process state back to normal More commonly used through the (async_)reset_signal_is() API for processes Specify a boolean port/channel as the reset signal and an edge as the reset value When any reset signal attains the reset value, process is put in reset_state; for async case, an immediate reset also happens When ALL reset signal attains non-reset value, process is taken out of reset_state

Throwing a C++ Exception in a Process template <typename T> sc_process_handle:: throw_it(const T& excp) immediate/asynchronous effect throws user-defined exception excp in target process stack target process catches the exception and waits or returns control returns to the initiator process

The Simulation Delta Cycle Given : Multiple independent but intercommunicating processes each simulate a small portion of the system behavior. Problem The system executes the processes concurrently, but the simulator executes the processes in a non-deterministic order that can clobber the intercommunication. Solution At each simulation “cycle” withhold process outputs until all processes again attain a “resting” state. Implementation Delta cycles have separate evaluate and update phases: Evaluate – Execute each “runnable” process to its next resting state Update Make available those outputs that processes deferred update cycle count evaluate

The sc_main() Function The sc_main() method is your entry point into the simulation flow: Instantiate the design top level unit(s) Can instantiate one complete top-level wrapper module Inside top level module, instantiate other child modules, instantiate channels, and bind child module ports to channels Call sc_start() to start simulation Return the simulation status #include "systemc.h" #include "top.h" int sc_main(int argc, char *argv[]) { top top_inst("top_inst"); sc_start(); return 0; }

The SystemC Event Scheduler Simulation consists of an initialization followed by a series of delta cycles Note that elaboration (constructor initialization) is already done, so upon sc_start() the simulator follows up any effects from that and then makes most processes ready to run Only the first sc_start() runs a simulation initialization phase Thereafter the simulator runs delta cycles, which consist of evaluate and update phases Following pages further explain these phases... initialize phase delta cycles constructor initialization evaluate sc_start() update phase update advance delta cnt pending delta-delay notify? make most processes runnable y delta notify pending time-delay notify? y advance sim time stop

Simulation Initialization The first sc_start() call initializes the simulation. The simulator: Runs an update phase to complete deferred assignments executed during elaboration Makes runnable any method and thread processes for which dont_initialize() has not been called Runs a delta notification phase to make runnable any additional processes sensitive to events notified in the update phase constructor initialization sc_start() update phase 1 make most procs runnable 2 3 delta notify evaluate phase

Delta Cycles: Evaluate and Update Phases The generic delta cycle algorithm is: Evaluate – Execute each runnable process to the point of suspension or termination Update – Call back primitive channels that requested update Delta notification – Make runnable any processes suspended in wait for delta-delay events (when none go to 4) Timed notification – Make runnable any processes suspended in wait for time-delay events Simulation stops when no pending events exist. initialize 1 evaluate 2 update advance delta cnt pending delta-delay notify? 3 y pending time-delay notify? 4 y advance sim time stop

Stopping the Simulation Use sc_stop() to stop the simulation Call from anywhere Stops the simulation Returns to sc_main() from any sc_start() call Cannot continue! sc_stop();

Pausing the Simulation Use sc_pause() to pause the simulation New in p1666-2011 Call from anywhere Pauses the simulation after completing current delta cycle Returns to sc_main() from any sc_start() call Simulation can be resumed again with a call to sc_start()

Additional Resources Standard SystemC Language Reference Manual IEEE Std. 1666-2011 http://www.ieee.org Accellera Systems Initiative http://www.accellera.org Technical Papers (Application Notes, Documentation, Tips), News, Events, Products & Solutions (Books, Consulting, Training), Discussion, FAQs SystemC Publications Jayram Bhasker. "A SystemC Primer". Star Galaxy Publishing, 2004. David Black, (et al.). "SystemC: From The Ground Up". Springer, 2010. Thorsten Grötker, (et al.). "System Design with SystemC". Springer, 2002. Frank Ghenassia, (Ed.). “Transaction-Level Modeling with SystemC”. Springer, 2005. W. Müller; W. Rosenstiel; J. Ruf (Eds.). "SystemC Methodologies and Applications". Springer, 2003.

Questions?