Lecture 7 TLM API 1.

0 in SystemC Part I
Multimedia Architecture and Processing Laboratory Prof. Wen-Hsiao Peng () pawn@mail.si2lab.org 2007 Spring Term

Reference
Frank, Ghenassia, Transaction-Level

Modeling with System C TLM Concepts and Applications for Embedded Systems, Springer,
2005. (ISBN: 0-387-26232-6)

A. Rose, S. Swan, J. Pierce, and J.M Fernandez, OSCI TLM

Standard Whitepaper: Transaction Level Modeling in SystemC, http://www.systemc.org Cadence Design Systems, March 2006

S. Swan, A Tutorial Introduction to the SystemC TLM Standard,

TLM API 1.0

What does TLM API 1.0 provide?

Define core interfaces and standard channels for communication

Users can design their own channels implementing core interfaces

What is not defined in TLM API 1.0?

The content of the transactions

The task left for the TLM 2.0 that is now under development

The constraints on the implementation of channels

High Level Goals

Provide a common way of TLM modeling at different levels

A "recipe" that allows new users to get started quickly

Help users avoid problems

Concurrency, memory leaks, pointer aliasing, SEGFAULTS, etc.

Achieve efficiency in space and time without sacrificing clarity and safety

A set of interfaces that map to both HW and SW, and across HW/SW
Create interfaces and methods that support IP reuse

within a project from one abstraction level to another across projects

Promote IP interoperability through standard interfaces Promote a design style encapsulating functions in a polymorphous way

Operations on classes are independent of the class An arbiter that is independent of the transaction data type

General Strategy
Establish a fundamental set of TLM interfaces Core interfaces

Unidirectional interfaces - send data in one direction

tlm_put_if<T>, tlm_get_if<T>, tlm_peek_if<T>

Bidirectional interfaces - send data in both directions

tlm_transport_if<REQ, RSP> tlm_maser_if<REQ, RSP>, tlm_slave_if<REQ, RSP>

Standard channels

tlm_fifo<T>, tlm_req_rsp_channel<REQ,RSP> tlm_transport_channel<REQ,RSP>

Communication Types
Bidirectional communication

A read transaction across a bus is bidirectional Burst write with a completion bus status is bidirectional
Unidirectional communication

Place read address on bus is unidirectional Send IP packet is unidirectional

Complex protocol can be broken down into a sequence of

bidirectional or unidirectional transfers

A complex bus with address, control and data phases may look

like a simple bidirectional read/write bus at a high level of abstraction, but more like a sequence of pipelined unidirectional transfers at a more detailed level

Interface Styles
Similar to interfaces of sc_fifo Data transfer is effectively done by Pass-by-Value mechanism

Use const & for interface parameters Data send back to caller as return value Never use pointer Never use non const & for inbound data

Inbound data is always passed by (const &)

bool nb_put(const &)

Outbound data is returned by value

There is data to return

T get()

There may not be data to return

Return the status and pass in a (non-const &) bool nb_get(T &)

Interface Styles (c. 1)

Effectively Pass-by-Value data transfer
Call by Reference
//blocking write of sc_fifo template <class T> inline void sc_fifo<T>::write( const T&val_ ) { while( num_free() == 0 ) sc_core::wait( m_data_read_event ); m_num_written ++; buf_write( val_ ); request_update(); } template <class T> inline bool sc_fifo<T>::buf_write( const T& val_ ) { if( m_free == 0 ) { return false; } m_buf[m_wi] = val_; m_wi = ( m_wi + 1 ) % m_size; m_free --; return true; Pass by Value }

Call by Reference

Interface Styles (c. 2)

Pros

Eliminate problems of pointers and dynamic memory allocation Help eliminate problems of race conditions Help you reason about concurrent systems Enable use of C++ smart containers and handles Simple, clear lifetime and ownership of objects
Cons

Naive passing of large objects may lead to performance problems

E.g, passing larger vectors or arrays of data by value

Core Interfaces

10

11

Core Interfaces
Developed based on sc_fifo interface Primary unidirectional interfaces

tlm_put_if<T> (blocking+non-blocking) tlm_get_if<T> (blocking+non-blocking) tlm_peek_if<T> (blocking+non-blocking)

Primary bidirectional interface

