A parser hands you a syntax tree.
Gate-level timing at chip scale, and a full UVM environment, need an elaborated design and an intermediate representation the simulator owns.
That is what forced the architecture change.
FSimX did not start with its own SystemVerilog front end. The first version of FSimX used Slang for parsing SystemVerilog. Slang itself does much more than parse, and does the parsing job very well; our issue was not with Slang. It was that our integration used it primarily at the parsing layer, and downstream of that layer we needed ownership of lowering, elaboration and the IR the rest of the simulator would run on. For a linter or a quick analysis pass, a parsing-layer integration is enough. For a simulator that has to back-annotate gate-level timing across a whole chip and bring up a full UVM testbench, the work that matters lives past that layer, and our earlier architecture did not give us the downstream control we needed.
Two forcing functions pushed the change, from two directions: gate-level simulation with SDF back-annotation at full-chip scale, and full UVM elaboration. Both need control of how the design lowers into an IR - how a specify path becomes an annotatable delay, how a class type resolves through the factory, how a generate block specializes per instance. Owning that lowering was the change.
Where a parser stops and a chip begins
A parse tree tells you the source is well-formed. It does not resolve a parameterized instance into a concrete piece of hardware. Elaboration is the step that turns module foo #(WIDTH) u(...) written once into the many distinct instances it becomes in a full hierarchy, each with its own parameter values, its own signal widths, its own connectivity. Every downstream capability a simulator needs, timing annotation, four-state value tracking, coverage sampling, UVM phasing, reads from that elaborated model, not from the syntax tree. When the front end stops at the tree, the simulator has to reconstruct the design itself, and it inherits none of the parser's knowledge of types and scopes while doing so.
Neither of those two capabilities can be built on tokens alone. Each needs the simulator to control how the design lowers into an IR - which specify paths become annotatable delays, how a class type resolves through the factory, how a generate block specializes per instance. Owning the front end meant owning that lowering.
What it elaborates today, and how fast
The clearest way to show that the native front end is a full elaborator and not a dressed-up parser is to point it at whole chips and read the scale it reports back. The figure below is the measured elaboration profile across the WIOWIZ flagship hierarchies, taken on the shipping product binary.
DeepFuse is a WIOWIZ-original sensor-fusion SoC testbench: an image-signal-processing pipeline, a four-core compute cluster, a CNN processing-element array, radar FFT and CFAR, a fusion block, and SPI and CAN interfaces, 148 source files under one top. It exists to stress the front end and the runtime with a design that looks like a product, not a unit test. FSimX parses and elaborates it in 0.69 seconds, zero errors, first try. For calibration, Verilator takes 25.6 seconds to build a runnable model of the same testbench, and it can only do so by discarding the covergroups it cannot compile. The front end being fast is not a vanity metric here; it is what makes an interactive edit-run loop possible on a design this size.
The instance tree it produces is walkable, not a summary. That is the elaborated model the rest of the engine runs on.
The largest design we run this on is an automotive SoC measured independently downstream: 588 sources, 2,673 instances, roughly 700,000 signals, 10,657 processes, elaborated with zero compile or elaboration errors in about nine seconds. A parser can tell you those 588 files are grammatical. Only an elaborator can tell you they connect into 2,673 instances and hand that model to a timing engine.
Reason one: gate-level timing at full-chip scale
Gate-level simulation with SDF back-annotation is not a mode you bolt onto a parse tree. The delays in an SDF file attach to elaborated instances and to specify paths inside them. To apply them, the simulator has to have lowered each specify path into an object it can find by name and rewrite, and it has to have elaborated the netlist those names live in. The off-the-shelf parser produced neither. Our native lowering does: an SDF-annotated path delay resolves against the elaborated cell and fires as a delayed output write.
$ fsxrun -sv -sdf design.sdf -top tb ... SDF annotate: 1 cells matched ... 1 IOPATH delays annotated SDF applied: 2 delayed output write(s) fired result : PASS (5 ns path delay observed at the sample point)
The current edge of this, disclosed: a bare specify-block delay with no SDF annotation is not yet applied by FSimX, and the engine should say so rather than drop it silently. That gap is filed and scheduled. What works today is the industrial case - annotated gate-level timing driven from an SDF file - because the front end lowers the design into an IR the timing engine can annotate against elaborated cells. A parsing-layer integration could not produce that IR.
Reason two: a UVM testbench that elaborates all the way up
The second forcing function was UVM. A UVM environment is not RTL with extra files - it is a class library with a factory, phasing, a component hierarchy, sequences and register abstraction, and each of those requires front-end-to-IR control the parsing-layer integration did not expose. Elaborating UVM means resolving class types through the factory, building the component tree, and wiring the phase schedule before a single nanosecond of simulation runs. This is elaboration work in the class domain, and it requires the same kind of IR ownership.
The evidence is the full upstream rv_timer UVM DV environment from a widely used open-source silicon-verification suite, brought up whole: 342 files, 653 design units.
FSimX brings that environment up whole. The exact wall-clock numbers, and the failure modes of Icarus Verilog and Verilator on the same environment, are in Blog 02. The point for this article is narrower: bringing this testbench up at all is elaboration work in the class domain, and it is possible because the front end lowers classes and phases into the same IR it lowers modules into.
What the decision bought
Replacing a working parsing-layer integration is not free, and we did not do it for elegance. We did it because the two capabilities WIOWIZ needed most - full-chip SDF-annotated GLS and full UVM elaboration - both required IR ownership downstream of parsing. With the native front end, one engine elaborates a 2,673-instance automotive SoC in seconds, back-annotates SDF timing against the elaborated netlist, and stands up a 342-file UVM environment. The one still-open gap on the front-end side is the bare specify-block delay case above.
Owning the elaboration and IR is what let SDF back-annotation land at chip scale and a full UVM environment stand up. The bare-specify delay case is where the front end is not yet done.
Backing numbers
- DeepFuse: 430 instances, 21,811 signals, 1,239 processes, elaborated in 0.69 s, 0 errors
- Automotive SoC: 2,673 instances, ~700k signals, 10,657 processes, ~9 s, 0 errors
- rv_timer full UVM DV: 342 files, 653 units, TEST PASSED in 10.84 s, 3/3
- SDF path delay: annotated cell matched, delayed write fired, 5 ns observed
Run it yourself - FSiMX Studio
The native FSiMX engine described in this article ships in FSiMX Studio, a Docker bundle from the WIOWIZ website. Download it, build the image, and run the same elaboration, four-state and assertion behaviour you saw here, with vWIZ-Wave and vWIZ-Coverage in the same window.
Download FSiMX Studio on wiowiz.ai →
Our Approach
We're building systems that think about specifications the way engineers do.
We build our own in-house EDA with an intelligence layer across it. Our stack covers the full flow,
from spec to comprehensive sign-off, on tools we build and control.
Walk-in ones, walk-in zeros