1. SYSTEMC

2. Design Challenge I: Hardware/Software Co-design
In complex systems, software developers must often wait for the hardware design to be finalized before they can begin detailed coding.
Software developers must also wait for devices (ICs and printed circuit boards) to be manufactured to test their code in a realistic environment.
This dependency creates a long critical path that may add so much financial risk to a project that it is never started.

3. Design Challenge II: Hardware Implementation
A system engineer writes a C or C++ model of the system to verify the concepts and algorithms at the system level.
The parts of the C/C++ model to be implemented in hardware are manually converted to a VHDL or Verilog description for actual hardware implementation.

4. Problems with the Current Methodology
Manual Conversion from C to HDL Creates Errors
The designer:
creates the C model,
verifies that the C model works as expected, and
translates the design manually into an HDL.
This is very tedious and error prone.
Disconnect Between System Model and HDL Model
After conversion, the HDL model becomes the focus of development. The C model quickly becomes out of date as changes are made.
Typically changes are made only to the HDL model and not implemented in the C model.
Multiple System Tests
Tests that are created to validate the C model functionality typically cannot be run against the HDL model without conversion.
Not only does the designer have to convert the C model to HDL, but the test suite has to be converted to the HDL environment as well.

5. Concurrency support is missing (HW is inherently parallel)
Why not just C++?
Concurrency support is missing (HW is inherently parallel)
No notion of time (clock, delays)
Communication model is very different from actual HW model (signals)
Weak/complex reactivity to events
Missing data types (logic values, bit vectors, fixed point math)
PLAIN VANILLA C++ IS NOT USABLE!

6. Objectives: Challenge: SystemC Objectives
Model HW with SW programming language
Achieve fast simulation
Provide support for
Hardware modeling
Hardware/software system design
Challenge:
Give hardware semantics to software models!

7. Object-oriented style
SystemC
C++ extensions
C++ class library (libsystemc.a), which also delivers a modeling methodology
HW semantics defined through the class library
SystemC code is C++ code and can be freely mixed with C++ code
Object-oriented style
Basic component models (reusable!)
Inheritance, polymorphism, templates,...
Usually translated into traditional HDLs for hardware synthesis

8. SystemC Infrastructure

9. What is SystemC
SystemC is a C++ class library and a methodology that you can use to effectively create a model of
software algorithms,
hardware architecture, and
system-level designs.
The SystemC Class Library has been developed by a group of companies forming the Open SystemC Initiative (OSCI): semiconductor + EDA companies
Since 2011, merging with “Accellera” standards organization into the “Accellera Systems Initiative”
You can use SystemC and standard C++ development tools to
create a system-level model,
quickly simulate to validate and optimize the design,
provide the hardware and software development teams with an executable specification of the system.
An executable specification is essentially a C++ program that exhibits the same behavior as the system when executed.

10. Benefits of Executable Specification
Avoids inconsistency and errors and helps ensure completeness of the specification.
because you are essentially creating a program that behaves the same way as the system.
Ensures unambiguous interpretation
Whenever implementers are in doubt about the design, they can run the executable specification to determine what the system is supposed to be doing.
Helps validate system functionality before implementation begins.
Helps create early performance models of the system and validate system performance.
Its testbench can be refined (or used as is) to test the implementation of the specification.
This can provide tremendous benefits to implementers and drastically reduce the time for implementation verification.

11. SystemC highlights
Supports hardware and software co-design
Developing an executable specification avoids inconsistency and errors
Avoids wrong interpretation of the specification
SystemC has a rich set of data types for you to model your systems
It allows multiple abstraction levels, from high level design down to cycle-accurate RTL level

12. SystemC and the Hardware/software co-design challenge
UNTIMED TLM
HARDWARE
DEVELOPMENT
TIMED TLM
RTL
RECIPROCAL IMPROVEMENT
RECIPROCAL IMPROVEMENT
SOFTWARE
DEVELOPMENT
FUNCTIONAL
SOFTWARE
HW/SW
CODESIGN
REAL-TIME
SOFTWARE
SOFTWARE
VALIDATION

13. Hardware Software Co-design
Bebefits of using SystemC:
Ability to start refining and testing software earlier, thereby reducing the overall development cycle.
Ability to provide earlier and more realistic hardware/software trade off studies at a time when changes are easier, thus improving overall system quality.
Ability to deliver executable models to customers both for validating the specification and driving changes, and acceleration of product adoption.
Ability to cancel (or redefine) an unrealistic project before spending even larger sums of money

