One Engine, No Knobs: How FSimX Decides When Compiled Execution Is Safe

Performance optimization should not require users to choose between two simulation flows and hope they produce the same result.

Simulators that offer compiled execution often expose it as a separate mode:

simulator --interpreted design
simulator --compiled design

That pushes a difficult decision onto the engineer:

Is the faster path correct for this design?

FSimX presents one user-facing flow. Internally, it selects interpreted or compiled execution for each eligible process—but only after a parity gate accepts the compiled result.

Keep the interpreter as the oracle

The interpreter is treated as the correctness baseline.

For a candidate process, FSimX compares compiled and interpreted execution at defined checkpoints:

Candidate process
       ↓
Run both execution paths
       ↓
Hash the signal-state snapshot
       ↓
Compare checkpoint sequences
       ↓
Match → Accept compiled execution
Mismatch → Fall back to interpreter

The state hash uses the observable signal-state snapshot. If the compiled and interpreted paths produce different hash sequences, the optimization is blocked.

This is a strong differential check, not a mathematical proof of equivalence. The claim is deliberately narrower: compiled execution is used only where the tested state remains in parity with the interpreter.

Prevent a vacuous parity result

A comparison can appear successful if the optimized path was never meaningfully exercised.

The parity gate therefore needs more than a matching hash. It must also establish that:

• A candidate process genuinely compiled
• The compiled path executed
• Named fallback behavior was exercised
• Reverting the optimization produces a detectable difference
• Both paths reached the same accepted state

This prevents “nothing compiled” from being misreported as compiled correctness.

Fall back instead of guessing

Not every process is currently suitable for compiled execution.

A process may:

• Use procedural behavior the compiler does not yet lower
• Contain unsupported operations
• Be too small to amortize compilation overhead
• Fail the parity comparison

In those cases, FSimX automatically uses the interpreter.

Eligible and equivalent → Compiled path
Unsupported or divergent → Interpreter

The user does not maintain separate scripts, results or debugging flows.

Where compiled execution helps

On processes with sufficient work, compiled execution can outperform interpretation. On smaller processes—or when every candidate falls back—the compile attempt may add overhead without improving runtime.

The interpreter remains the correctness floor; eligible processes move to compiled execution only after parity acceptance.

Publishing both wins and fallback cases matters. “Compiled” is not automatically faster if nothing meaningful reaches the compiled tier.

What controls the default transition

The interpreter remains the shipping default today. The compiled path handles accepted processes internally.

Moving to compiled-by-default is tied to a measurable product condition:

Interpreter fallback count
on the reference full chip
              ↓
Must reach zero

Even after that transition, the interpreter remains available internally as the correctness oracle.

See the parity gate, performance results and current limits

The complete WIOWIZ study covers:

• Checkpoint-by-checkpoint state-hash parity
• Non-vacuity controls
• Automatic interpreter fallback
• Full-chip compiled-process results
• A workload where compilation currently provides no win
• The metric governing the default transition

👉 Read the full study: How FSimX Decides When Compiled Execution Is Safe

#systemverilog #performance #verification #semiconductor