Transaction Level Modeling with SystemC

for System Level Design

Organization of the Tutorial

2
 Outline
(Part-I: SystemC)

 Module 1 - Introduction
 Module 2 - Terminology
 Module 3 - Event and Process
 Module 4 - Simulator
 Module 5 - Example of SystemC Model

3
Module 1 - Introduction

 Inadequacy of C/C++ for System Level Design

 SystemC for System Level Design

4
Motivation to for introducing a new Modeling Language ?
Why was it insufficient to keep using familiar HDLs ?
BW is a major
4 GB/s required for a typical
Digital TVIPSOC
4 Issue now
IP1 BW was not an
issue
IP 5
IP 6

IP 7
AvailableIP2
b/w < 4GB/s due to
parallel multiple accesses There is a limit on
IP 8 IP 9 the available BW

IP 10
IC’s now
IP3
IC’s during 80-90’s
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

6
 Solutions & Limitations
1. Spreadsheet analysis
 Low accuracy when traffic from different IP’s get mixed

2. High level C/C++ models

 Not available for complex SOC.
 Low accuracy
 Not effective correlation with post-silicon results

3. RTL Simulation with HDL- VHDL, Verilog

 Stable SOC RTL available very late.
 Very Slow though accurate

4. Emulation platforms
 Faster than RTL simulations but results are very late in SOC cycle
 RTL changes are very difficult without major impact on schedule
 System Level Design
Inadequacy of C/C++ for System Level Design

8
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 9
Modern System Design Flow

10
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

11
 Transaction Level Accuracy (TLM)
 TLM- Untimed (Programmers View- PV )
– Refers to both Interface & Functionality
o Transport data in zero time
o Process execute in zero time but in sequence
– Abstract Communication Channels/ Interfaces
o 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
o Transport data may be assigned latency
o Processes may be assigned an execution time
– Abstract Communication Channels/ Interfaces
o Functional Calls but latency modelled 12
 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

13
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

14
System Level Languages

15
Abstraction Level Coverage of Various HDLs

16
 HDL- Comparison
VHDL Verilog SystemC SystemVerilog
IEEE 1987 1995 2005 2005
Standardization
Base Language ADA/ Pascal C C++ Verilog/ C++
Type Checking Strong Weak Strong Medium
Design re-usability Medium Low Very High High
Ease of Learning Difficult Medium Easy Very Difficult
High Level High Low High High
Construct Support
Low Level Medium High Low High
Construct Support
Synthesizability High High Low High
Adoption Very High Very High Medium High17
SystemC for System Level Design

18
 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

19
Reasons for Adopting SystemC

20
 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

21
Module 2- SystemC Terminology

22
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_w> p1; sc_port<if_r> p2;

p1->write( ) P1 my_channel P2 p2->read( )

class if_w: virtual sc_interface { class if_r: virtual sc_interface {

virtual void write() = 0; virtual void read() = 0;
}; }; 23
Data Type

24
 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

25
 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

26
 Interface
class my_channel: if_w, if_r, sc_module
{ void write( ) {...}
void read( ) {…}
};
Producer Module Consumer Module

sc_port<if_w> p1; sc_port<if_r> p2;

p1->write( ) P1 my_channel P2 p2->read( )

class if_w: virtual sc_interface { class if_r: virtual sc_interface {

virtual void write() = 0; virtual void read() = 0;
}; }; 27
 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;
} 28
 Interface examples
// ----------------------------------------- // ------------------------------------------
// sc_signal_in_if // sc_signal_inout_if
// this interface provides a ‘read’ method // this interface provides ‘read’ & ‘write’ method
// ----------------------------------------- // ------------------------------------------

template <class T> template <class T>

class sc_signal_in_if : virtual public Class sc_signal_inout_if : virtual public
sc_interface { sc_signal_in_if {
public: public:
// interface methods // interface methods
virtual const T& read() const = 0; virtual void write( const T& ) = 0;
}; };
29
Difference Interface Type for Different Abstraction Level

Cycle Accurate Model Transaction Level Model

Interfaces in form of signals of Interfaces in the form of read
request, grant, address, data, etc (address) or write (address, data)

30
 Channel
class my_channel: if_w, if_r, sc_module
{ void write( ) {...}
void read( ) {…}
};
Producer Module Consumer Module
sc_port<if_w> p1; sc_port<if_r> p2;

p1->write( ) P1 my_channel P2 p2->read( )

class if_w: virtual sc_interface { class if_r: virtual sc_interface {

virtual void write() = 0; virtual void read() = 0;
}; }; 31
 SystemC Channel?
 Means for communication between modules sc_interface
 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]; my_channel
} (sc_signal)
void write(int & addr, int & data) {
arr[addr]= data;
}
} 32
 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;
}
}

33
 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;
}
}
34
 SystemC Port
write( T& value ) { T& read() {
m_value = value; return m_value;
} }

Channel

port1->write(value ) Value = port2->read()

Module1 Module2

Output Port 35 Input Port

 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);
36
 SystemC Ports
// SystemC // Verilog
sc_in <signaltype> port1; input wire port1;
sc_out <signaltype> port2 ; output wire port2;

