• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Verification
  3. De-Mystifying SystemC: What is TLM?
Jack Erickson
Jack Erickson

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
High-Level Synthesis
Registers
TLM
Models
C to Silicon
transaction level modeling
SystemC
Modeling
System Design and Verification

De-Mystifying SystemC: What is TLM?

3 Feb 2011 • 2 minute read

In my last post I briefly mentioned that when designing hardware with SystemC, you do not need to allocate logic to register boundaries. And I said that was a blog post for another day.

The first step is to separate the core functionality of the block from the way it interfaces to the system. So if you were designing an MPEG decoder, the decoding algorithm would be the core functionality. If it used AXI to communicate with the system, the AXI protocol would be the interface.

You can then describe the core using purely "untimed" SystemC. This is nice because you can focus on describing and verifying the algorithm itself, not worrying about how it will be implemented to meet the spec of a particular application. If you want to add some wait() statements to represent where you know you will need latency, that's fine. But you don't need to distribute them across logic, you can just stack them. That would be a "loosely-timed" model.

The interface to the system in most cases is dependent on protocol timing. So the interface would be cycle-accurate SystemC. Yes, being cycle-accurate means that simulation will run more slowly than if it were purely untimed, but you need that amount of timing fidelity to cover a large swath of your verification plan (you do start every project with a vPlan, don't you?).  This SystemC model still runs significantly faster than verifying interfaces at the RT Level, but for another order of magnitude speedup, you can swap out the cycle-accurate interface to use a Transaction-Level Model (TLM).

TLM basically abstracts the signal-level details of a communication protocol into a function call.  This function call specifies the attributes of a payload -- the command, address, data, enables, etc. So instead of having to wiggle individual signals in the proper order, you just issue a function call to, say, read data. Using this more abstracted version simplifies design, speeds verification runs, and perhaps most importantly makes debugging waveforms much less tedious.

During synthesis, this TLM model gets refined to its corresponding signal-level model.  The advantage of SystemC as a language is that you have complete flexibility to quickly and accurately describe any complex protocol.  For commonly used bus protocols such as AXI or OCP, you can simply plug and play from a pre-verified TLM library.

Back to my previous post -- the nice thing about all this is that it is all contained in SystemC, and provided you write synthesizable SystemC, it can all be synthesized by a single tool like C-to-Silicon Compiler. So here is a case where we are partitioning the design, but this is to enable portability by separating the computation from the communication. You could describe everything in one module, but that would limit where you could use your core. And in any case, it is all one language, one synthesis flow.

What exactly is synthesizable SystemC? I think that will be my next topic.

Jack Erickson

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information