Lecture7 Part I

7/29/2019 Lecture7 Part I

1/38

1

Lecture 7 TLM API 1.0 inLecture 7 TLM API 1.0 inSystemCSystemCPart IPart I

Multimedia Architecture and Processing Laboratory

Prof. Wen-Hsiao Peng ()

[email protected]

2007 Spring Term


2/38

2

ReferenceReference

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 TLMStandard Whitepaper: Transaction Level Modeling in SystemC,

http://www.systemc.org S. Swan, A Tutorial Introduction to the SystemC TLM Standard,

Cadence Design Systems, March 2006


3/38

3

TLM API 1.0TLM API 1.0

What does TLM API 1.0 provide?

Define core interfaces and standard channels for communicationUsers 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


4/38

4

High Level GoalsHigh 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


5/38

5

General StrategyGeneral Strategy

Establish a fundamental set of TLM interfaces

Core interfaces Unidirectional interfaces - send data in one direction

tlm_put_if, tlm_get_if, tlm_peek_if

Bidirectional interfaces - send data in both directions

tlm_transport_if

tlm_maser_if, tlm_slave_if

Standard channels

tlm_fifo, tlm_req_rsp_channel tlm_transport_channel


6/38

6

Communication TypesCommunication 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 ofbidirectional or unidirectional transfers

A complex bus with address, control and data phases may looklike a simple bidirectional read/write bus at a high level ofabstraction, but more like a sequence of pipelined unidirectionaltransfers at a more detailed level


7/38

7

Interface StylesInterface 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 &)


8/38

8

Interface Styles (c. 1)Interface Styles (c. 1)

Effectively Pass-by-Value data transfer

//blocking write of sc_fifotemplate inline void sc_fifo::write( const T&val_ )

{while( num_free() == 0 )

sc_core::wait( m_data_read_event );m_num_written ++;buf_write( val_ );request_update();

}

template inline bool sc_fifo::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;

}

Call by Reference

Call by Reference

Pass by Value


9/38

9

Interface Styles (c. 2)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


10/38

10

Core InterfacesCore Interfaces


11/38

11

Core InterfacesCore Interfaces

Developed based on sc_fifo interface

Primary unidirectional interfaces tlm_put_if (blocking+non-blocking)

tlm_get_if (blocking+non-blocking)

tlm_peek_if (blocking+non-blocking)

Primary bidirectional interface

tlm_transport_if (blocking)

Channel specific bidirectional interfaces

tlm_master_if (blocking+non-blocking)

tlm_slave_if (blocking+non-blocking)

Useful for tlm_req_rsp_channel and tlm_transport_channel


12/38

12

Key TermsKey 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/38

13

Key Terms (c. 1)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/38

14

Hierarchy of Core InterfacesHierarchy of Core Interfaces

[3]

tlm_master/slave_if


15/38

15

Unidirectional InterfacesUnidirectional Interfaces

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 = 0 ) const = 0;

virtual const sc_event &ok_to_get( tlm_tag *t = 0 ) const = 0;};


class tlm_blocking_get_if :


{

public:

virtual T get( tlm_tag *t = 0 ) = 0;

virtual void get( T &t ) { t = get(); }

};

tlm_nonblocking_get_iftlm_blocking_get_if

tlm_get_if


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 = 0 ) const = 0;

virtual const sc_event &ok_to_put( tlm_tag *t = 0 ) const = 0;

};


class tlm_blocking_put_if :

public virtual sc_interface{

public:

virtual void put( const T &t ) = 0;

};

tlm_nonblocking_put_iftlm_blocking_put_if

tlm_put_if


16/38

16

Unidirectional Interfaces (c. 1)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

class tlm_nonblocking_peek_if :


{

public:

virtual bool nb_peek( T &t ) = 0;

virtual bool nb_can_peek( tlm_tag *t = 0 ) const = 0;

virtual const sc_event &ok_to_peek( tlm_tag *t = 0 ) const = 0;

};


class tlm_blocking_peek_if :


