Transaction Level Modeling with SystemC for System Level Design

1. Transaction Level Modeling with SystemC for System Level Design

2. Organization of the Tutorial

3. Module 1 - Introduction Module 2 - Terminology Module 3 - Event and Process Module 4 - Simulator Module 5 - Example of SystemC Model Outline(Part-I: SystemC)

4. Inadequacy of C/C++ for System Level Design SystemC for System Level Design Module 1 - Introduction

5. Motivation to for introducing a new Modeling Language ? Why was it insufficient to keep using familiar HDLs ? BW is a major Issue now 4 GB/s required for a typical Digital TV SOC IP 4 BW was not an issue IP1 IP 5 MEMORY IP 6 IP 7 IP2 Available b/w < 4GB/s due to parallel multiple accesses There is a limit on the available BW IP 8 IP 9 IP 10 IC’s now IP3 IC’s during 80-90’s

6. Motivation to for introducing a new Modeling Language ? Why was it insufficient to keep using familiar HDLs ? How does a system-on-chip like today? Memory Processor with Embedded SW Interconnect Bus Peripherals

7. Solutions & Limitations • Spreadsheet analysis • Low accuracy when traffic from different IP’s get mixed • High level C/C++ models • Not available for complex SOC. • Low accuracy • Not effective correlation with post-silicon results • RTL Simulation with HDL- VHDL, Verilog • Stable SOC RTL available very late. • Very Slow though accurate • Emulation platforms • Faster than RTL simulations but results are very late in SOC cycle • RTL changes are very difficult without major impact on schedule

8. System Level DesignInadequacy of C/C++ for System Level Design

9. Traditional C++ Based System Design Flow Advantages • OOPS • Existing Infrastructure Disadvantages • No Notion of Simulation Time • No Concurrency Support • No Availability of Hardware Data Types • Manual Conversions creates errors • Disconnect between System Model & HDL Model

10. Modern System Design Flow

11. Modeling Abstractions at System Level • Register Transfer Accurate • Bus Cycle Accurate • Performance Modeling • DUT Verification • Transaction Level Accurate • Embedded S/w Development • Golden Reference Models

12. Transaction Level Accuracy (TLM) • TLM- Untimed (Programmers View- PV ) • Refers to both Interface & Functionality • Transport data in zero time • Process execute in zero time but in sequence • Abstract Communication Channels/ Interfaces • Functional calls (i.e read(addr), write(addr, data)) • TLM- Timed (Approximately or Loosely Timed) • Timed but not clocked • May refer to one or both Interface & Functionality • Transport data may be assigned latency • Processes may be assigned an execution time • Abstract Communication Channels/ Interfaces • Functional Calls but latency modelled

13. Cycle Accuracy (CA) • Bus Cycle Accurate • Communication protocol may be clocked • Communication Latency modelled • Functionality may/not be timed • Register Transfer Accurate • Synchronous transfer between the functional units • Fully timed/ Clocked • Bit/ Register/ BUS Cycle Accurate • May be synthesizable

14. Modeling Accuracy Requirement at System Level • Modeling at Different Abstraction Level • RTL, BCA, TLM • Structural Accuracy • Design Partitioning/ Modules/ Abstract Data Type • Timing Accuracy • Physical Time & Simulation Time/ Timed/ Clocked • Functional Accuracy • Timed/ Untimed/ Event Based/ Clock Based • Data Organization Accuracy • Registers/ Hardware Data • Communication Protocol Accuracy • Clocked/ Timed/ Signal Level Interface/ Functional Interface

15. System Level Languages

16. Abstraction Level Coverage of Various HDLs

17. HDL- Comparison

18. SystemC for System Level Design

19. Reasons for Adopting SystemC • Single language for modeling hardware/software systems: • Communication channels, events • Concurrency process • Timing clock, sc_time • Data types sc_logic • Object-oriented approach, design re-usability • Hardware primitives along with simulation kernel • Multiple abstraction levels

20. Reasons for Adopting SystemC

