Skip to content
STIMSMITH

Discrete Event Simulation

Technique

Discrete event simulation, in the provided verification context, is the simulator mechanism used to synchronize UVM-style testbench tasks and processes by scheduling events and runnable tasks. The evidence describes an event simulator as having a Scheduler that manages event queues and a Task Executor that runs triggered tasks, with cooperative threading, yielding, context switching, and possible multicore task execution.

First seen 5/25/2026
Last seen 5/25/2026
Evidence 2 chunks
Wiki v1

WIKI

Overview

Discrete event simulation is described in the evidence as the mechanism required by the UVM base class library to synchronize testbench tasks and processes. In the eUVM implementation, the discrete-event simulator schedules testbench-related tasks and events and is broadly partitioned into a Scheduler and a Task Executor. [C1]

The scheduler manages event queues and schedules triggered tasks for execution. In a single-threaded simulator, the task executor runs runnable tasks sequentially on one CPU thread of the host machine. [C2]

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections
eUVM ← uses 100% 1e
eUVM implements its own discrete-event simulator to schedule testbench tasks and events.

CITATIONS

11 sources
11 citations — click to expand
[1] C1: UVM needs a discrete event simulator for synchronization, and eUVM implements one partitioned into a Scheduler and Task Executor. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[2] C2: The scheduler manages event queues and schedules triggered tasks; in a single-threaded simulator, the task executor runs runnable tasks sequentially on one CPU thread. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[3] C3: The eUVM scheduler model includes immediate events, delta events, runnable process queues, simulation-time increments, and timed-event checks. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[4] C4: In UVM testbenches, tasks include run phases, sequence body methods, and spawned forks, and most simulators implement these tasks as cooperative user threads. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[5] C5: Blocking calls such as start_item or finish_item can cause simulation control to move to another component, after which the sequence task yields and later wakes after item_done notification. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[6] C6: When a cooperative task yields, it relinquishes the CPU thread and saves state such as call stack and CPU registers so it can resume later. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[7] C7: Context switching is simulator runtime overhead and performance can be optimized by reducing simulation events. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[8] C8: A multicore simulator can use multiple task executors, each with its own CPU thread, with synchronization barriers to keep them synchronized with the scheduler. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[9] C9: Scheduler parallelization may have limited benefit because few active events and processes exist at a given simulation time; the scheduler is sequential and synchronization barriers add overhead. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[10] C10: Amdahl’s Law is used to explain that total performance improvement is limited by the fraction of time the optimized part is used. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings
[11] C11: Multicore gains may occur for compute-intensive tasks such as sequence randomization, and eUVM maps each UVM agent to a separate CPU thread to distribute sequence randomization. [PDF] Crafting a Million Instructions/Sec RISCV-DV - DVCon Proceedings