sc_inout<signaltype> port3; inout wire port3;

 Example
– sc_in<sc_logic> a[32]; //input ports a[0] to a[31] of type sc_logic

37
 Now, altogether…
sc_port sc_interface

Specify communication
services (pure virtual
my_port<my_interface> my_interface methods)

Implement
my_channel communication
services

 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
 Module

// SystemC // Verilog
SC_MODULE(module_name){ module module_name();
------ -----
} endmodule
39
 SystemC Module
 Basic building block to partition a complex design into smaller
components
 Module is a C++ class.

40
 Connecting Module to Channel

Ports
Module

Channel

Process

Binding Interface

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

• Event
• Process

43
Event

44
 SystemC Event
 Basic synchronization object

 Events
– are used to synchronize processes
– are declared in a module

 Syntax
sc_event event_name1, event_name2, ... ;

45
 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);

46
 Process

// SystemC // Verilog
SC_METHOD(blk); always @(clk)
sensitive <<clk; begin : blk
...
void blk(){...} end

47
 SystemC Process
module module
P process P channel P process P
p_in p_out p_in p_out

 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:
1. Threads: SC_THREAD
2. Methods: SC_METHOD

48
 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
49
 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

50
 wait() Statement for a Thread
 Once (re)-activated, its statements are executed until a wait()
statement is encountered
THREAD
 Execution will be suspended upon hitting the wait() statement
 At its next reactivation, it will resume from the statement
immediately following the wait()
wait(e);
 If no wait() is executed, the process will execute in zero time
 Examples:
– wait (e1| e2| e3)
– wait (200, SC_NS)
– wait (200, SC_NS, e1&e2&e3)
– wait (SC_ZERO_TIME)

51
 Example of a Thread Declaration
SC_HAS_PROCESS (traffic_generator);
traffic_generator(sc_module_name, …) {
void compute(void);
Process declaration
within the module’s SC_THREAD(compute);
constructor!
sensitive << irq;
}

void compute(void) {
while(true) {
----
wait(event);
}
} 52
 Method Process
What is it different from a thread process?
Similar to a thread process except that it cannot be suspended

Sensitivity List
• Static Sensitivity: Same as for thread processes
• Dynamic Sensitivity:
– next_trigger(event);
– next_trigger(time);

53
 Declare, Invoke and Execute a Method Process
 Invoked by the SystemC scheduler whenever sensitive list changes
 Once invoked, the entire body of the process will be executed
 Upon completion, the method process returns the execution control back to