21. Brief History & Major Releases • Confluence of 4 different streams of Ideas/ Efforts- • Synopsys & Univ. of California/ Infineon: Cycle based approach deploying C++ • Frontier Design: Data Types • IMEC/ CoWare: Hw/Sw Co-design • OSCI: System Level Design concepts • SystemC 1.0: Production release on September 27th 1999 • RTL-like concepts • SystemC 2.0: Production release on October 18th 2001 • System Level Modeling and Verification • SystemC 2.1: IEEE 1666-2005 • SystemC 2.3.1: IEEE 1666.1–2016 standard for SystemC AMS • Strong Process Control

22. Module 2- SystemC Terminology

23. SystemC is: Module, Process, Ports, Channel, Interface class my_channel: if_w, if_r, sc_module { void write( ) {...} void read ( ) {…} }; Producer Module Consumer Module sc_port<if_r> p2; sc_port<if_w> p1; p1->write( ) p2->read( ) P1 my_channel P2 class if_r: virtual sc_interface { virtual void read() = 0; }; class if_w: virtual sc_interface { virtual void write() = 0; };

24. Data Type

25. SystemC Data Types • All C++ data types • sc_logic - 0, 1, X, Z • sc_lv<length> - array of sc_logic • sc_uint<length> , sc_biguint<length>, sc_bv<length> • sc_fix

26. Data Type • Use native C++ data types wherever possible • Use sc_logic if 4-valued logic is required • Use sc_uint<length> for less than 64-bits and 2-valued logic • Use sc_biguint<length> for more than 64-bits and 2-valued logic • Use sc_fix for fixed point arithmetic

27. Interface class my_channel: if_w, if_r, sc_module { void write( ) {...} void read( ) {…} }; Producer Module Consumer Module sc_port<if_r> p2; sc_port<if_w> p1; p1->write( ) p2->read( ) P1 my_channel P2 classif_r: virtual sc_interface { virtual void read() = 0; }; classif_w: virtual sc_interface { virtual void write() = 0; };

28. SystemC Interface • Declares a set of access methods needed for communication between IPs • Do not provide any implementation of the access methods • Implementation of interfaces are done within a channel • sc_signal_in_if –> T& read() const interface • sc_signal_inout_if –> void write(const T&) interface • You can define your own interfaces but it should inherit from sc_interface class template <typename T> class my_interface: public sc_interface { int read(int & addr) = 0; void write( int& addr, int & data) = 0; }

29. Interface examples // ------------------------------------------ // sc_signal_inout_if // this interface provides ‘read’ & ‘write’ method // ------------------------------------------ template <class T> Class sc_signal_inout_if : virtual public sc_signal_in_if { public: // interface methods virtual void write( const T& ) = 0; }; // ----------------------------------------- // sc_signal_in_if // this interface provides a ‘read’ method // ----------------------------------------- template <class T> class sc_signal_in_if : virtual public sc_interface { public: // interface methods virtual const T& read() const = 0; };

30. Difference Interface Type for Different Abstraction Level • Cycle Accurate Model • Interfaces in form of signals of request, grant, address, data, etc • Transaction Level Model • Interfaces in the form of read (address) or write (address, data)

31. Channel class my_channel: if_w, if_r, sc_module{ void write( ) {...} void read( ) {…} }; Producer Module Consumer Module sc_port<if_r> p2; sc_port<if_w> p1; p1->write( ) p2->read( ) P1 my_channel P2 class if_r: virtual sc_interface { virtual void read() = 0; }; class if_w: virtual sc_interface { virtual void write() = 0; };

32. SystemC Channel? sc_interface • Means for communication between modules • Provides the functionality of methods declared in interface • Derived from interfaces my_interface (sc_signal_inout_if) • template <typename T> • class my_channel: my_interface, sc_module { • int read(int& addr) { • return arr[add]; • } • void write(int & addr, int & data) { • arr[addr]= data; • } • } my_channel (sc_signal)

