DEV Community

Cover image for WIOWIZ FsimX Studio - Can an Open Simulator Run a Real UVM Environment?
WIOWIZ Technologies
WIOWIZ Technologies

Posted on

WIOWIZ FsimX Studio - Can an Open Simulator Run a Real UVM Environment?

#systemverilog #verification #semiconductor #opensource

Can an Open Simulator Run a Real UVM Environment?

Compiling UVM headers is not the same as running a verification environment—and reaching the end of a simulation is not automatically a valid pass.

When engineers evaluate an open simulator, one of the first questions is:

Will it run our actual UVM environment?

The meaningful test is not a toy sequence. It is an environment containing:

  • The Accellera UVM library
  • Factory and class resolution
  • Phasing
  • Drivers and monitors
  • Sequences
  • Scoreboards
  • Register abstraction
  • A trustworthy end-of-test verdict

What “runs UVM” should mean

A valid UVM result needs to satisfy four conditions:

1. The environment elaborated
2. Transactions occurred
3. Checking occurred
4. The verdict reflects that work
Enter fullscreen mode Exit fullscreen mode

A simulator can complete while the testbench performs no useful verification.

For example, if a scoreboard reports zero writes and zero reads, a printed PASS should be treated as suspicious—not successful.

Testing the same environment

WIOWIZ tested three open simulators against the same Accellera IEEE 1800.2-2020 UVM workloads.

The results are scoped to the exact versions used. Open-source tools evolve quickly, so broad claims such as “Tool X does not support UVM” are less useful than reproducible statements about a specific version, library and workload.

Capability matrix comparing the tested simulator versions across UVM and verification workloads

The matrix records whether each tested version produced a runnable verification result.

The workload increases in complexity:

UVM hello_world
       ↓
Bus environment with driver, monitor and scoreboard
       ↓
Full upstream RISC-V timer DV environment
Enter fullscreen mode Exit fullscreen mode

Some tools may stop in the UVM library or class type system before simulation begins. That is a compile-time outcome—not a UVM execution result.

The scale test

The largest workload is a complete upstream RISC-V timer UVM DV environment.

It includes:

  • 342 source files
  • 653 design units
  • 27 packages
  • Agents and monitors
  • A scoreboard
  • Register-abstraction infrastructure

Full RISC-V timer UVM DV environment elaborated by FSimX

The complete environment is elaborated into packages, instances and signals before runtime begins.

The important result is not simply that FSimX accepts the files.

The environment must elaborate, run meaningful activity, perform checks and produce an evidence-backed verdict.

Why verdict integrity matters

Two common false-positive patterns are:

PASS changes with the launch directory
PASS is reported even though the scoreboard checked nothing
Enter fullscreen mode Exit fullscreen mode

The first indicates an unstable build or include-resolution problem. The second indicates that the verification environment did no measurable work.

A simulator evaluation should detect both conditions instead of presenting them as successful runs.

The takeaway

“UVM support” should not mean:

The simulator parsed some UVM source.

It should mean:

A real environment elaborated, transactions occurred, checking occurred and the verdict accurately reflected the work.

That is the standard against which FSimX and the tested simulator versions were evaluated.

👉 Read the complete comparison, commands, measured results and version-specific limitations on WIOWIZ

#systemverilog #verification #semiconductor #opensource

Top comments (0)