14. SystemC and the Hardware Implementation Challenge
Refinement Methodology:
The design is not converted from a C level description to an HDL in one large effort.
The design is slowly refined in small sections to add the necessary hardware and timing constructs to produce a good design.
Using this refinement methodology, the designer can more easily implement design changes and detect bugs during refinement.

15. SystemC and the Hardware Implementation Challenge
Written in a Single Language
the designer does not have to be an expert in multiple languages.
SystemC allows modeling from the system level to RTL.
Higher Productivity
because the designer can model at a higher level.
 smaller code, that is easier to write and
 simulates faster than traditional modeling environments
Testbenches can be reused from the system level model to the RTL model
Saving conversion time.
gives the designer a higher confidence that the system level and the RTL model implement the same functionality.

16. SystemC Synthesis
SystemC is not “born” to be a language for HW implementation (like Verilog & VHDL)
Basic idea: define synthesizable SystemC subset
Make it another refinement step
Commercial translation tools are available
From TLM to RTL
From RTL to Verilog/VHDL
[Celoxica 2005]

17. SystemC contrasted with other design languages
matlab
Vera e Sugar Jeda
SystemVerilog
VHDL
Verilog
Fermati qua.
VHDL ha un buco nella functional verification?
Due aspetti:
Testbench
Assertion
Il verilog e vhdl è debole nelle assertion. Non sono ricche
E potenti come le assertion in system verilog. Puoi scrivere dei
Programmi che controllano sequenziamento di transazioni
E segnali.
Vera è un linguaggio solo per la verifica. SI aggiungono a Verilog e VHDL
Per specificare testbench e asserzioni.
Matlab inteso come simulink e state-flow: specifica di blocchi.

18. Levels of Abstraction
Raising LOA is necessary for managing complexity.

19. Open Community Licensing
How to get SystemC ?
V.2.3.0

20. SystemC - contd

21. Language Architecture
C++ Language Standard
Core Language
Module
Ports
Processes
Events
Interfaces
Channels
Event-driven simulation kernel
Data types
Bits and bit-vectors
Arbitrary precision integers
Fixed-point numbers
4-valued logic types, logic-vectors
C++ user defined types
Elementary Channels
Signal, Timer, Mutex, Semaphore, FIFO, etc
Channels for MoCs
Kahn process networks, SDF, etc
Methodology-specific Channels
Master/Slave library

22. No Syntax Extensions
SystemC is able to model HW components without extending C++ language syntax

23. Typical Programming Model
A set of modules interacting through communication channels
Module
I/O Ports
Communication channels
(e.g., signals)
Design
May be connected to other designs or to a testbench

24. Ports (sc_in<>, sc_out<>, sc_inout<>)
Modules
Modules (sc_module)
Fundamental structural entity
Map functionality of HW/SW blocks
Contain processes (functionality)
Contain other modules (creating hierarchy)
Communicate through ports/IF/channels
Ports (sc_in<>, sc_out<>, sc_inout<>)
Modules in turn have ports
Ports have types
Port types are template parameters

25. Module Structure PROCESS MODULE Channel (implements an IF)
Port (accesses a channel’s IF)
MODULE
PROCESS
Interface
Algorithm (reads data from input ports and writes data to output ports)
Can be made sensitive to input ports or to other signals (e.g., clock)

26. Modules in SystemC
Actually, a C++ class definition!

27. Typical Programming Model
Some modules can be hierarchical….
Module
Design
Module
Design
..that is, they contain yet another structural view, not a functional one

28. Processes Processes Functionality is described in a process
Implemented as member functions
Processes run concurrently
Code inside a process executes sequentially
SystemC has three different types of processes
SC_METHOD
SC_THREAD
SC_CTHREAD
Macros telling the scheduler (i.e., the simulation engine) how to handle such processes

29. Processes Sensitivity list:
List of ports that a process is sensitive to
Processes registered with “SystemC Simulation Kernel” at run-time
Name of the process + its sensitivity list
Place & time: at module instantiation time (when the module constructor is called)
Processes called by “SystemC Simulation Kernel”
whenever one of the ports in the “sensitivity list” changes value
Executes sequentially until return() or wait(), depending on whether it is a method or a thread

