The TLM 2.0 transaction level modeling standard from the Open SystemC Initiative (OSCI) was released on 9th June 2008. Transaction-level modeling (TLM) is a high-level modern approach to modeling digital systems. That modeling is based on the abstraction of the communications between different parts of the model to allow to work the algorithms of each module, and on the other hand to work the communications between modules. Buses, FIFOs and other communication mechanisms are modeled as channels, and are presented to modules using SystemC interface classes in this techniques.
Transaction requests take place by calling interface functions of these channel models, which encapsulate low-level details of the information exchange. At the transaction level, the emphasis is more on the functionality of the communication model and less on their actual implementation. The technique improves the overall speed of the design being modeled and makes it easier for the designer to experiment on models with different bus architectures using common interfaces.
The application of TLM is not specific to the SystemC. It is an approach that can be used with other languages as well.
Some basic constructs of TLM 2.0 include:
Initiators and Targets:
An initiator is a module which starts a new transaction in TLM 2.0. A target module is there which responds to the transactions initiated. Transaction is nothing but a data structure passed between initiator and target function calls. The same module could be both an initiator and target as in the case of a router or duplex bus.
Sockets:
Sockets are used to pass transactions between Initiators and Targets. Both initiator and targets have their sockets which are connected in TLM when the transaction is need to be made. A device called interconnect component is present which contains the sockets of both initiator and target. The interconnect just forwards the transaction without making any changes to it.
Generic Payload:
tlm_generic_payload is the default transaction type for socket classes. Generic payload is an important part of TLM 2.0 as it helps in achieving interoperability between TLM models. It is used for generalized transactions like memory mapping when the exact bus details/protocols used for transaction are not important. It can be used to model a wide range of protocols due to its general/open nature. Many specific protocols are built over this general payload which are later easier to connect as they are built over the same payload type.
A generic payload has a specific set of attributes like command, data, byte enables, streaming width, response status and other DMI(Direct Memory Interfacing) extensions which are explained in detail below.
The generic payload supports 2 commands : read & write.
The address attribute points to the lowest address value to which data needs to be written to or read from.
The data pointer attribute points to a data buffer within the initiator, and the data length attribute gives the length of the data array in bytes.
The streaming width attribute specifies the width of a streaming burst where the address repeats itself. For a non-streaming transaction, the streaming width should equal the data length.
The byte enable pointer is self-explanatory. There is a byte enable length attribute as well.
The response status should always be initialized to TLM_INCOMPLETE_RESPONSE. The response status will be set by the target.
Another attribute is array of extensions.
Keep following VLSIFacts for further constructs and updates on TLM 2.0. 🙂