DEV Community

Cover image for WIOWIZ FSimX Studio : What Does Two-State Simulation Hide?
WIOWIZ Technologies
WIOWIZ Technologies

Posted on

WIOWIZ FSimX Studio : What Does Two-State Simulation Hide?

#systemverilog #verification #semiconductor #performance

Treating every unknown as zero can make a design follow a valid-looking path that the RTL has not earned.

SystemVerilog uses four-state logic:

0 — logic low
1 — logic high
X — unknown
Z — high impedance
Enter fullscreen mode Exit fullscreen mode

A two-state simulator works with only 0 and 1. This is a deliberate performance-oriented modelling choice—but it can produce a different result when the design depends on initialization, reset or unknown propagation.

Where the answers diverge

Consider an uninitialized register:

logic [7:0] state;

initial begin
  $display("%h", state);
end
Enter fullscreen mode Exit fullscreen mode

A four-state simulator preserves the value as unknown:

xx
Enter fullscreen mode Exit fullscreen mode

A two-state model may initialize it to:

00
Enter fullscreen mode Exit fullscreen mode

That difference can affect:

  • Reset controllers
  • Conditional expressions
  • case selectors
  • Arithmetic operations
  • State-machine transitions
  • Chiplet link training
  • Watchdog completion

A state machine that sees X may take its default or error path. If the same value becomes zero, it may enter an apparently valid state and continue without revealing the initialization problem.

A changed value can change the entire run

The difference is not always limited to one signal in a waveform.

On larger workloads, the selected modelling approach can determine whether:

A link trains
A completion condition occurs
An assertion is evaluated
A watchdog expires
The testbench reaches its verdict
Enter fullscreen mode Exit fullscreen mode

This is why two-state and four-state results should be understood as answers produced under different semantic models.

Two-state behaviour is not automatically a defect. The engineering decision depends on which risks the verification run is expected to expose.

Throughput is only one part of performance

Compiled two-state execution can deliver much higher sustained throughput on long, compute-bound RTL workloads.

Simulation throughput comparison across the tested tools and workloads

Compiled two-state execution leads sustained cycle throughput in the measured free-running workload.

But cycle throughput does not include the full path to a result.

A simulator may spend time on:

Parsing and elaboration
→ Backend generation
→ Native compilation
→ Runtime execution
Enter fullscreen mode Exit fullscreen mode

Front-end, backend-build and simulation time across flagship designs

The total wall clock includes front-end work, backend build time and simulation.

For long runs, the compiled model may amortize its build cost and dominate runtime performance. For short edit-run-debug loops, time to the first simulated cycle can matter more.

Choosing the right question

The practical comparison is not simply:

Fast versus slow
Enter fullscreen mode Exit fullscreen mode

It is:

Which semantics does this test require?
How quickly does the first cycle begin?
How long will the simulation run?
Could X propagation change the verdict?
Enter fullscreen mode Exit fullscreen mode

For initialization-sensitive logic, reset sequencing, state machines and chiplet links, four-state behaviour may expose failures that a two-state model cannot represent.

See the measured semantic and performance results

The complete WIOWIZ study includes:

  • Five X-semantics checks
  • Four-state reference comparisons
  • Chiplet workloads where modelling changes completion
  • Sustained cycle-throughput measurements
  • Time-to-first-cycle analysis
  • FSimX’s current disclosed limitation

👉 Read the full study: What Does Two-State Simulation Hide?

#systemverilog #verification #semiconductor #performance

Top comments (0)