30. Process Type SC_METHOD: method process SC_THREAD: thread process
Sensitive to a set of signals
Cannot be suspended: executed till completion
Does not remember internal state across invocations
Used for combinational logic
SC_THREAD: thread process
Can be suspended: executed until a wait(), resumed through sensitivity list
Remembers internal state across invocations
Heavier load on the scheduler, larger memory footprint
Use for combinational logic (same as methods), but mainly for testbenches
SC_CTHREAD: clocked thread process
Sensitive only to one edge of a clock signal
Execute until a wait_until() (note the enhanced wait semantics)
Watching(reset) restarts from top of process body (reset evaluated on target ck edge)
Often the only synthesizable subset of SystemC

31. Create and initialize “Internal Data Structures” of the module
Module Constructor
Registers module Processes, and their sensitivity list with “SystemC Kernel”
Create and initialize “Internal Data Structures” of the module
Initialize Internal Data Storage
An “instance name” is passed to the constructor at instantiation time
Each instantiated module (even from the same SC_MODULE type) can have its own name
Helps in reporting debug, error, and information messages from the module

32. Port declaration
my_module ID
IN_A
IN_B
OUT_C

33. SC_METHOD The process is a method of the my_module class
Process registered as a method with the simulation kernel...
sensitive << in_a << in_b;
..and made sensitive to specified INPUT ports
Should not save state between invocations
Runs to completion: should not contain infinite loops
Not preempted

34. SC_THREAD Simple threads can be easily translated into methods.
As long as there is no delay or dynamic event requiring a wait(),
sc_method makes a significant enhancement in simulation speed
State saved between invocations
Infinite loops should contain a wait()

35. Supported wait constructs since SystemC 2.2:
SC_CTHREAD
Watching construct
unsupported since SystemC 2.2 (included). Rather, use function “reset_signal_is(in_port, level)”
Supported wait constructs since SystemC 2.2:
wait();
Wait(int n);

36. Ports, Interfaces, Channels
Communication Semantics
Ports, Interfaces, Channels
Module
Channel
Module
Port
Interface
PORT: module’s gateway to the external world
INTERFACE: abstract class defining the pure virtual functions the module can use to access the communication channel through its gateway
CHANNEL: inherits the interface abstract class and defines the implementation of the pure virtual functions in the interface