tlm_transport_if<REQ, RSP> (blocking)

Channel specific bidirectional interfaces

tlm_master_if<REQ, RSP> (blocking+non-blocking) tlm_slave_if<REQ, RSP> (blocking+non-blocking) Useful for tlm_req_rsp_channel and tlm_transport_channel

12

Key Terms
Peek

Peek reads most recent valid value Similar to read to a variable or signal
Put/Get

Put queues data and moves a transaction from initiator to target Get consumes data and moves a transaction from target to initiator Similar to write/read from a FIFO
Master/Slave

Master initiates activity by issuing a request Slave passively waits for requests and returns a response

13

Key Terms (c. 1)

Blocking

Mean method implementation might call wait() Methods may not return immediately Methods can be called only from SC_THREAD processes
Non-blocking

Mean method implementation can never call wait() Methods return immediately with a bool indicating the success Methods can be called from SC_METHOD or SC_THREAD processes

14

Hierarchy of Core Interfaces

tlm_master/slave_if

[3]

15

Unidirectional Interfaces
tlm_put_if tlm_blocking_put_if
template < typename T > class tlm_blocking_put_if : public virtual sc_interface { public: virtual void put( const T &t ) = 0; };

tlm_nonblocking_put_if
template < typename T > class tlm_nonblocking_put_if : public virtual sc_interface { public: virtual bool nb_put( const T &t ) = 0; virtual bool nb_can_put( tlm_tag<T> *t = 0 ) const = 0; virtual const sc_event &ok_to_put( tlm_tag<T> *t = 0 ) const = 0; };

tlm_get_if tlm_blocking_get_if
template < typename T > class tlm_blocking_get_if : public virtual sc_interface { public: virtual T get( tlm_tag<T> *t = 0 ) = 0; virtual void get( T &t ) { t = get(); } };

tlm_nonblocking_get_if
template < typename T > class tlm_nonblocking_get_if : public virtual sc_interface { public: virtual bool nb_get( T &t ) = 0; virtual bool nb_can_get( tlm_tag<T> *t = 0 ) const = 0; virtual const sc_event &ok_to_get( tlm_tag<T> *t = 0 ) const = 0; };

16

Unidirectional Interfaces (c. 1)

Non-blocking interfaces may fail and thus must return a bool value Polling-based usage of non-blocking put, get, and peek

nb_can_put/get/peek enquires whether a transfer will be successful

Interrupt-based usage of non-blocking put, get and peek

Event functions enables an SC_THREAD to wait until it is likely that the access succeeds or a SC_METHOD to be woken up
tlm_peek_if tlm_blocking_peek_if
template < typename T > class tlm_blocking_peek_if : public virtual sc_interface { public: virtual T peek( tlm_tag<T> *t = 0 ) = 0; virtual void peek( T &t ) { t = peek(); } };

tlm_nonblocking_peek_if
class tlm_nonblocking_peek_if : public virtual sc_interface { public: virtual bool nb_peek( T &t ) = 0; virtual bool nb_can_peek( tlm_tag<T> *t = 0 ) const = 0; virtual const sc_event &ok_to_peek( tlm_tag<T> *t = 0 ) const = 0; };

17

Examples of Unidirectional Interfaces

Polling-based usage

Interrupt-based usage

18

Examples of Bidirectional Interfaces

Model transactions with a tight 1-to-1, non pipelined binding

between the request and the response

A merger between the blocking get and put functions

Useful for modeling from a software programmers point of view

A read with an address going in and the read data coming back

19

Examples of Bidirectional Interfaces (c. 1)

tlm_master_if and tlm_slave_if tlm_master_if
template < typename REQ , typename RSP > class tlm_master_if : public virtual tlm_put_if< REQ > , public virtual tlm_get_peek_if< RSP > {}; class tlm_slave_if : public virtual tlm_put_if< RSP > , public virtual tlm_get_peek_if< REQ > {};

tlm_slave_if
template < typename REQ , typename RSP >

20

Hardware Implication

[3]

Standard Channels

21

22

Remarks
Users can and should design their own channels implementing

some or all of these core interfaces

They can implement them directly in the target using sc_export The transport function in particular will often be directly

implemented in a target when used to provide fast programmers view models for software prototyping

23

