Skip to content
STIMSMITH

Transaction Level Modeling

Technique WIKI v1 · 5/26/2026

Transaction Level Modeling (TLM) is described in the provided evidence as relying on temporal decoupling of data from simulation time and events. The evidence highlights limitations of SystemVerilog for TLM-style execution and shows how UVM/eUVM TLM FIFOs are used to exchange transaction data between synchronous simulator tasks and asynchronous worker threads.

Overview

Transaction Level Modeling (TLM) is a verification and modeling technique whose essential requirement, in the provided evidence, is temporal decoupling: transaction data should be decoupled from simulation time and events. This characteristic is contrasted with SystemVerilog behavior, where integral variables and expressions implicitly carry value-change events, enabling constructs such as wait(a > b) and thereby tying data values to event semantics. [C1]

SystemVerilog implications

The evidence states that SystemVerilog lacks support for TLM at a fundamental level because TLM requires temporal decoupling of data from simulation time and events, while SystemVerilog integral variables and expressions implicitly hold value-change events. The same source reports that computational algorithms coded in SystemVerilog execute an order of magnitude slower than corresponding code in C/C++ and other native programming languages. [C1]

This limitation is discussed in the context of verification testbench performance. The evidence notes that modern HDL simulators can parallelize RTL designs, but comparatively little has been done to enable multicore parallelization of testbenches. It also describes SystemVerilog/UVM testbenches as behavioral, capable of automatic data scoping, and able to share data by reference, which makes parallelism require user-level constructs for synchronized access to shared data. [C2]

TLM FIFOs in UVM and eUVM

The evidence describes UVM TLM FIFOs as the prescribed mechanism for exchanging data between asynchronous worker threads and synchronous simulator tasks while maintaining synchronization. A regular UVM TLM FIFO blocks a read operation through an explicit event in the read port when the FIFO is empty; a write into the FIFO triggers that read event and reactivates the blocked task. Similarly, when the FIFO is full, an explicit event associated with the write port blocks a write operation. [C3]

eUVM extends this pattern for asynchronous worker threads. Worker threads are described as free-running asynchronous threads owned by the simulator but decoupled from the scheduler. Because such worker threads cannot wait for simulator events, eUVM implements asynchronous TLM FIFO variants to support synchronized transaction exchange. [C4]

One described variant is an async-write TLM FIFO, used when a worker thread generates UVM transactions that must be transferred to a regular UVM task. If the FIFO is full, the worker thread is blocked by a software semaphore rather than a UVM event. When the receiving task pulls a transaction and a FIFO slot becomes available, the semaphore is freed to unblock the worker thread. If the FIFO is empty, the receiving task blocks on the regular UVM read-port event; when the worker thread puts a transaction into the FIFO, it triggers the read event and unblocks the receiver. The evidence also notes that an async-read TLM FIFO handles the reverse scenario, where a worker thread receives data from a regular UVM task. [C5]

Role in acceleration and parallel testbenches

The evidence places TLM-related mechanisms in the broader context of testbench acceleration. It mentions transaction-based acceleration for co-emulation, specifically an approach proposing an untimed hardware verification language domain for accelerating the testbench when the design under test is mapped to FPGA while the testbench continues to run on an HDL simulator. [C6]

Within multicore testbench execution, the evidence presents sequence-level parallelization and asynchronous TLM FIFOs as mechanisms that allow worker threads and regular UVM tasks to exchange transactions while respecting synchronization constraints imposed by simulator scheduling and event semantics. [C4]

CITATIONS

6 sources
6 citations
[1] C1: TLM requires temporal decoupling of data from simulation time and events, while SystemVerilog integral variables and expressions implicitly hold value-change events; the evidence reports SystemVerilog algorithms as an order of magnitude slower than corresponding C/C++ or native-language code. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[2] C2: Testbench parallelization is less developed than multicore RTL simulation, and SystemVerilog/UVM testbenches require synchronized shared-data access constructs because they are behavioral, support automatic scoping, and can share data by reference. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[3] C3: A regular UVM TLM FIFO blocks reads when empty and writes when full using explicit events associated with its ports; writes can trigger the read event to reactivate a blocked task. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[4] C4: eUVM worker threads are free-running asynchronous threads decoupled from the scheduler; because they cannot wait for simulator events, eUVM implements asynchronous TLM FIFO mechanisms for synchronized exchange with other threads. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[5] C5: An async-write TLM FIFO supports worker-thread-generated UVM transactions transferred to a regular UVM task by using a software semaphore when full and read-port event triggering when a transaction is put into an empty FIFO; async-read handles the reverse direction. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[6] C6: Transaction-based acceleration for co-emulation is described as proposing an untimed hardware verification language domain to accelerate the testbench while the design under test is mapped to FPGA and the testbench runs on an HDL simulator. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings