Skip to content
STIMSMITH

Async TLM FIFO

Concept WIKI v1 · 5/24/2026

**Async TLM FIFO** is an eUVM synchronization and communication construct used to exchange UVM transactions between asynchronous worker threads and regular scheduler-controlled UVM tasks. It extends the behavior of a conventional UVM TLM FIFO by replacing one or both simulator-event guards with software semaphores, allowing free-running worker threads—which cannot wait on simulator events—to participate in transaction transfer safely.[^c021309a]

Async TLM FIFO

Async TLM FIFO is an eUVM synchronization and communication construct used to exchange UVM transactions between asynchronous worker threads and regular scheduler-controlled UVM tasks. It extends the behavior of a conventional UVM TLM FIFO by replacing one or both simulator-event guards with software semaphores, allowing free-running worker threads—which cannot wait on simulator events—to participate in transaction transfer safely.[1]

Context

In eUVM, worker threads are free-running asynchronous threads hierarchically owned by the simulator. They are decoupled from the simulator scheduler and continue running even when the scheduler becomes active.[1] Because of this decoupling, a worker thread cannot wait for a simulator event, although it can trigger events.[1]

UVM data exchange between such worker threads and synchronous simulator tasks is required to happen through TLM FIFOs in order to preserve synchronization across threads.[1]

Conventional UVM TLM FIFO behavior

A standard, synchronous UVM TLM FIFO uses simulator events to block and unblock tasks:

  • If the FIFO is empty, a read operation blocks on an explicit event associated with the read port.
  • A write operation triggers the read event, reactivating the blocked reader.
  • If the FIFO is full, a write operation blocks on an explicit event associated with the write port.[1]

This event-based design works for regular UVM tasks, but it is not sufficient for eUVM worker threads because worker threads cannot wait for simulator events.[1]

Async TLM FIFO variants

eUVM defines three asynchronous TLM FIFO architectures to cover different producer/consumer combinations.[1]

FIFO type Producer Consumer Write-side guard Read-side guard Main use case
Async write TLM FIFO Worker thread Regular UVM task Semaphore UVM read event Worker thread generates transactions for a synchronous task
Async read TLM FIFO Regular UVM task Worker thread UVM write event Semaphore Worker thread receives transactions from a synchronous task
Async read/write TLM FIFO Worker thread Worker thread Semaphore Semaphore Data exchange between two asynchronous worker threads

Async write TLM FIFO

An async write TLM FIFO is used when a worker thread generates UVM transactions that must be transferred to a regular UVM task.[1]

Its synchronization behavior is asymmetric:

  1. If the FIFO is full, the worker thread is blocked using a software semaphore rather than a UVM event.
  2. When the receiving UVM task pulls a transaction from the FIFO, the pull method detects that a slot has become available.
  3. The pull method releases the semaphore, unblocking the waiting worker thread.
  4. If the FIFO is empty, the receiving task blocks on the regular UVM read event.
  5. When the worker thread places a transaction into the FIFO, it triggers the read event, unblocking the synchronous receiving task.[1]

This design works because the worker thread only needs to trigger the simulator event; it does not need to wait on one.[1]

Async read TLM FIFO

An async read TLM FIFO supports the reverse direction: a regular UVM task sends data to a worker thread.[1] In this architecture, the worker-thread side uses semaphore-based synchronization for reads, while the synchronous task side can still use the regular event mechanism where appropriate.

This allows a worker thread to receive transactions without needing to wait on a simulator event.[1]

Async read/write TLM FIFO

A fully asynchronous async read/write TLM FIFO is used for data exchange between two asynchronous worker threads.[2] In this variant, both the read and write guard events are replaced with semaphores.[2]

This avoids simulator-event waits entirely and allows both endpoints to be free-running worker threads.

Relationship to IPC channels

Functionally, asynchronous FIFO constructs serve a similar purpose to IPC channels used in distributed sequencer architectures.[2] However, eUVM uses shared-memory parallelization semantics: a transaction, or a handle to it, generated on one CPU thread can be shared directly with other threads without IPC, packing/unpacking, or DPI overhead.[2]

As a result:

  • Verification engineers do not need to write additional IPC or DPI-related code.
  • Data handoff between threads is much faster than in an inter-process communication model, because communication occurs through shared memory.[2]

Performance considerations

Async TLM FIFOs enable sequence-level parallelization, particularly when transaction generation and randomization are complex and time-consuming.[2] eUVM worker threads can be used to parallelize a UVM sequencer, for example by having multiple worker threads feed a virtual sequencer in round-robin fashion.[2]

However, async FIFO reads and writes introduce overhead. If transactions are simple, have naïve constraints, and randomize quickly, the overhead of exchanging data through asynchronous TLM FIFOs can offset the gains from parallelization.[2]

See also

References

[1]: Evidence c021309a-0fec-46c5-8652-609158a0b84d. [2]: Evidence 81776739-5a18-4134-89a3-0300f8bfd60e.