{

public:

virtual T peek( tlm_tag *t = 0 ) = 0;

virtual void peek( T &t ) { t = peek(); }

};

tlm_nonblocking_peek_iftlm_blocking_peek_if

tlm_peek_if


17/38

17

Examples of Unidirectional InterfacesExamples of Unidirectional Interfaces

Polling-based usage

Interrupt-based usage


18/38

18

Examples of Bidirectional InterfacesExamples of Bidirectional Interfaces

Model transactions with a tight 1-to-1, non pipelined bindingbetween 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/38

19

Examples of Bidirectional Interfaces (c. 1)Examples of Bidirectional Interfaces (c. 1)

template < typename REQ , typename RSP >

class tlm_slave_if :

public virtual tlm_put_if< RSP > ,

public virtual tlm_get_peek_if< REQ > {};

template < typename REQ , typename RSP >

class tlm_master_if :

public virtual tlm_put_if< REQ > ,

public virtual tlm_get_peek_if< RSP > {};

tlm_slave_iftlm_master_if

tlm_master_if and tlm_slave_if


20/38

20

Hardware ImplicationHardware Implication

[3]


21/38

21

Standard ChannelsStandard Channels


22/38

22

RemarksRemarks

Users can and should design their own channels implementingsome 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 directlyimplemented in a target when used to provide fast programmers

view models for software prototyping


23/38

23

ttlm_fifolm_fifo

Implement all the unidirectional TLM interfaces based on sc_fifo

Support request_update/update mechanism

Support fifo size of 0 and infinite


24/38

24

tlm_req_rsp_channeltlm_req_rsp_channel

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/38

25

tlm_transport_channeltlm_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;

}


26/38

26

Background InformationBackground Information


27/38

27

Key TermsKey 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/38

28

Key Terms (c. 2)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 TLMtransactions

29


29/38

29

NotationsNotations

sc_port a small square with anarrow leaving it

sc_export a small square withan arrow entering it

Channel an arrow at a modulewith no small square

Thread

30


30/38

30

Comparisons ofComparisons ofsc_exportsc_exportandandsc_portsc_port

sc_port

Declare interfaces required at a module boundary

sc_port of a module requires that interface from the outside

sc_export

Declare interfaces provided at a module boundary

sc_export of a module provides that interface to the outside

31


31/38

31

sc_exportsc_export

Improve speed by reducing the number of threads

sc_port sc_port

channel(IF1, IF2)

sc_port sc_export

IF

32


32/38

32

sc_exportsc_export(c. 1)(c. 1)

Allow sc_ports to connect to more than one implementation of thesame interface in the same top level block

sc_port sc_port

B1 B2

sc_export sc_export

virtual RSP transport( const REQ & ) = 0; virtual RSP transport( const REQ &) = 0;

Port Declarationstlm_export first(port 1);

tlm_export second(port 2);

Port Bindings

first(B1);second(B2);

33


33/38

33


Allow a different transport function for each protocol

sc_port sc_port

IF1 IF2

sc_export sc_export

tlm_transport_if

virtual RSP1 transport( const REQ1 & ) = 0;

tlm_transport_if

virtual RSP2 transport( const REQ2 &) = 0;

Port Declarationstlm_export first( port 1 );

tlm_export second( port 2 );

Port Bindingsfirst(this);

second(this);

34


34/38

34


A thread in a low level sub module inside an initiator directly callsa method in low level sub module in a target

sc_port to sc_port sc_export to sc_export

sc_port to sc_export sc_export to sc_interfacebinding

35


35/38

35

Improve ReusabilityImprove Reusability

Channels/sc_export offering more than actually required bysc_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 rather than sc_port

Provide the maximal interfaces for a given situation Use sc_export rather than sc_export


36/38

36

AppendixAppendix

37


37/38

CallCall--byby--ValueValuev.sv.s. Call. Call--byby--ReferenceReference

Call-by-Value

void Two(int x)

{

x = 2;

cout


38/38

MiscellaneousMiscellaneous

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

Documents

Lecture7 Part I