The TLM DAC

46daclogoThe past few days here at DAC, a big theme has been transaction level modeling (TLM).

TLM is often considered to be SystemC TLM-2.0. Most of the statements from the EDA companies are to the effect that SystemC TLM-2.0 solves the problem of combining models from different sources. Scratching the surface of this happy picture, it is clear that it is not that simple…

The issue is that even if all agree on using the TLM-2.0 standard and its default standard generic memory-mapped bus protocol and payload for the memory-map part of their device models, there are other interfaces which are not standard at this point in time.

For example, there is no standard way to model interrupts between devices. So any time you have interrupts in a system (which tends to be always), you need to write custom wrappers between modules to convert different ways of modeling interrupts. Even worse, the standard way to do it is to use SystemC signals, which are definitely not TLM abstractions. They take a detour through the SystemC kernel, which is quite costly.

The defining property (from a simulation execution perspective) of TLM is that your simulation modules talk directly to each other through direct function calls, rather than passing over whatever simulation kernel you happen to be using. Essentially, TLM tends to convert simulators into being much more like “regular programs”, with fewer references to the simulation kernel and its event and time handling. In my world, unless you are doing direct function calls, you are not doing TLM.

Note that this state of things in the SystemC world is likely to change for the better over time. GreenSocs announced at DAC that they are working with Virtutech and an unnamed other partner to create a set of TLM interfaces for other interconnects, such as signals (interrupts under another name), serial, and Ethernet.

But apart from all the technicalities of SystemC TLM-2.0 and how it works, the big question is just what to use TLM for, and how. Here, everyone seems to try to turn TLM into their own use cases. The most obvious application is doing fast virtual platforms, but you also have TLM use as the basis for hardware synthesis, validation, golden reference models, architectural exploration, and pretty much all other EDA design tasks.

Even so, the most important message for me is that the EDA industry is actually starting to get interesting in TLM. It is no longer a quaint odd thing done by some peripheral start-up companies, but rather a mainstream technology that everyone has to pay attention to.

Finally, I want to point out that TLM is not just SystemC. TLM is a general idea that has been in active use since the late 1960s. It is the obvious way to model a computer, if all you are concerned about is how it looks to the software. Another current example is the Simics style of TLM (and here), which is similar to but different in details from the SystemC implementation.

5 thoughts on “The TLM DAC”

  1. thanks Mr. Jakob,

    i really have one question..

    what is the difference between the memory mapped bus und the non-memory mapped bus? can you give me an example for each?

    thanks a lot..

  2. I guess that is a good question.

    A memory-mapped bus, as I see it, is some kind of bus/network/switch/other interconnect in the hardware that takes memory transactions from a source such as a processor or DMA engine, and delivers them to a recipient based on the address in the transaction.

    A memory transaction minimally can be described by its address, value, size, and type (read or write).

    A non-memory-mapped bus are not very common in virtual platforms, but I guess you could call something like the CAN bus a non-memory-mapped bus. Or maybe USB and other interconnects that do not directly have memory transactions as their logical interface to the system.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.