TLM Modeling Techniques

TLM modeling techniques
Acknowledgments:
•F. Ghenassia (Ed.). ”Transaction-level Modeling with SystemC”,
Springer, 2005
•Transaction Level Modeling in SystemC (white paper)
• Updated TLM Proposal (March 2004)
• TLM WG Update (June, 2007)
• www.doulos.com

Communication via sc_port

sc_export
It is a new type of port introduced with SytemC 2.1
Like sc_port, its declaration is defined on an interface
It is different from sc_port
– sc_export is used to implement the channel inside a module and
still make it accessible from the outside

Communication via sc_export
TLM relies both on sc_port and sc_export

2005 2006 2007
2008
- TLM 1.0 provides some low-level interfaces for transaction-level
communication
- put, get, nb_put, nb_get, transport
- such interfaces are included in TLM-2.0
- TLM 2.0-draft1 and TLM2.0-draft2 extend TLM1.0 by introducing
- the nb_transport
- a generic payload + extensions (for memory-mapped bus
modeling)

Key concepts in TLM
TLM focuses on proposing a communication standard
and is based on SystemC
Particular emphasis on
– Blocking vs. non blocking
– Bidirectional vs. unidirectional
– Interfaces. They are the real key to TLM: the goal is to define a
small set of generic, reusable interfaces

Blocking vs. non blocking
Contains wait(.) –
OSCI Terminology process is Can be called from
suspended
Blocking Possibly SC_THREAD only
Non Blocking No
SC_METHOD or
SC_THREAD

Unidirectional vs. bidirectional
Unidirectional interfaces send data in only a single
direction
Bidirectional interfaces send data in both directions
Examples:
– A complete read transaction across the bus is bidirectional
– Send IP packet is unidirectional
Any complex protocol can be broken down into a set of
unidirectional and bidirectional accesses that use the
TLM API (Application Programming Interface)

Unidirectional interfaces
Based on the sc_fifo interfaces as in SystemC 2.1
Further split into:
– Unidirectional blocking interfaces
– Unidirectional non blocking interfaces
A transaction from initiator to target is called put
A transaction from target to initiator is called get
A non consuming interface that reads the most recent
valid value is peek
These interfaces can be implemented in a fifo, some
other channel, or directly in the target by using sc_export

Unidirectional blocking interfaces
They never fail
because they
are blocking

- TLM 2.0 does not support either of these coding styles

Unidirectional non blocking interfaces
They may fail
because they are
non blocking

Bidirectional blocking interface
It models transactions with a tight one-to-one binding
between request going in and response coming out
Typically used in PV
– A read can be seen as an address going in and the read data
coming out
It can be considered a merger between the blocking get
and put functions

Summary for core TLM interfaces

Core TLM channels
tlm_fifo
– It implements all the unidirectional interfaces mentioned before
– It is based on sc_fifo
– a transaction put into the tlm_fifo is not available for getting until
the next delta cycle (request-update / update scheme)
– It can be zero or infinite sized

Core TLM channels (cont’ed)
tlm_req_rsp_channel
– It consists of two fifos
one for the request going from initiator to target
one for the response being moved from target to initiator
– Direct access to these fifos is provided as follows:
the put request and get response interfaces are exported to the initiator
the get request and put response interfaces are exported to the target
– This has been all grouped into master & slave interfaces

Core TLM channels (cont’ed)
tlm_transport_channel
– used to model situations in which each request is tightly bound to
one response
– Because of this tight one to one binding, the request and
response fifos must be of size one
– It directly exports the same interfaces exported by
tlm_req_rsp_channel

Modeling API
API (Application Programming Interface)
– It is a set of procedures available to the programmer and able to
provide an abstraction that hides the underlying hardware
When modeling API, 3 levels are distinguished
– Core TLM interface layer
It is the layer upon which TLM protocols and IPs can be developed
These are the interfaces provided by the TLM Library
– Protocol layer
– IP layer

TLM layered approach for API

API: TLM Protocol layer - overview
Various communication protocols can be defined on the
top of the TLM interface layer
These protocols rely fully on the core TLM interface to
transfer a transaction between two different points
For each TLM protocol, a set of methods is defined
(convenience functions)

API: defining a TLM protocol
To create a new protocol, the following is needed:
1. A suitable TLM interface must be chosen
2. The protocol between initiator and target is defined for:
Exchanged information
Protocol interface

Choosing the right interface for a TLM protocol
It depends on the protocol to be implemented
In a design, more than one protocol can be implemented
Each protocol can either be uni- or bidirectional
– Bidirectional: it uses blocking bidirectional interface
Request is a parameter of the function call
Response is the return value of the function call
– Unidirectional: it uses either blocking or non blocking
unidirectional interface
Examples:
Initiators send requests and get responses
Targets get requests and send responses
– Untimed TLM protocol can be
Bidirectional: if it is based on the read/write
Unidirectional: if it broadcasts a transaction without waiting for any response
– Timed TLM protocol is usually unidirectional, as it implements
timing notions

API: IP layer
TLM IPs are modeled on top of a TLM protocol layer as
functional modules
Communication between TLM IPs are done through the
communication API defined in the protocol interface

Initiator port
An initiator is a TLM module implementing one or more
processes, which can generate transactions to the
channel module
An initiator is always modeled as a SystemC module:
– It declares processes to model its behavior
– It instantiates one or more ports to be bound to the
communication channel
A process inside an initiator starts communication by:
– Employing the convenient functions of the protocol interface in
the initiator port

Target modeling
A target is a TLM module modeled by implementing a
SystemC module that takes charge of the IP behavior
– Model IP behavior at the functional level without any microarchitectural
details
– Implement the TLM interface