33. Channel Example (1/2) // ---------------------------------- // sc_signal<T> // ---------------------------------- template <class T> class sc_signal : public sc_signal_inout_if<T> { m_value; T& read () { //immediate return return m_value; } }

34. Channel Example (1/2) // ---------------------------------- // sc_signal<T> // ---------------------------------- template <class T> class sc_signal : public sc_signal_inout_if<T> { m_value; T& read () { //return after some time wait (10, SC_NS); return m_value; } }

35. Channel Module1 SystemC Port • T& read() { • return m_value; • } write( T& value ) { m_value = value; } port1->write(value ) Value = port2->read() Module2 Input Port Output Port

36. SystemC Port • Created from the base class sc_port and are bound to an interface type • Syntax sc_port<interface_type, N> port_name; N is the number of channels connected to the port • To access a channel method through an sc_port object, use -> operator sc_port<sc_signal_in_if<int>, 2> my_read_port; sc_port<sc_signal_out_if<int>, 2> my_write_port; int data = my_read_port->read(addr); my_write_port->write(addr, data);

37. SystemC Ports • // SystemC • sc_in<signaltype> port1; • sc_out<signaltype> port2 ; • sc_inout<signaltype> port3; // Verilog inputwire port1; outputwire port2; inoutwire port3; • Example • sc_in<sc_logic> a[32]; //input ports a[0] to a[31] of type sc_logic

38. my_channel sc_interface sc_port Specify communication services (pure virtual methods) my_interface my_port<my_interface> Implement communication services Now, altogether… • Interface defines (but does not implement) a set of access methods • Channel implements the methods of one or more interfaces • Port is bound to Channel through the Interface

39. Module // Verilog module module_name(); - - - - - endmodule // SystemCSC_MODULE(module_name){ - - - - - - }

40. SystemC Module • Basic building block to partition a complex design into smaller components • Module is a C++ class.

41. Ports Module Channel Process Connecting Module to Channel Interface Binding SPG systemc_tr1.0

42. SC_MODULE(filter) { • //Sub-modules : “components” • sample *s1; • coeff *c1; • mult *m1; • // Signals • sc_signal<sc_uint 32> > q, s, c; • //Constructor : “architecture” • SC_CTOR(filter) { • //Sub-modules instantiation and mapping • s1 = new sample (“s1”); • s1->din(q); //named mapping • s1->dout(s); • c1 = new coeff(“c1”); • c1->out(c); • m1 = new mult (“m1”); • (*m1)(s, c, q); //Positional mapping • } • } Modules

43. Event Process Event and Process

44. Event

45. SystemC Event • Basic synchronization object • Events • are used to synchronize processes • are declared in a module • Syntax sc_event event_name1, event_name2, ... ;

46. Event Notification • To trigger an event, call notify()method • Notification of an event could be immediate or delayed event_name.notify(); event_name.notify(SC_ZERO_TIME); event_name.notify(1, SC_NS);

47. Process // SystemCSC_METHOD(blk); sensitive <<clk; void blk(){...} // Verilogalways @(clk) begin : blk ... end

48. SystemC Process • Module can have a number of Processes to describe its functionality • functions identified by the SystemC kernel • invoked by the kernel based on its static or dynamic sensitivity list • cannot be called directly !!! • Two different types of processes: • Threads: SC_THREAD • Methods: SC_METHOD module module process process P P channel P P p_in p_out p_in p_out

49. Declaration of a Thread • One (or more) thread process(es) may be declared C++ member function in a module void process_name(void); • Registered in the SystemC kernel within the module’s constructor: SC_THREAD(process_name); • Thread process: • is implemented in an infinite loop • runs only when started by the SystemC scheduler • can be invoked based upon Static or Dynamic sensitivity ist

50. Sensitivity List • Static Sensitivity List • Expressed in Module constructor • Events such as sc_signal or sc_event that the process is sensitive to void compute(void); SC_THREAD(compute); sensitive << irq1<<irq2; //in the constructor of a module • Dynamic Sensitivity List wait(irq);//no explicit declaration in the constructor