Overview
TLM Fifo Asynchronous Communication is a technique described for eUVM multicore verification environments. It addresses how free-running asynchronous worker threads exchange transaction data with regular scheduler-controlled UVM tasks, while preserving synchronization through TLM FIFOs. In eUVM, worker threads are hierarchically owned by the simulator but are decoupled from the scheduler; they keep running when the scheduler activates, cannot wait for simulator events, and can trigger events. [worker_threads_in_euvm]
Although worker threads share memory with simulator tasks, the cited source states that UVM requires data exchange through TLM FIFOs to maintain synchronization across threads. [data_exchange_via_tlm_fifos]
Baseline: synchronous UVM TLM FIFO behavior
A conventional UVM TLM FIFO uses explicit events at its read and write ports. If the FIFO is empty, a read operation blocks on a read-port event; a write operation later triggers that event and reactivates the blocked task. If the FIFO is full, a write operation blocks on a write-port event. [synchronous_tlm_fifo_behavior]
This event-based mechanism does not directly work for asynchronous worker threads, because such threads cannot wait for simulator events. eUVM therefore introduces asynchronous TLM FIFO variants that use software semaphores on asynchronous sides of the communication. [async_need_and_variants]
Asynchronous FIFO variants
The source describes three asynchronous TLM FIFO architectures in eUVM, corresponding to three communication scenarios. [async_need_and_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 by a UVM event. When the receiving task pulls a transaction and creates a free slot, the pull method frees the semaphore and unblocks the worker thread. If the FIFO is empty, the receiving task still blocks on the regular UVM read event; when the worker thread puts a transaction into the FIFO, it triggers the read event and unblocks the synchronous receiver. [async_write_fifo]
Async read TLM FIFO
An async read TLM FIFO handles the reverse scenario: a worker thread receives data from a regular UVM task. [async_read_fifo]
Fully asynchronous read/write TLM FIFO
A completely asynchronous TLM FIFO supports data exchange between two asynchronous worker threads. In this architecture, semaphores replace the guard events at both the read and write ports. [fully_async_fifo]
Role in parallel testbench execution
The asynchronous FIFO constructs are presented as serving a role similar to IPC channels in a distributed sequencer, but 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 cited source states that this reduces coding effort for IPC/DPI constructs and makes handoff time very small compared with an architecture using inter-process communication. [shared_memory_vs_ipc]
The technique is used in the context of sequence-level parallelization and worker-thread based transaction generation. Worker threads can feed a virtual sequencer, for example in a round-robin scheme, which may help when transaction generation and randomization are complex and time-consuming enough to choke RTL simulation. [sequence_level_parallelization]
Applicability and limitation
The cited source cautions that the parallelization scenarios using asynchronous TLM FIFO reads and writes are useful when transaction generation and randomization take substantial time. For simple transactions with naive constraints and fast randomization, the overhead of exchanging data over asynchronous TLM FIFO reads and writes can offset the benefit. [overhead_limitation]