tlm_fifo<T>
Implement all the unidirectional TLM interfaces based on sc_fifo Support request_update/update mechanism Support fifo size of 0 and infinite

24

tlm_req_rsp_channel<REQ,RSP>
One tlm_fifo for the request going from initiator to target One tlm_fifo for the response being moved from target to initiator The fifos in tlm_req_rsp_channel can be of arbitrary size

25

tlm_transport_channel
1-to-1, non pipelined binding between request and response The fifos in tlm_req_rsp_channel must be of size one Used to bridge time and untimed TLMs

RSP transport( const REQ &req ) { mutex.lock(); master_port->put( req ); rsp = master_port->get(); mutex.unlock(); return rsp; }

Background Information

26

27

Key Terms
TLM target port

sc_export bound to a TLM core interface

TLM initiator port

sc_port bound to a TLM core interface

TLM target

Module instantiating at least one TLM target port

TLM initiator

Module instantiating at least one TLM initiator port

TLM transactions

Data structures transferred by TLM core interface

28

Key Terms (c. 2)

System initiator

Example: a CPU issuing read/write requests

System target

Example: a memory serving read/write requests

System transactions

Example: a read/write operation from a CPU to a memory

Corollary

A system initiator is always a TLM initiator A system component might be both initiator and target A SystemC module might be both a TLM initiator and target A system transaction might be built from a sequence of several TLM transactions

29

Notations
sc_port a small square with an

arrow leaving it

Channel an arrow at a module

with no small square

sc_export a small square with

an arrow entering it

Thread

30

Comparisons of sc_export and sc_port

sc_port

Declare interfaces required at a module boundary sc_port<IF> of a module requires that interface from the outside
sc_export

Declare interfaces provided at a module boundary sc_export<IF> of a module provides that interface to the outside

31

sc_export
Improve speed by reducing the number of threads
channel (IF1, IF2) sc_port<IF1> sc_port<IF2> sc_port<IF>

IF sc_export<IF>

32

sc_export (c. 1)
Allow sc_ports to connect to more than one implementation of the

same interface in the same top level block

virtual RSP transport( const REQ & ) = 0;

virtual RSP transport( const REQ &) = 0;

B1 sc_export<IF> sc_port<IF>

B2 sc_export<IF> sc_port<IF>

Port Declarations tlm_export<REQ, RSP> first(port 1); tlm_export<REQ, RSP> second(port 2); Port Bindings first(B1); second(B2);

33

sc_export (c. 2)
Allow a different transport function for each protocol
tlm_transport_if<REQ1,RSP1> virtual RSP1 transport( const REQ1 & ) = 0; tlm_transport_if<REQ2,RSP2> virtual RSP2 transport( const REQ2 &) = 0;

IF1

IF2

sc_export<IF1> sc_port<IF1>

sc_export<IF2> sc_port<IF2>

Port Declarations tlm_export<REQ1, RSP1> first( port 1 ); tlm_export<REQ2, RSP2> second( port 2 ); Port Bindings first(this); second(this);

34

sc_export (c. 2)
A thread in a low level sub module inside an initiator directly calls

a method in low level sub module in a target

sc_port to sc_export

sc_export to sc_interface binding

sc_port to sc_port

sc_export to sc_export

35

Improve Reusability
Channels/sc_export offering more than actually required by

sc_port are still Plug Compatible [Lecture pp18-19]

C++ implicit conversions to base classes

Having a hierarchy of interfaces is the key to enable this feature

Require the most minimal interfaces for a given situation
Use sc_port<tlm_nonblocking_get_if<T> > rather than sc_port<tlm_get_if<T> >

Provide the maximal interfaces for a given situation

Use sc_export<tlm_get_if<T> > rather than sc_export<tlm_blocking_get_if<T> >

Appendix

36

37

Call-by-Value v.s. Call-by-Reference

Call-by-Value
void Two(int x) { x = 2; cout << x <<endl; } void One() { int y = 1; Two(y); cout << y <<endl; } Results: 2 1 } Results: 2 2 } void One() { int y = 1; Two(y); cout << y <<endl;

Call-by-Reference
void Two(int& x) { x = 2; cout << x <<endl;

38

Miscellaneous
Reference v.s. Pointers
http://en.wikipedia.org/wiki/Reference_(C++)#Syntax_and_terminology