Overview
Asynchronous worker threads are described in eUVM as free-running asynchronous threads owned by the simulator hierarchy. They are introduced as part of a sequence-level parallelization approach intended to exploit multicore concurrency in comparatively simple module-level UVM testbenches, including cases with only a limited number of UVM components. [Worker-thread definition]
Unlike regular simulator tasks, a worker thread is decoupled from the scheduler: it keeps running even when the scheduler activates. A direct consequence is that a worker thread cannot wait for a simulator event, although it can trigger events. [Scheduler decoupling]
Motivation
The technique is intended to parallelize UVM sequence activity by moving work into free-running worker threads. The cited eUVM example describes worker thread constructs that parallelize a UVM sequencer by creating multiple free-running worker threads that feed a virtual sequencer in round-robin order. This is presented as useful when transaction generation and randomization are complex or time-consuming enough to choke RTL simulation. [Sequencer parallelization]
Communication model
Worker threads share memory with simulator tasks, but UVM requires data exchange to occur through TLM FIFOs for synchronization. A normal UVM TLM FIFO blocks reads with a read-port event when empty and blocks writes with a write-port event when full; writes trigger the read event and reads free write-side progress when space becomes available. [TLM FIFO behavior]
Because worker threads cannot wait on simulator events, eUVM provides asynchronous TLM FIFO variants to synchronize worker-thread communication. These FIFOs combine regular UVM events, where used by synchronous tasks, with software semaphores, where blocking is needed on the worker-thread side. [Async FIFO need]
FIFO variants
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. 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 creates space, the pull method releases the semaphore, unblocking the worker thread. If the FIFO is empty, the receiver blocks on the regular UVM read-port event; when the worker thread puts a transaction into the FIFO, it triggers that read event and unblocks the receiver. [Async write FIFO]
Async read TLM FIFO
An async read TLM FIFO handles the reverse direction: a worker thread receives data from a regular UVM task. [Async read FIFO]
Fully asynchronous read/write TLM FIFO
For exchanges between two asynchronous worker threads, eUVM implements a completely asynchronous TLM FIFO. In this design, semaphores replace guard events at both the read and write ports. [Fully async FIFO]
Relationship to distributed communication
The cited source compares eUVM asynchronous FIFO constructs functionally to IPC channels used in a distributed sequencer. However, eUVM uses shared-memory parallelization semantics: a transaction or transaction handle generated on one CPU thread can be shared with other threads without IPC, packing/unpacking, or DPI overhead. The source states that this reduces coding effort for IPC/DPI constructs and makes handoff time between threads minuscule compared with a testbench architecture that uses inter-process communication. [Shared-memory communication]
Appropriate use cases and limits
The worker-thread approach is framed as useful when transaction generation and randomization are expensive enough for parallelization gains to outweigh communication overhead. The source cautions that asynchronous TLM FIFO reads and writes introduce overhead, which can offset gains for simple transactions with naive constraints and fast randomization. [Use-case limits]