DEV Community

Cover image for WIOWIZ FsimX Studio - Why FsimX Built Its Own SystemVerilog Front End
WIOWIZ Technologies
WIOWIZ Technologies

Posted on

WIOWIZ FsimX Studio - Why FsimX Built Its Own SystemVerilog Front End

Why FSimX Built Its Own SystemVerilog Front End

Parsing SystemVerilog is only the beginning. A simulator must turn that source into an executable design.

FSimX did not begin with a native SystemVerilog front end. Its original architecture used Slang for parsing—and Slang performed that job well.

The limitation was not parsing quality. It was what FSimX needed to control after parsing:

SystemVerilog source
        ↓
Parsing
        ↓
Lowering
        ↓
Elaboration
        ↓
Simulator-owned IR
        ↓
Runtime execution
Enter fullscreen mode Exit fullscreen mode

Full-chip gate-level timing and complete UVM environments both depend on the lower half of this pipeline.

A syntax tree is not an executable design

A parser can confirm that the source is grammatically valid and produce a syntax tree.

A simulator must also resolve:

  • Parameterized module instances
  • Generate-block specialization
  • Signal widths and connectivity
  • Type and scope relationships
  • Class hierarchies and factories
  • Timing paths
  • Runtime processes

For example, a module written once may become hundreds of concrete instances, each with different parameters and connections.

Only elaboration turns the source description into that complete hierarchy.

FSimX elaboration scale across WIOWIZ design hierarchies

The native front end produces the instances, signals and processes consumed by the simulator runtime.

Why gate-level timing needs IR ownership

SDF back-annotation does not attach delays to source tokens.

The timing data must resolve against:

  • Elaborated cell instances
  • Concrete interconnect paths
  • Lowered specify paths
  • Runtime delay objects
fsxrun -sv -sdf design.sdf -top tb
Enter fullscreen mode Exit fullscreen mode

For an annotated delay to fire correctly, the simulator must own an intermediate representation where the target path can be located and updated.

That requirement pushed FSimX beyond a parsing-layer integration.

Why UVM created the same requirement

A UVM environment adds another kind of elaboration:

  • Class inheritance
  • Factory resolution
  • Component hierarchy
  • Sequences
  • Register abstraction
  • Simulation phases

These relationships must be built before simulation time begins.

Full UVM DV environment elaborated by the FSimX native front end

The environment is elaborated as packages, design units, instances and signals—not merely accepted as source files.

Although gate-level timing and UVM appear to be different workloads, both require the same architectural capability: control over how SystemVerilog becomes an executable model.

What the decision enabled

Owning the front end gave FSimX one design model that downstream features can share:

Elaborated hierarchy
├── Runtime execution
├── SDF timing
├── Four-state values
├── Coverage
├── Assertions
└── UVM scheduling
Enter fullscreen mode Exit fullscreen mode

This was not about building another parser for its own sake.

It was about owning the lowering, elaboration and IR required by the simulator.

The takeaway

Parsing answers:

Is this SystemVerilog source valid?

Elaboration answers:

What concrete hardware and verification environment does it create?

For linting or lightweight source analysis, parsing may be enough.

For chip-scale timing, UVM and simulation, the executable design begins after parsing.

👉 Read the complete engineering rationale, benchmarks and current limitations on WIOWIZ


#systemverilog #verification #semiconductor #programming

Top comments (0)