the simulation kernel
SC_HAS_PROCESS (traffic_generator);
traffic_generator(sc_module_name name, …) {
void display (void);
Process declaration
within the module’s SC_METHOD(display);
constructor! sensitive << irq;
}
void display (void{
- ----
next_trigger (event);
54
}
 Method Processes
.h file .cpp file

void Mux21::doIt( void ) {

SC_MODULE(Mux21 ){ sc_uint<8> out_tmp;
void doIt( void );
if( selection.read() ) {
SC_CTOR( Mux21 ) {
out_tmp = in2.read();
SC_METHOD( doIt ); } else {
sensitive << selection; out_tmp = in1.read();
sensitive << in1; }
sensitive << in2; out.write( out_tmp );
} }
Now, altogether…
Simulator

 Time Concepts
 SystemC Synchronization
 SystemC Scheduler

57
Time Concepts

58
 Physical Time vs. Simulation Time
Physical Time Line
Instant of Simulation I Instant II Instant III

P1 P2 P3 P2 P4 P1 P3

Instant III

Instant II
Instant of Simulation I Simulation Time Line

59
SystemC Synchronization

60
 System Synchronization
Using SC_THREAD

• SystemC models concurrency

– Synchronization primitives are thus needed

• To suspend a process in SystemC

– wait()

• To resume the execution of a suspended process

– notify(…)

61
 Synchronizing by Event Notification

Process A Process B

Time
wait(e);
e.notify();

The process is suspended by the wait statement resumes its execution when the
awaited event, e, is notified

62
SystemC Scheduler

63
 Process Management
by a non-preemptive scheduler

Selected by
scheduler for
running
Running Eligible

Awaken by an event
Execution suspended
notification for next
upon a wait(), etc
Sleeping selection

SPG
64
systemc_tr1.0
 SystemC: Execution Flowchart
// Entry point for program execution
void sc_main () { Program Entry
Elaboration Starts
sc_signal timer1_sig, timer2_sig;
my_channel channel(“Channel1”);
// Declaration and instantiation of the platform components
Timer timer1(“T1” );
Timer timer2(“T2” );
Itc itc(“ITC1”);
//Bind the modules to the communication channel using ports
timer1.sigoutport(timer1_sig);
timer1.chanport(channel);
timer2.chanport(channel);
timer2.sigoutport(timer2_sig);
itc.in1(timer1_sig);
itc.in2(timer2_sig);
Elaboration Ends
itc.chanport(channel);
sc_start(-1); // -1 = runs indefinitely 65 Simulation Starts
 The Simulation Delta Cycle
Scenario Multiple independent but intercommunicating processes
Problem The processes are executed concurrently but in a non-
deterministic order that can give rise to race conditions.
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 all “runnable” process to resting state deferring the
changes/ updates made by them
 Update Make available those deferred changes/ updates

update
cycle count

evaluate 66
Process Management – Simulation Flowchart

67
SC_MODULE(my_mod){
void P1(void); 0ns+delta1 Evaluate run P1
void P2(void); 0ns+delta1 Evaluate run P2
sc_port<sc_signal_inout_if<sc_logic> > port;
sc_event event;
SC_CTOR(my_mod){ 0ns+delta1 Update update port with '1'
SC_THREAD(P1);
SC_THREAD(P2); 0ns+delta2 Evaluate Run P1=> event
port.initialize('Z'); notification will make
} P2 runnable in current
}; evaluate phase.
void my_mod::P1(void) { void my_mod::P2(void) {
0ns+delta2 Evaluate Run P2
port->write('1'); P2 comes to end &exit.
wait(SC_ZERO_TIME); cout<<port->read();
0ns+delta2 Update Update port with '2'
cout<<port->read(); wait(event);
port->write('2'); cout<<port->read(); 0ns+delta2 Update simulation time
event.notify(); advances to 10ns
}
cout<<port->read(); 10ns+delta1 Evaluate Run P1
P1 comes to end & exit
wait(10,SC_NS);
cout<<port->read(); Simulation stopped: No runnable thread/ Event
68
}
Example of SystemC Models

• Example of SystemC IP
• Example of SystemC System

69
Example of SystemC IP

70
 D Flip-Flop
#include “systemc.h”
SC_MODULE (dff) {
sc_in<bool> din;// Declaration of ports
sc_in<bool> clock;
sc_out<bool> dout;
void doit(void); // Declaration of the process
// Constructor //dff.cpp
SC_CTOR (dff) { #include “dff.h”
// registering process with kernel // process implementation
SC_METHOD (doit); void dff :: doit();
sensitive_pos << clock ;// Sensitivity list dout = din;
} }
}; 71
Example of SystemC System

72
 A Typical System
ITC1
Process
ITC1
• an object, i.e. instance of the class
Port
sig2 ITC

Channel TIMER1 and TIMER2

sig1 • 2 objects, i.e. instances of the class
TIMER

sig1 and sig2

• 2 objects, i.e. instances of the class
sc_signal
TIMER1 TIMER2

73
 Steps to develop SystemC System
 Write sc_main

 Instantiate the components of the system

 Bind the modules to the communication channels through port

 Start the simulation by calling sc_start(args)

74
 Example Code
// Entry point for the program execution
void sc_main () { Program Entry
sc_signal timer1_sig, timer2_sig;
my_channel channel(“Channel1”);
// Declaration and instantiation of the platform components
instantiation
Timer timer1(“T1” );
Timer timer2(“T2” );
Itc itc(“ITC1”);
//Bind the modules to the communication channel using ports
timer1.sigoutport(timer1_sig);
timer1.chanport(channel);
timer2.chanport(channel);
timer2.sigoutport(timer2_sig); Binding
itc.in1(timer1_sig);
itc.in2(timer2_sig);
itc.chanport(channel);
// Starting the simulation 75
SystemC is

76
 SystemC 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, 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.
TLM
 Complexity of Designs
• Let’s take an example:
– Design a quad core SoC where each core ...
• ... has a multistage-stage superscalar out-of-
order pipeline.
• ... has 8 threads of execution supporting
speculative loads and stores
• ... supports precise exception
• ... has a tournament branch predictor with 6
different predictors
• ... has a separate L1 D-cache, L1 I-cache and a
unified L2 cache whose size, number of blocks
per line, and associativity is parameterizable.
 Complexity of Verification
• What if there is a Load operation which has
a TLB miss, a cache miss and a page fault,
and is speculatively executing on a
conditional branch which is mispredicted?
• Generate a test case?
 Introduction : System On Chip

• How does a system-on-chip like today?

81
 System On Chip Design Flow

Bottlenecks: Solution:
• Explosive Complexities • Raise the level of
TLM or Virtual Prototype
• Cost as
fulfills both conditions
abstraction for system level
• Time to market Pressure
the ideal solution design
• Support HW/SW co- Benefits of V.P.:
development • Better Time to Market
• Quality Confidence
Virtual • Communication Point
• Reference Simulation
Prototype
Architecture

Design Architecture Software Development

Early system integration

Verification
Coding
Silicon
Integration
Board
Hardware Development

Validation
System Development Time To Market saved
 High Level Modeling
Enab
i f i es le
HW/S s
l on
i mp cati W
S rifi co-de
ve si gn

s
Promote
reuse
ck
Qui n
ig
des ce
spa atio Re
l or de duc
exp n
tur sign ed
n a an
r d
tim ound
e
 What is a Virtual Prototype?
• Fully functional software model of complete systems

• SoC, board, I/O, user interface

• Executes unmodified production code

• Drivers, OS, and applications Software Stack

• Runs fast Virtual Prototype

• Boots OS in seconds
• Highest debugging efficiency through full system visibility and control

• Supports multi-core SoCs debug

•Easy deployment
 Why Prototype?
Without Prototyping
Spec Freeze Tape Out Silicon Project Finished

Arch Manufac- Software Development, HW/SW

SoC Hardware Development
Design turing Integration & System Validation

With Prototyping
Spec Freeze Tape Out Silicon Project Finished

Arch Manufac-
SoC Hardware Development
Design turing

Software Development, Integration & Gained TTM

System Validation
 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
– Transaction level modeling and verification increases
your productivity
Transaction
• Less detail means higher performance and easier debug
Transactor
• EarlierHeader Payload
testing (before RTL) means less expensive bug fixes
– SystemC TLM Models
A transactor popular
adapts between inlevel
a transaction Virtual Platforms
interface and for
a signal level interface

SW bring up
Refining the Transaction Level Model

•You refine the transaction level model

(eventually
Transactionto synthesizable RTL) while
Transaction-Level
Transaction

maintaining
Producer
(random) the transaction level system
Model (golden)
Consumer
(checker)

environment.
Refined
Transactor Transactor
Model
(master) (slave)
(RTL)
Transaction Level Modeling 101

Functiona
RTL
l Model

Transaction level
Pin accurate, - function call
cycle accurate write(address,data
)

RTL Functiona
l Model

Simulate every event 100-10,000 X faster simulation

88
 Reasons for Using TLM
Accelerates product release schedule

Firmware / Software development

software

Fast enough
TLM Architectural modeling
Ready before RTL

RTL
Hardware verification
Test bench
TLM = golden model

89
 Typical Use Cases for TLM
• Represents key architectural components of hardware
platform
• Architectural exploration, performance modelling
• Software execution on virtual model of hardware platform
• Golden model for hardware functional verification
• Available before RTL
• Simulates much faster than RTL

90
History of TLM

91
 TLM-2 Requirements
• Transaction-level memory-mapped bus modelling
• Register accurate, functionally complete
• Fast enough to boot software O/S in seconds
• Loosely-timed and approximately-timed modelling
• Interoperable API for memory-mapped bus modelling
• Generic payload and extension mechanism
• Avoid adapters where possible

92
 Use Cases, Coding Styles and
Mechanisms
Use cases

Software Software Architectural Hardware

development performance analysis verification

TLM-2 Coding styles

Loosely-timed

Approximately-timed

Mechanisms

Blocking Generic Non-blocking

DMI Quantum Sockets Phases
interface payload interface

93
 Coding Styles

• Loosely-timed = as fast as possible

– Only sufficient timing detail to boot O/S and run multi-core s
– Processes can run ahead of simulation time (temporal decoup
– Each transaction has 2 timing points: begin and end
– Uses direct memory interface (DMI)

• Approximately-timed = just accurate enough for performance modeling

– aka cycle-approximate or cycle-count-accurate
– Sufficient for architectural exploration 94
 The TLM 2.0 Classes
Utilities:
Interoperability layer for bus modeling Convenience sockets
Payload event queues
Quantum keeper
Generic payload Phases
Instance-specific extn

Initiator and target sockets

TLM-1 standard TLM-2 core interfaces:

Analysis ports
Blocking transport interface
Non-blocking transport interface
Direct memory interface
Debug transport interface Analysis interface

IEEE 1666™ SystemC

95
 Interoperability Layer
1. Core interfaces and sockets

Initiato
Target
r

2. Generic payload 3. Base protocol

Command BEGIN_REQ
Address
Data
END_REQ
Byte enables
Response status
BEGIN_RESP
Extensions
END_RESP

Maximal interoperability for memory-mapped bus models

96
 Directory Structure

include/tlm
tlm_h
tlm_req_rsp TLM-1.0 legacy
tlm_trans TLM-2 interoperability classes
tlm_2_interfaces TLM-2 core interfaces
tlm_generic_payloadTLM-2 generic payload
tlm_sockets TLM-2 initiator and target sockets
tlm_quantum TLM-2 global quantum
tlm_analysis TLM-2 analysis interface, port, fifo
tlm_utils TLM-2 utilities

docs
doxygen
examples
unit_test

97
 Utilities
• tlm_utils
– Convenience sockets
– Payload event queues
– Quantum keeper
– Instance-specific extensions

• Productivity
• Shortened learning curve
• Consistent coding style

• Not part of the interoperability layer

98
Initiator and Target Sockets

Initiator Target
socket socket

b_transport ()
nb_transport_fw()
Initiator Target
get_direct_mem_ptr()
transport_dbg()

nb_transport_bw()
invalidate_direct_mem_ptr()

Link
Sockets provide fw and bw paths and group interfaces

99
 Benefit of Sockets
• Group the transport, DMI and debug transport interfaces
• Bind forward and backward paths with a single call
• Strong connection checking
• Have a bus width parameter

• Using core interfaces without sockets is not recommended

100
TLM-2 Core Interfaces - Transport
tlm_blocking_transport_if

void b_transport( TRANS& , sc_time& ) ;

tlm_fw_nonblocking_transport_if

tlm_sync_enum nb_transport_fw( TRANS& , PHASE& ,

sc_time& );
tlm_bw_nonblocking_transport_if

tlm_sync_enum nb_transport_bw( TRANS& , PHASE& ,

sc_time& );

101
TLM-2 Core Interfaces - DMI and
Debug
tlm_fw_direct_mem_if

bool get_direct_mem_ptr( TRANS& trans , tlm_dmi&

dmi_data ) ;
tlm_bw_direct_mem_if

void invalidate_direct_mem_ptr( sc_dt::uint64 start_range,

sc_dt::uint64 end_range ) ;

tlm_transport_dbg_if

unsigned int transport_dbg( TRANS& trans ) ;

May all use the generic payload transaction type

102
 Blocking versus Non-blocking
•
Transport
Blocking transport interface
LT AT
Socket
s

– Includes timing annotation

– Typically used with loosely-timed coding style
– Forward path only

• Non-blocking transport interface

– Includes timing annotation and transaction phases
– Typically used with approximately-timed coding style
– Called on forward and backward paths

• Share the same transaction type for interoperability

103
 Blocking Transport LT

Transaction type

template < typename TRANS = tlm_generic_payload >

class tlm_blocking_transport_if : public virtual sc_core::sc_interface {

public:
virtual void b_transport ( TRANS& trans , sc_core::sc_time& t ) =
0;
};
Transaction object Timing annotation

Link
104
Blocking Transport – With Wait
Initiator Target

Simulation time = 100ns

Call b_transport(t, 0ns)

wait(40ns)

Return
Simulation time = 140ns

Call b_transport(t, 0ns)

wait(40ns)

Return
Simulation time = 180ns

Initiator is blocked until return from b_transport

105
Blocking Transport – With Timing
Annotation
Initiator Target

Simulation time = 100ns

Call b_transport(t, 0ns) Local time = 100 + 0ns

-,t,40ns Return
Local time = 100 + 40ns

Call b_transport(t, 40ns) Local time = 100 + 40ns

Local time = 100 + 80ns -,t,80ns Return

wait(80ns)

Simulation time = 180ns

Fewer context switches means higher simulation speed

106
 The Time Quantum
Initiator Target

Simulation time = 1us Quantum = 1us

Local time offset

Call b_transport(t, 950ns)

+950ns

+970ns
b_transport(t, 970ns) Return

Call b_transport(t, 990ns)

+990ns

+1010ns
b_transport(t, 1010ns) Return

wait(1us)
Simulation time = 2us
Call b_transport(t, 0ns)
+0ns

107
 The Quantum Keeper
(tlm_quantumkeeper)
debug
• Quantum is user-configurable
speed

LL
SMA
u
ant
qu m r
e ve
BIG l

• Processes can check local time against quantum

 Non-blocking Transport AT
Non
blocking

enum tlm_sync_enum { TLM_ACCEPTED, TLM_UPDATED, TLM_COMPLETED };

template < typename TRANS = tlm_generic_payload,

typename PHASE = tlm_phase>

class tlm_fw_nonblocking_transport_if : public virtual sc_core::sc_interface {

public:
virtual tlm_sync_enum nb_transport( TRANS& trans,
PHASE& phase,
sc_core::sc_time& t ) = 0;
};

Trans, phase and time arguments set by caller and modified by callee
109
 tlm_sync_enum
• TLM_ACCEPTED
– Transaction, phase and timing arguments unmodified (ignored) on return
– Target may respond later (depending on protocol)

• TLM_UPDATED
– Transaction, phase and timing arguments updated (used) on return
– Target has advanced the protocol state machine to the next state

• TLM_COMPLETED
– Transaction, phase and timing arguments updated (used) on return
– Target has advanced the protocol state machine
Link straight to the final phase

110
 Using the Backward Path
Phase Initiator Target

Simulation time = 100ns

Call -, BEGIN_REQ, 0ns

BEGIN_REQ Return TLM_ACCEPTED, -, -

Simulation time = 110ns
-, END_REQ, 0ns Call

END_REQ Return
TLM_ACCEPTED, -, -
Simulation time = 120ns
-, BEGIN_RESP, 0ns Call

BEGIN_RESP TLM_ACCEPTED, -, - Return

Simulation time = 130ns

Call -, END_RESP, 0ns

END_RESP
Return
TLM_COMPLETED, -, -

Transaction accepted now, caller asked to wait

111
 Using the Return Path
Phase Initiator Target

Simulation time = 100ns

Call -, BEGIN_REQ, 0ns

BEGIN_REQ Return TLM_UPDATED, END_REQ, 10ns

END_REQ Simulation time = 110ns

Simulation time = 150ns

-, BEGIN_RESP, 0ns Call

BEGIN_RESP TLM_COMPLETED, END_RESP, 5ns Return

END_RESP Simulation time = 155ns

Callee annotates delay to next transition, caller waits

112
 Early Completion
Phase Initiator Target

Simulation time = 100ns

Call -, BEGIN_REQ, 0ns

BEGIN_REQ TLM_COMPLETED, -, 10ns Return

END_RESP Simulation time = 110ns

Callee annotates delay to next transition, caller waits

113
 Timing Annotation
Phase Initiator Target

Simulation time = 100ns

Call -, BEGIN_REQ, 10ns

Return
TLM_ACCEPTED, -, - Payload
Event
Queue
BEGIN_REQ Simulation time = 110ns

Simulation time = 125ns

-, END_REQ, 10ns Call

Payload Return TLM_ACCEPTED, -, -

Event
Queue
END_REQ Simulation time = 135ns

114
 DMI and Debug Transport
 Direct Memory Interface LT DMI
– Gives an initiator a direct pointer to memory in a target, e.g an ISS
– By-passes the sockets and transport calls
– Read or write access by default
– Extensions may permit other kinds of access, e.g. security mode
– Target responsible for invalidating pointer

 Debug Transport Interface

– Gives an initiator debug access to memory in a target
– Delay-free
– Side-effect-free

 May share transactions with transport interface

115
 Direct Memory Interface
Access requested Access granted

status = get_direct_mem_ptr( transaction, dmi_data );

tlm_fw_direct_me
m_if
Forward path Interconnec Forward path
Initiator t Target
component
Backward path Backward path

tlm_bw_direct_me
m_if
invalidate_direct_mem_ptr( start_range, end_range );

Transport, DMI and debug may all use the generic payload
Interconnect may modify address and invalidated range
116
DMI Transaction and DMI Data
DMI Transaction

Requests read or write access

For a given address
Permits extensions

class tlm_dmi

unsigned char* dmi_ptr Direct memory pointer

uint64 dmi_start_address
Region granted for given access type
uint64 dmi_end_address
dmi_type_e dmi_type; Read, write or read/write

sc_time read_latency Latencies to be observed by initiator

sc_time write_latency

117
 Debug Transport Interface
Command
Address
Data pointer
num_bytes = transport_dbg( transaction ); Data length
Extensions
tlm_transport_dbg
_if

Forward path Interconnec Forward path

Initiator t Target
component
Backward path Backward path

Uses forward path only

Interconnect may modify address, target reads or writes data
118
 The Generic Payload LT AT

• Typical attributes of memory-

mapped busses
– command, address, data, byte
enables, single word transfers,
burst transfers, streaming, response
status

• Off-the-shelf general purpose

Specific protocols can use the same generic payload machinery

payload
– for abstract bus modeling
119
Generic Payload Attributes
Attribute Type Modifiable?

Command tlm_command No
Address uint64 Interconnect
only
Array owned by
Data pointer unsigned char* No (array – yes) initiator

Data length unsigned int No Array owned by

initiator
Byte enable pointer unsigned char* No (array – yes)

Byte enable length unsigned int No

Streaming width unsigned int No

Try DMI !
DMI hint bool Yes
Response status tlm_response_status Target only
Consider memory
Extensions (tlm_extension_base* Yes management
)[ ]

120
 class tlm_generic_payload
class tlm_generic_payload { Not a template
public:

// Constructors, memory management

tlm_generic_payload () ;
Construct & set mm
tlm_generic_payload(tlm_mm_interface& mm) ;Frees all extensions
virtual ~tlm_generic_payload (); Frees mm’d extensions
void reset();
mm is optional
void set_mm(tlm_mm_interface* mm);
bool has_mm(); Incr reference count
void acquire(); Decr reference count, 0 => free trans
void release();
int get_ref_count();

void deep_copy_into(tlm_generic_payload& other) const;

... 121
};
 Memory Management Rules
 b_transport – memory managed by initiator, or reference counting
(set_mm)

 nb_transport – reference counting only

 Reference counting requires heap allocation
 Transaction automatically freed when reference count == 0
 free() can be overridden in memory manager for transactions
 free() can be overridden for extensions

 When b_transport calls nb_transport, must add reference counting

 Can only return when reference count == 0

 b_transport can check for reference counting, or assume it could be

122
present
Command, Address and Data
enum tlm_command {
TLM_READ_COMMAND, Copy from target to data array
TLM_WRITE_COMMAND, Copy from data array to target
TLM_IGNORE_COMMAND Neither, but may use extensions
};

tlm_command get_command() const ;

void set_command( const tlm_command command ) ;

sc_dt::uint64 get_address() const;

void set_address( const sc_dt::uint64 address );

unsigned char* get_data_ptr() const; Data array owned by initiator

void set_data_ptr( unsigned char* data );

unsigned int get_data_length() const; Number of bytes in data array

void set_data_length( const unsigned int length );

123
 Response Status
enum tlm_response_status Meaning

TLM_OK_RESPONSE Successful
TLM_INCOMPLETE_RESPONSE Transaction not delivered to target.
(Default)
TLM_ADDRESS_ERROR_RESPONSE Unable to act on address

TLM_COMMAND_ERROR_RESPONS Unable to execute command

E
TLM_BURST_ERROR_RESPONSE Unable to act on data length or streaming
width
TLM_BYTE_ENABLE_ERROR_RESP Unable to act on byte enable
ONSE
TLM_GENERIC_ERROR_RESPONSE Any other error

124
The Standard Error Response
• A target shall either
– Execute the command and set
TLM_OK_RESPONSE
– Set the response status attribute to an error response

– Call the SystemC report handler and set

TLM_OK_RESPONSE

125
 Generic Payload Example 1
void thread_process() { // The initiator
tlm::tlm_generic_payload trans; Would usually pool transactions
sc_time delay = SC_ZERO_TIME;

trans.set_command( tlm::TLM_WRITE_COMMAND );
trans.set_data_length( 4 );
trans.set_byte_enable_ptr( 0 );
trans.set_streaming_width( 4 );

for ( int i = 0; i < RUN_LENGTH; i += 4 ) {

int word = i;
trans.set_address( i );
trans.set_data_ptr( (unsigned char*)( &word ) );
trans.set_response_status( tlm::TLM_INCOMPLETE_RESPONSE );

init_socket->b_transport( trans, delay );

if ( trans.get_response_status() <= 0 )
SC_REPORT_ERROR("TLM2", trans.get_response_string().c_str());
...
}
126
Generic Payload Extension Methods
• Generic payload has an array-of-pointers to extensions
• One pointer per extension type
• Every transaction can potentially carry every extension type
• Flexible mechanism

template <typename T> T* set_extension ( T* ext ); Sticky extn

template <typename T> T* set_auto_extension ( T* ext ); Freed by ref counting

template <typename T> T* get_extension() const;

Clears pointer, not extn object
template <typename T> void clear_extension ();

template <typename T> void release_extension (); mm => convert to auto

no mm => free extn object

127
 Extension Example
struct my_extension : tlm_extension<my_extension> User-defined extension
{
my_extension() : id(0) {}
tlm_extension_base* clone() const { ... }
Pure virtual methods
virtual void copy_from(tlm_extension_base const &ext) { ... }
int id;
};
...

tlm_generic_payload* trans = new tlm_generic_payload( mem_mgr ); Heap allocation

trans->acquire(); Reference counting

my_extension* ext = new my_extension;

ext->id = 1;
trans.set_extension( ext );

socket->nb_transport_fw( *trans, phase, delay );

trans.release_extension<my_extension>(); Freed when ref count = 0

trans->release(); Trans and extn freed

128
Base Protocol - Coding Styles
• Loosely-timed is typically
– Blocking transport interface, forward and return path
– 2 timing points
– Temporal decoupling and the quantum keeper
– Direct memory interface

• Approximately-timed is typically
– Non-blocking transport interface, forward and backw
– 4 phases
– Payload event queues 129
Base Protocol and tlm_phase
 The base protocol = tlm_generic_payload + tlm_phase
 tlm_phase has 4 phases, but can be extended to add new phases

enum tlm_phase_enum { UNINITIALIZED_PHASE = 0,

BEGIN_REQ=1, END_REQ, BEGIN_RESP, END_RESP };

class tlm_phase {
public:
tlm_phase();
tlm_phase( unsigned int id );
tlm_phase( const tlm_phase_enum& standard );
tlm_phase& operator= ( const tlm_phase_enum& standard );
operator unsigned int() const;
};

#define DECLARE_EXTENDED_PHASE(name_arg) \
class tlm_phase_##name_arg : public tlm::tlm_phase { \ 130
...
 Base Protocol Rules
• Base protocol phases
– BEGIN_REQ  END_REQ  BEGIN_RESP  EN
– Must occur in non-decreasing simulation time order
– Only permitted one outstanding request or response p
– Phase must change with each call (other than ignorab
– May complete early

• Generic payload memory management rules

• Extensions must be ignorable
• Target is obliged to handle mixed b_transport / nb_transport
• Write response must come from target

131
 Why Do We Need TLM Standard ?
Mismatch
a. Port types
Per3 b. API

Initiator1 c. Function params

d. Protocols
Per2
Interopability

Initiator2
Disadvantages
Per1 Per2
Ext IP a.Develop time
b.Maintenance
c.Simulation speed

1 Link
3
2

September 17, 2023

 Acronyms

• Initiator – module that initiates new

transactions
• Target – module that responds to
transactions initiated by initiator
• Transaction – data structure (C++
object) passed between initiators and
targets using function calls
Link

1
3
3

September 17, 2023

 Code Snippet - Example 1 1/4
#include “tlm.h”  TLM 2.0 interoperability standard
#include "tlm_utils/simple_initiator_socket.h" TLM Utility
#include "tlm_utils/simple_target_socket.h"

struct simple_initiator : sc_module {

tlm_utils::simple_initiator_socket<simple_initiator>
init_socket;
SC_CTOR(simple_initiator) : init_socket(“init_socket”) { ...}
};
struct memory : public sc_module {
tlm_utils::simple_target_socket<memory> mem_socket;
SC_CTOR(memory):mem_socket(“mem_scoket”) { …}
};

1
3
4

September 17, 2023

 Code Snippet - Example 1 2/4
struct Top : sc_module {
simple_initiator *initiator;
memory *mem;
SC_CTOR(Top) {
initiator = new
simple_initiator(“simple_initiator”);
mem = new memory(“memory”);
initiator->init_socket.bind(mem->mem_socket);
}
};
int sc_main() {
Top top(“top”);
sc_start();
return 0;
1 }
3
5

September 17, 2023

 Code Snippet - Example 1 3/4
struct simple_initiator : sc_module {
tlm_utils::simple_initiator_socket<simple_initiator>
init_socket;
SC_CTOR(simple_initiator) : init_socket(“init_socket”) {
SC_THREAD(test_process);
}
void test_process() {
while(1) {
tlm::tlm_generic_payload *gp = new
tlm::tlm_generic_paylaod;
sc_time delay;
// Set different fields of GP
init_socket->b_transport(*gp, delay);
….
}
1
3 }
6
}
September 17, 2023
 Code Snippet - Example 1 4/4

struct memory : sc_module {

tlm_utils::simple_target_socket<memory> mem_socket;
SC_CTOR(memory):mem_socket(“mem_scoket”) {
…
mem_socket.register_b_transport(this,
&memory::b_transport);
}
void b_transport(tlm::tlm_generic_payload &gp, sc_time
&delay) { …}
};

Link

1
3
7

September 17, 2023

 Sockets AT Sockets

• Transaction involve communication in both direction

sc_port sc_export

Initiator Target

sc_export sc_port

• Initiator and Target Sockets makes it convenient

Initiator Target

Initiator Socket Target Socket

1
3
8

September 17, 2023

 Sockets
Initiator Target
init_skt->fw() Fw_methods

init_skt->bw()
Bw_methods

• Implemented as SystemC channels

struct Initiator : sc_module, tlm::tlm_bw_transport_if<> {}
struct Target : sc_module, tlm::tlm_fw_transport_if<> {}

1
3
9

September 17, 2023

 Sockets
• Example Initiator module
struct initiator : sc_module, tlm::tlm_bw_transport_if<> {
tlm::tlm_initiator_socket<> init_socket;

// Must implement all backward calls

tlm::tlm_sync_enum nb_transport_bw(…) {}
void invalidate_direct_mem_ptr(…) {}
};

1
4
0

September 17, 2023

 Sockets
• Example Target module
struct target : sc_module, tlm::tlm_fw_tranaport_if<> {
tlm::tlm_target_socket<> target_socket;
…
// Must implement all forward calls
void b_transport(…) {}
tlm::tlm_sync_enum nb_transport_fw(…) { }
bool get_direct_mem_ptr(…) {}
unsigned int transport_dbg(…) { }
}; Link

1
4
1

September 17, 2023

LT Mechanisms for Increasing Simulation
Speed

• Impediments to simulation speed

• Context switches
– Reduce context switches with temporal decoupling
• Function call hierarchy
– By-pass bus with direct access to memory (DMI)

Link

1
4
2

September 17, 2023

 Phases
• BEGIN_REQ
• Initiator acquires the bus
• Connection becomes busy and clocks further requests

• END_REQ
• Target ‘accepts’ the request
• Bus free to start additional requests

• BEGIN_RESP
• Target acquires the bus to provide response
• Bus becomes ‘busy’

• END_RESP
• Initiator acknowledges response
• Bus is freed
• Payload reference freed-up
Link
1
4
3

September 17, 2023

 Quantum Keeper Example LT
Quantu
m
struct Initiator: sc_module Keeper
{
tlm_utils::simple_initiator_socket<Initiator> init_socket;
tlm_utils::tlm_quantumkeeper m_qk; The quantum keeper

SC_CTOR(Initiator) : init_socket("init_socket") {
...
m_qk.set_global_quantum( sc_time(1, SC_US) ); Replace the global quantum
m_qk.reset(); Recalculate the local quantum
}
void thread() { ...
for (int i = 0; i < RUN_LENGTH; i += 4) {
...
delay = m_qk.get_local_time() ;
init_socket->b_transport( trans, delay );
m_qk.set( delay ); Time consumed by transport
m_qk.inc( sc_time(100, SC_NS) ); Further time consumed by initiator
if ( m_qk.need_sync() ) Check local time against quantum
m_qk.sync(); and sync if necessary
}
}
};

144
CHALLENGES AHEAD
 Chanellenges(1/3)
• Need for more performance!
– TLM 2.0 LT style modeling is a very good step forward
• Simulations with speed from tens to hundreds of MIPS achievable,
with LT style modeling and temporal decoupling
– But .. Lot more space to cover
• Multi-core simulation
• Board level simulation(multiple soc simulation)
– Options
• Parallel simulator
• Pararalled discrete event simulation
– Had a bit of success in TCIC6618 simulator, with board-level simulation.
– Native support on systemC poC?
 Challenges(2/3)…
• Model-model interoperability standard
– TLM 2.0 interface standard increaded interopbility.
– More space to cover
– Non memory mapped interfaces
• Interrupts
• Serial interrupts
• IO interfaces
– PCIr
– UART
– I2C etc.
 Challenges(3/3)
• Tool-model interopablilty standards
– Aware of OSCI initiative on CCI standards for
configuration and contrl
– Current gaps
• Software debugger and ISA model interop standards.
• Use-case descpiptionfor rapid-prototyping and architecture-
stidie
• Winndows DLL
– Support in 2.3.1 draft versoin.