WIOWIZ Technologies

Posted on Aug 16

WIOWIZ FSimX Studio : How Fast Can a Simulator Turn RTL Into a Runnable SoC?

#systemverilog #verification #performance #semicondutor

How Fast Can a Simulator Turn RTL Into a Runnable SoC?

Parsing source files is not the same as building the design those files describe.

Before simulation begins, a SystemVerilog tool must transform source code into a connected, executable hierarchy.

That requires more than syntax checking.

What elaboration builds

Consider a parameterized module:

module fifo #(parameter WIDTH = 32) (...);

The source defines it once, but a full SoC may instantiate it many times with different parameters, widths and connections.

Elaboration must resolve:

Parameter values
Generate blocks
Module instances
Signal widths
Port connections
Processes
Class and package relationships
The complete hierarchy under the selected top

The result becomes the design model used by simulation, coverage, assertions and timing annotation.

SystemVerilog sources
        ↓
Parse and resolve
        ↓
Elaborate instances
        ↓
Connect signals and processes
        ↓
Runnable SoC hierarchy

Measuring the scaling curve

WIOWIZ measured the same FSimX front end and elaborator across designs ranging from a three-file testbench to a 588-file automotive SoC.

The study records:

Source files
Design units
Instances
Signals
Processes
Parse and elaboration wall time
Error count

The same pipeline is measured across small testbenches, chiplet systems, UVM environments and whole-chip designs.

The largest workload contains:

588 source files
2,673 instances
~700,000 signals
10,657 processes

FSimX parses and elaborates the hierarchy in about nine seconds, with zero compile or elaboration errors in the measured run.

Why the instance tree matters

A summary count is useful, but downstream simulation needs a navigable model.

DeepFuse is resolved into a connected hierarchy of module instances, signals and processes.

The elaborated tree establishes what the design actually builds. It distinguishes instantiated hardware from source files that merely exist in a repository.

That model is then shared by:

Four-state runtime
SVA evaluation
Coverage
UVM execution
SDF back-annotation
Waveform and hierarchy debug

Why time to the first cycle matters

RTL verification is iterative:

Edit
→ Elaborate
→ Simulate
→ Debug
→ Repeat

Even modest front-end delays become expensive when repeated throughout the day.

A responsive elaborator shortens the distance between a source-code change and the first useful simulation result.

Compare stages carefully

Simulator architectures do not always expose equivalent stages.

For FSimX:

Parse + elaborate
→ Begin simulation

A compiled simulator may use:

Analyze
→ Generate backend code
→ Build native model
→ Begin simulation

Comparing wall-clock time to the first cycle can be useful. Calling both measurements “front-end time” would be inaccurate because the pipelines perform different work.

A fair comparison should identify:

Exactly which stages are timed
Whether backend compilation is included
Whether unsupported constructs were removed
The tool version and machine configuration
Whether the resulting model is runnable

Explore the full whole-chip scaling study

The complete WIOWIZ article includes:

Six measured design points
The 588-file automotive SoC result
DeepFuse and chiplet hierarchy views
A full UVM compile-versus-elaboration measurement
Zero-error results for every reported row
The methodology caveat for first-cycle comparisons

👉 Read the full study: How Fast Can a Simulator Turn RTL Into a Runnable SoC?

#systemverilog #semiconductor #performance #verification

DEV Community