37. Communication Semantics
Interface Method Calls (IMC)
Process calls an interface method of a channel
The collection of a fixed set of communication methods is called an Interface (abstract class)
More than one channel is feasible for the same interface
Modules can be connected via their Ports to those channels
class IF {
public:
virtual void write (bool) = 0; };
class channel_A: public IF {
void write (bool) {
//defines write() with respect to
// channel_A }
Module
Process
Out_port.write(1);
sc_out<bool>
Out_port;

38. Channel Binding my_if<> my_if<>
Module
Channel
Module
Plug-'n'-Play
my_if<>
my_if<>
Channel
sc_port< my_if<> >
sc_port< my_if<> >
The association of a specific channel (out of many possible ones) to a given interface is done during the BINDING phase

39. Signal Examples sc_signal<sc_uint<8> > my_signal1;
from sc_main or from top-level SC_MODULE:
sc_signal<sc_uint<8> > my_signal1;
sc_signal<bool> my_signal2;
sc_clock my_clock(“my_clock", 20, 0.5, 2, true);
my_module_1.clock_port(my_clock);
my_module_1.out_port(my_signal1);
my_module_1.in_port(my_signal2);
my_module_2.clock_port(my_clock);
my_module_2.out_port(my_signal2);
my_module_2.in_port(my_signal1);
my_module1
my_clock
my_signal1
my_signal2
my_module2
BINDING: associating a port/IF with a corresponding channel

40. They provide well-defined boundaries through which modules interact
Ports
They provide well-defined boundaries through which modules interact
SystemC template class to create ports
template <class IF, int N = 1>
class sc_port:…
Template parameters:
type of interface
number of connected interfaces
They connect to channels by means of interfaces, specified through a template parameter
Typical channel (in RTL modules): sc_signal

41. SystemC provides a template class for creating ports
template<class IF, int N=1>
class sc_port : //class derivation details omitted {
public:
IF* operator->();
// other member functions and member variables }
“IF” denotes the interface class
Operator “->” overload returns a pointer to the IF class
This trick makes interface methods available to the module’s processes

42. Specialized signal ports are provided by SystemC
Any interface method can be invoked through the port
read() and write() below are interface method calls, which are implemented by sc_signal channel
sc_port<sc_signal_inout_if<int> > p;
……………..
x=p->read();
p->write(y)
Specialized signal ports are provided by SystemC
template<class T>
class sc_in : public sc_port<sc_signal_in_if<T> > ..;
class sc_out : public sc_port<sc_signal_inout_if<T> > ..;

43. Implementing an Interface
An interface does not actually do anything
It just has to declare prototypes for the channel methods
It has to mandatorily inherit predefined “sc_interface” class
class my_read_if : virtual public sc_interface {
public:
virtual char read() = 0; };
Written this way, a module
will only be able to connect
to one of the interfaces –
either for read or for write!
class my_write_if : virtual public sc_interface {
public:
virtual void write(char) = 0; };

44. Implementing an Interface
To be able to implement a read/write connection to the channel, we need a derived interface:
class my_readwrite_if :
public my_read_if,
public my_write_if { };
Now both read() and write() will be available to a module port connected to my_readwrite_if
Interestingly, the channel does not carry any direction information. The direction is given by the port.

45. Interfaces for sc_signal channel
HW signal interfaces:
sc_signal_in_if<T>
Contains virtual function read()
read() returns a constant reference to T such that value may be read
sc_signal_inout_if<T>
Derived from sc_signal_in_if<T>
Contains virtual function write()
Write() takes as input a constant reference to T

46. Channels
Port and Interface describe the functions available in the communication package
Channel defines the implementation of the communication functions
Channel is derived from the interface
More than one Channel might implement the same interface in different ways
A Channel might implement more than one interface

47. Channels Primitive Hierarchical Channels can be
primitive (supporting “Evaluate then update” semantics)
hierarchical (may include modules, processes, ports, subchannels)
Code to be implemented:
The channel itself
The interface

48. Implementing a Channel
The channel must provide the implementation of the methods declared in its interfaces
The channel inherits sc_prim_channel and thus can access its APIs, especially:
void request_update()
virtual void update() = 0 (requires an implementation inside of the channel!)
The channel also inherits sc_interface (through its interfaces) and thus can access its API, especially:
virtual const sc_event& default_event() (tells the simulation kernel which is the event on which to enqueue processes waiting on their sensitivity list)

49. Request-Update Semantics
The channel must comply with the “Evaluate then update” paradigm of SystemC! To do so:
When some channel method is invoked (typically writes), the channel calls the simulation kernel via sc_prim_channel’s request_update()//for VHDL-like simulation
The simulation kernel schedules the channel for update in the update phase of the current Delta cycle. When such virtual time arrives, the kernel calls the channel’s update() method
update() is still inherited by sc_prim_channel, but its implementation is channel-specific

50. Implementing a Channel
class my_channel :
public sc_prim_channel, public my_read_if, public my_write_if {
public:
[…]
virtual char read() { return curr_val };
virtual void write(char val) { next_val = val;
if (next_val != curr_val) request_update(); }
virtual const sc_event& default_event() const
{ return val_chg_event; } //called by S.kern. At the beginn.
………
virtual void update() { curr_val = next_val;
val_chg_event.notify(SC_ZERO_TIME); }
char curr_val, next_val;
sc_event val_chg_event; };
“Evaluate then update” semantics
Sensitivity support
One Delta cycle

51. Instantiating a Channel
// my_module.h
SC_MODULE (my_module) {
sc_port <my_read_if> in;
void my_function();
SC_CTOR(my_module)
SC_METHOD(my_function);
sensitive << in; } };
// my_module.cpp
void my_module::my_function() {
printf(“%c\n”, in.read()); };
//main.cpp
My_channel CH;
My_module MYMOD;
MYMOD.in(CH); //binding

52. sc_signal template <class T> class sc_signal
:public sc_signal_inout_if<T>,
public sc_prim_channel {
public:
//get the default event
virtual const sc_event& default_event() const
{ return m_value_changed_event;}
virtual const sc_event& value_changed_event() const
virtual const T& read() const
{ return m_cur_val;}
virtual void write(const T& value_)
m_new_value = value_;
if ( ! (m_new_val == m_cur_val)) request_update(); }

53. sc_signal protected: //get the default event virtual void update() {
if ( ! (m_new_val == m_cur_value)) {
m_cur_value = m_new_value;
m_value_changed_event.notify(SC_ZERO_TIME); }
T m_cur_valu;
T m_new_val;
sc_event m_value_changed_event; };