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