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

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

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

A four-state simulator preserves the value as unknown:

xx

A two-state model may initialize it to:

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

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.

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

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

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?

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