TLM in SystemC

2.4.3.1 User-defined Channels in SystemC 2.0

In the version 1.0 of SystemC, the library contained only low-level constructs, and could hardly be used to model communication at a higher level than RTL.

Starting from version 2.0, SystemC allows user-defined communication channels. The mechanism is the following:

User−defined class inherits is a template with argument sc interface

user interface

SystemC class

user implementation user port

sc port base

sc port<user interface,N>

sc port b<user interface>

Figure 2.8: Inheritance Diagram for User-Defined Communication Channels

SystemC defines the abstract classsc_interfacefrom which the user can derive his own interface, and implementation. The user-defined interface is a contract between the modules and the channel (see figure2.8).

It also defines the classessc_port_base,sc_port_b<>andsc_port<>, and lets the user derive his own port fromsc_port<user if, N>,user ifbeing the user-defined interface, andNthe maximum number of channels that can be bound to this port. The user-defined port exports some functions to the module containing it, which are mainly wrappers around the functions of the interface of the channel.

The SystemC primitive channel sc_signal and the corresponding ports are a good exam-ple of channel built using this mechanism. It defines the interfaces sc_signal_in_if<> and sc_signal_inout_if<>defining in particular the methodsread()for the first one, and in addition write()for the second one. Those interfaces are implemented among others insc_signal<>. The

32/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy

2.4. SystemC and the TLM API

corresponding ports,sc_inandsc_inoutdefine the same methods, which are trivial wrappers around the methods of the interface. For example, thesc_in<data_type>::read()method is defined by

const data_type& read() const { return (*this)->read(); }

(the operator->has been overloaded to return the interface bound to the port).

2.4.3.2 The TLM interface

The System Platform Group team of STMicroelectronics proposed a common interface for several TLM protocols. The interface itself, calledtlm_ifcontains only one function:

virtual tlm_status transport(tlm_transaction& transaction) = 0;

The role of the transportmethod is to route a transaction from an initiator module to a target module. The corresponding moduletlm_portis defined with the appropriate binding methods.

At this level, a transaction only contains a pointer to the initiator and target ports, a pointer to the data and one to the meta-data (the data will be used to carry the actual data that will circulate on the bus, the meta-data will typically be used to carry information about the success or failure of the transaction). Both the data and the meta-data are empty classes that will be derived in protocol implementation.

This is of course insufficient to actually write a TLM model. This interface, with the associated guide-lines, give only the common ground. Real protocols will be layered on top of it. The user of the protocols will only see the protocols, but not the TLM interface itself.

Later, this proposal has been reviewed, improved, and finally standardized by the Open SystemC Con-sortium Initiative. One of the changes is that the TLM interface is now a template:

template<REQ, RSP>

class tlm_transport_if : public sc_interface { public:

virtual RSP transport(const REQ&) = 0;

};

In [RSP⁺05], the standard is presented, and some guidelines are given to build protocols on top of this interface. The protocols presented below correspond to the former proposal, and are being re-written to use the version of the OSCI standard.

2.4.3.3 TheBASICprotocol

The BASICprotocol was designed as an example of protocol that can be implemented using the TLM interface. It was implemented by STMicroelectronics and is actually not used for production by any-one. It defines two modes of transactions: READandWRITE. The transaction data contains the mode, an address and a piece of data. The address is of typeunsigned long, and the data is an array of unsigned long(it can contain a block of data instead of a single piece of data).

The transaction is routed according to an address map specified in a separate configuration file. The BASICprotocol is implemented in two flavors: thebasic_routeris a highly available channel. Trans-actions are served as they arrive, in parallel in the case of concurrent accesses. Thebasic_arbiter, on the other hand, serializes the transactions and applies a simple arbitration policy to serve the most prioritized transactions first.

2.4.3.4 TheTACProtocol

The TACprotocol is an extension of the BASICprotocol. UnlikeBASIC, it is intended to be used in production. Its features are a superset of the functionalities ofBASIC. It should contain all the necessary, and only the necessary to model a SoC at the PV level, and therefore enable software development and

Matthieu Moy Ph.D Thesis 33/190

Chapter 2. Modeling Systems-on-a-Chip at the Transaction Level in SystemC

platform verification. It was designed and implemented by the SPG team of STMicroelectronics, and is widely used internally.

The first addition ofTACcompared toBASICis the fact thatTACchannels are C++ templates on the addresses and data-type. This is mandatory to allow bit-accurate modeling as well as flexibility.

TACalso models some features of some bus protocols that could hardly be built on top of a simple READ/WRITEinterface. It is possible to sendLOCK/UNLOCKcommands to the channel itself. The seman-tics is the following:

• When the channel receives a transaction of modeLOCK, it becomes locked;

• When the channel receives a transaction of mode other thanLOCK, with the optionLOCK ACCESS set, the channel processes the transaction normally, and becomes locked afterwards.

• When the channel is locked and receives a transaction, the transaction is queued, even if there are no other transactions pending,

• The channel will be released by the next non-locking transaction.

Another addition ofTACcompared toBASICis the ability to consider only a subset of the bytes of the transaction. For example, on a 32-bits wide bus, an initiator may want to write a single byte in memory.

This is called byte-enable. InTAC, this is just an additional information in the transaction that can be set by the initiator, and taken into account by the target.

2.4.3.5 Standardization of a Generic Channel

The TAC protocol relies on open standard, but is not a standard itself. STMicroelectronics whishes it to become a standard, for at least two reasons:

• We need a standard to be able to exchange IP blocks at the TLM level, without the need for protocol adapters.

• We prefer the standard to be our proposal, since we are already using it and supporting it. It would allow us to stay in advance compared to our concurrents.

The standardization process has not begun, yet, but some candidates are already there: the TAC proto-col, the Generic User Bus from GreenSoCs¹, and probably others in the future.

2.4.3.6 Didactic Example of Model Using theTACProtocol

The following example (see Figure2.9) will be used later to illustrate the extraction of the semantics of a SystemC model. It is voluntarily minimalist, and for clarity, we only show the body of the processes, and the methods called to process transactions in the target modules. The system contains two initiator modules and two target modules. They are connected through atac seqchannel. The program contains assertionsfor some properties we will prove (or falsify) later (chapters6and8).

Take the example of the statement port.write(address, &x) in the module status_initiator. We are going to follow the transaction sent by this statement step by step:

2.4.3.6.1 Build the transaction, transmit it to the channel. The process calls the methodwriteon the port of the module. The port will create a transaction of modeWRITE, with the addressaddressand the datax. The transaction is then passed to the member functiontransportof the channel.

2.4.3.6.2 Wait for channel availability. Since the channel is atac_seq, it will not serve the transac-tion if it is already either locked or serving another transactransac-tion. If the channel is busy, the transactransac-tion will be queued, and it will be woken up when the previous transaction finishes.

2.4.3.6.3 Resolve addresses. The channel has loaded its addressmap from the fileCHANNEL.map dur-ing the elaboration phase. The file contains:

1http://www.greensocs.com/projects-gub.html

34/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy