DEV Community: WIOWIZ Technologies

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

WIOWIZ Technologies — Sun, 16 Aug 2026 04:26:42 +0000

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

WIOWIZ FSimX Studio : How FSimX Decides When Compiled Execution Is Safe

WIOWIZ Technologies — Sun, 16 Aug 2026 04:22:05 +0000

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

WIOWIZ FSimX Studio : An Assertion That Wasn't Evaluated Did Not Pass

WIOWIZ Technologies — Sun, 16 Aug 2026 04:09:16 +0000

An Assertion That Wasn’t Evaluated Did Not Pass

A green simulation log is meaningless if the property you depended on was never evaluated.

Concurrent SystemVerilog assertions contain some of the most valuable checks in a verification environment.

Consider this property:

property req_ack;
  @(posedge clk)
    req |-> ##[1:3] ack;
endproperty

assert property (req_ack);

It requires an acknowledgement to arrive one to three cycles after a request.

If a simulator cannot lower the cycle-delay range, it has three choices:

Reject the property
Warn and skip it
Silently skip it

Only the first choice is safe by default.

If the simulation continues without evaluating the assertion, a clean run may look like a pass even though the intended behaviour was never checked.

Use a planted failure as proof of evaluation

A reliable assertion test should include a negative control:

Many valid handshakes
+
One deliberate violation

The planted failure proves that the property is active.

If the simulator reports an all-pass result, the next question should be:

Did the property genuinely pass, or was it never evaluated?

A pass count without an evaluated count cannot answer that question.

Track the complete assertion lifecycle

FSimX separates assertion activity into five categories:

evaluated — lowered, armed and checked
skipped   — parsed but not evaluated
passed    — substantive successful evaluations
failed    — detected violations
vacuous   — antecedent never triggered

The verdict policy is intentionally strict:

skipped > 0 → PASS is forbidden
failed  > 0 → Run exits non-zero

A skipped assertion remains unproven. It cannot contribute to a successful verdict.

Vacuous is not the same as passed

Consider:

req |-> ##1 ack

If req never becomes true, the assertion may be vacuously satisfied. No violation occurred—but the stimulus also never exercised the behaviour.

That result can be useful diagnostically:

High vacuity
→ Antecedent rarely or never triggered
→ Stimulus may not be testing the intended scenario

Combining vacuous and substantive passes into one number would exaggerate how much behaviour was actually checked.

Make the result machine-readable

The same assertion ledger should be available to CI pipelines and reporting systems:

{
  "assertions": {
    "evaluated": 2,
    "skipped": 0,
    "passed": 815,
    "failed": 1,
    "vacuous": 0
  }
}

This allows automation to enforce the same rules as the human-readable log.

A pipeline can fail when:

assertions.skipped > 0
assertions.failed > 0

That prevents an unsupported or dropped property from disappearing inside a green build.

Compare evaluation—not parsing

Simulator capability should be measured by whether a property was executed, not merely accepted as source text.

The SVA comparison distinguishes evaluated properties from properties the tested tool versions could not compile.

Version-scoped comparison matters because assertion-language support evolves. A reproducible result should identify the exact tool release, property and workload being tested.

See the negative control and full assertion evidence

The complete WIOWIZ study includes:

The ranged-delay SVA probe
A deliberately planted violation
Version-specific simulator results
Machine-readable assertion counts
Vacuity measurements
Larger assertion workloads
Strict CI verdict behaviour

👉 Read the full study: An Assertion That Wasn’t Evaluated Did Not Pass

#systemverilog #verification #testing #semiconductor

WIOWIZ FSimX Studio : What Does Two-State Simulation Hide?

WIOWIZ Technologies — Sun, 16 Aug 2026 04:01:06 +0000

Treating every unknown as zero can make a design follow a valid-looking path that the RTL has not earned.

SystemVerilog uses four-state logic:

0 — logic low
1 — logic high
X — unknown
Z — high impedance

A two-state simulator works with only 0 and 1. This is a deliberate performance-oriented modelling choice—but it can produce a different result when the design depends on initialization, reset or unknown propagation.

Where the answers diverge

Consider an uninitialized register:

logic [7:0] state;

initial begin
  $display("%h", state);
end

A four-state simulator preserves the value as unknown:

xx

A two-state model may initialize it to:

That difference can affect:

Reset controllers
Conditional expressions
case selectors
Arithmetic operations
State-machine transitions
Chiplet link training
Watchdog completion

A state machine that sees X may take its default or error path. If the same value becomes zero, it may enter an apparently valid state and continue without revealing the initialization problem.

A changed value can change the entire run

The difference is not always limited to one signal in a waveform.

On larger workloads, the selected modelling approach can determine whether:

A link trains
A completion condition occurs
An assertion is evaluated
A watchdog expires
The testbench reaches its verdict

This is why two-state and four-state results should be understood as answers produced under different semantic models.

Two-state behaviour is not automatically a defect. The engineering decision depends on which risks the verification run is expected to expose.

Throughput is only one part of performance

Compiled two-state execution can deliver much higher sustained throughput on long, compute-bound RTL workloads.

Compiled two-state execution leads sustained cycle throughput in the measured free-running workload.

But cycle throughput does not include the full path to a result.

A simulator may spend time on:

Parsing and elaboration
→ Backend generation
→ Native compilation
→ Runtime execution

The total wall clock includes front-end work, backend build time and simulation.

For long runs, the compiled model may amortize its build cost and dominate runtime performance. For short edit-run-debug loops, time to the first simulated cycle can matter more.

Choosing the right question

The practical comparison is not simply:

Fast versus slow

It is:

Which semantics does this test require?
How quickly does the first cycle begin?
How long will the simulation run?
Could X propagation change the verdict?

For initialization-sensitive logic, reset sequencing, state machines and chiplet links, four-state behaviour may expose failures that a two-state model cannot represent.

See the measured semantic and performance results

The complete WIOWIZ study includes:

Five X-semantics checks
Four-state reference comparisons
Chiplet workloads where modelling changes completion
Sustained cycle-throughput measurements
Time-to-first-cycle analysis
FSimX’s current disclosed limitation

👉 Read the full study: What Does Two-State Simulation Hide?

#systemverilog #verification #semiconductor #performance

WIOWIZ EDA Platform

WIOWIZ Technologies — Sat, 15 Aug 2026 14:00:05 +0000

WIOWIZ EDA Suite is now live

The connected RTL frontend verification suite, in the cloud.

Lint → CDC/RDC → Formal → Simulation → Coverage → Power-Aware → Signoff
All engines talking to each other. Full tool output. No install.

What’s inside the suite:

FSiMX – RTL / GLS / UVM simulation
Truti – CDC & RDC structural analysis
Hetu-Formal – Property proofs & counterexamples
vWIZ-Coverage – Code + functional coverage
vWIZ-Wave – Waveform debug
Vajra-LP – UPF / low-power verification

Point it at your design. Every stage hands context to the next.
Private workspace. Just your work email.

👉 https://platform.wiowiz.ai

Built for teams who want a real connected flow instead of stitching tools together.

Try the suite. Tell us what you break. Your feedback helps us improve the platform and make it better for everyone.

WIOWIZ FsimX Studio - Can an Open Simulator Run a Real UVM Environment?

WIOWIZ Technologies — Tue, 11 Aug 2026 13:31:18 +0000

Can an Open Simulator Run a Real UVM Environment?

Compiling UVM headers is not the same as running a verification environment—and reaching the end of a simulation is not automatically a valid pass.

When engineers evaluate an open simulator, one of the first questions is:

Will it run our actual UVM environment?

The meaningful test is not a toy sequence. It is an environment containing:

The Accellera UVM library
Factory and class resolution
Phasing
Drivers and monitors
Sequences
Scoreboards
Register abstraction
A trustworthy end-of-test verdict

What “runs UVM” should mean

A valid UVM result needs to satisfy four conditions:

1. The environment elaborated
2. Transactions occurred
3. Checking occurred
4. The verdict reflects that work

A simulator can complete while the testbench performs no useful verification.

For example, if a scoreboard reports zero writes and zero reads, a printed PASS should be treated as suspicious—not successful.

Testing the same environment

WIOWIZ tested three open simulators against the same Accellera IEEE 1800.2-2020 UVM workloads.

The results are scoped to the exact versions used. Open-source tools evolve quickly, so broad claims such as “Tool X does not support UVM” are less useful than reproducible statements about a specific version, library and workload.

The matrix records whether each tested version produced a runnable verification result.

The workload increases in complexity:

UVM hello_world
       ↓
Bus environment with driver, monitor and scoreboard
       ↓
Full upstream RISC-V timer DV environment

Some tools may stop in the UVM library or class type system before simulation begins. That is a compile-time outcome—not a UVM execution result.

The scale test

The largest workload is a complete upstream RISC-V timer UVM DV environment.

It includes:

342 source files
653 design units
27 packages
Agents and monitors
A scoreboard
Register-abstraction infrastructure

The complete environment is elaborated into packages, instances and signals before runtime begins.

The important result is not simply that FSimX accepts the files.

The environment must elaborate, run meaningful activity, perform checks and produce an evidence-backed verdict.

Why verdict integrity matters

Two common false-positive patterns are:

PASS changes with the launch directory
PASS is reported even though the scoreboard checked nothing

The first indicates an unstable build or include-resolution problem. The second indicates that the verification environment did no measurable work.

A simulator evaluation should detect both conditions instead of presenting them as successful runs.

The takeaway

“UVM support” should not mean:

The simulator parsed some UVM source.

It should mean:

A real environment elaborated, transactions occurred, checking occurred and the verdict accurately reflected the work.

That is the standard against which FSimX and the tested simulator versions were evaluated.

👉 Read the complete comparison, commands, measured results and version-specific limitations on WIOWIZ

#systemverilog #verification #semiconductor #opensource

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

WIOWIZ Technologies — Tue, 11 Aug 2026 13:24:12 +0000

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

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.

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

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.

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

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

WIOWIZ FsimX Studio - Coverage: Power-Aware Coverage from UPF Intent

WIOWIZ Technologies — Tue, 11 Aug 2026 12:30:22 +0000

Functional Coverage Does Not Prove Your Power Intent

A low-power SoC can achieve high functional coverage without powering down a single domain.

Traditional coverage answers whether the RTL logic was exercised. It does not automatically verify the behaviour introduced by the UPF power intent.

A low-power verification plan must answer additional questions:

Did every power domain enter its required states?
Were isolation controls applied and released?
Was retained state saved and restored?
Were legal power transitions exercised?
Were illegal transitions detected?
Did the domain recover correctly after wake-up?
Were unsafe DVFS sequences prevented?

These are separate verification goals and should not be hidden inside an overall functional-coverage percentage.

Intent defines the target

Power-aware coverage requires two inputs:

UPF-derived inventory → What should be covered
Runtime event stream  → What actually happened

The UPF-derived inventory provides the denominator. It identifies the power domains, states, transitions, isolation strategies, retention groups and other power-related points expected from the design.

The simulator’s runtime events provide the hits.

Each power parameter remains an independent coverage collector with its own result.

A point is covered only when the corresponding power behaviour is observed during execution.

Power states and transitions are different questions

Entering every power state does not prove that every required transition between those states occurred.

The coverage model therefore keeps state and transition coverage separate.

State coverage      → Was OFF, ON or RETENTION entered?
Transition coverage → Was OFF → ON or ON → RETENTION exercised?

Legal edges are covered when taken. Illegal edges require negative-control semantics.

An illegal transition should not be counted like a normal coverage hit. It should count only when the test attempts it and the design correctly detects or blocks it.

If the illegal transition occurs without detection, the result is a defect—not additional coverage.

Detecting the false green

A test may be named “power-down scenario” while never driving the design into a power-down state.

If the functional test passes, a conventional dashboard may still appear green.

Power-aware scenario correlation compares the requested scenario with the power activity actually observed.

The requested scenario is checked against the states and transitions that really occurred.

If no domain turned off, no retention sequence ran and no recovery occurred, the test did not validate low-power behaviour—regardless of its name.

Keep power closure separate

Power-aware coverage should have its own gate and verdict:

PASS_POWER_AWARE_FUNCTIONAL
POWER_COVERAGE_INCOMPLETE
POWER_COVERAGE_DEFECT

It should not be averaged into code or functional coverage. Otherwise, frequently exercised logic may hide incomplete power sequencing.

The takeaway

Functional coverage asks:

Did the logic execute?

Power-aware coverage asks:

Did the design enter, survive and recover from its power states exactly as the intent required?

A low-power signoff needs both answers.

👉 Explore the complete UPF-driven power-aware coverage model on WIOWIZ

#verification #semiconductor #vlsi #lowpower

WIOWIZ FsimX Studio - Coverage: Formal Reachability and UNR Closure

WIOWIZ Technologies — Tue, 11 Aug 2026 12:23:59 +0000

Coverage Closure with Proof: Formal Reachability and UNR Analysis

An uncovered point is not automatically a verification gap. It may be unreachable—but that conclusion should be proven, not assumed.

Near the end of a verification cycle, uncovered points usually fall into different categories:

A test has not exercised the point
The point is reachable but still uncovered
The point is structurally impossible to reach
The available analysis cannot determine the answer

Treating every uncovered point the same creates unnecessary tests. Waiving them without evidence creates a different risk.

Formal reachability provides a stronger path to closure.

Three outcomes instead of two

vWIZ-Coverage combines simulation coverage with formal unreachability analysis to classify coverage points as:

COVERED
Simulation reached the point

UNREACHABLE
Formal analysis proved the point cannot occur

OPEN
The point is reachable or remains undetermined

Every uncovered point retains its formal verdict and the evidence supporting it.

Only points proven unreachable are retired from the coverage target. Reachable and undetermined points remain in the denominator and continue to count against closure.

This keeps unknowns visible instead of silently converting them into exclusions.

Refine the denominator—not the numerator

Formal analysis does not create coverage hits.

If three points are proven structurally dead, those points may leave the target denominator. The number of covered points does not increase.

Raw coverage
     ↓
Formal reachability analysis
     ↓
Proof-refined coverage

The movement from raw coverage to proof-refined coverage remains visible and traceable.

Every denominator change should be connected to formal evidence—not hidden behind a modified percentage.

Simulation evidence must win contradictions

Formal results should not be accepted blindly.

Consider this conflict:

Formal verdict : UNREACHABLE
Simulation hits: 48

A point reached during simulation cannot also be unreachable.

A reliable evidence-join process must reject the contradictory formal bundle, preserve the existing coverage database and identify the offending point.

This independent check is essential. Otherwise, formal analysis becomes another source of claims instead of an arbiter of evidence.

Proof versus waiver

A manual waiver says:

We believe this point cannot happen.

Formal reachability says:

Here is the evidence that this point cannot happen.

That difference matters during reviews, audits and signoff. Proof-refined coverage can be re-derived from the raw data, formal verdicts and exclusion history.

The takeaway

Coverage closure should distinguish between:

What simulation covered
What formal analysis proved impossible
What still remains unknown

A point should leave the coverage target only when the evidence earns that decision.

👉 Explore the complete formal reachability and UNR-closure workflow on WIOWIZ

#verification #formalverification #semiconductor #vlsi

WIOWIZ - VWIZ-COVERAGE: Code, Toggle, FSM, Expression, Covergroup and Assertion in One Database

WIOWIZ Technologies — Mon, 10 Aug 2026 15:58:12 +0000

One Coverage Database Without One Misleading Percentage

Statement, branch, toggle, FSM, functional and assertion coverage do not answer the same question. Why reduce them to one number?

A single coverage percentage looks simple—but simplicity can hide verification gaps.

If multiple coverage families are averaged together, easy-to-hit metrics may compensate for critical areas that remain untested. Even worse, a metric that was never collected may disappear from the final result.

vWIZ-Coverage keeps every metric family in one database while preserving each as a separate verification question.

One database, separate metrics

The coverage database can bring together:

Statement coverage
Branch coverage
Toggle coverage
FSM coverage
Expression coverage
Covergroups and crosses
Assertion coverage

Each family retains its own numerator, denominator and collection status.

One database feeds the dashboard, but every coverage family remains independently visible.

This prevents a high toggle score, for example, from hiding an uncovered FSM transition or an untested functional combination.

Missing is not zero—or complete

There are three very different conditions:

0% coverage    → Measured, but nothing was covered
100% coverage  → Measured, and everything was covered
Not collected  → No valid measurement exists

An unfed metric should not be silently treated as zero, full or irrelevant.

vWIZ-Coverage reports it as Not Collected, preserving the distinction between a verified result and missing evidence.

Connect coverage to the source

Summary percentages identify that a gap exists. Engineers still need to find it.

The code-coverage workspace connects statement and branch results to the source lines that produced them.

Covered and uncovered lines remain visible together in their source context.

This also keeps statement and branch coverage separate. Executing a line does not prove that every outcome of its decision was exercised.

Why this matters for signoff

A credible coverage workflow should answer four questions:

What was measured?
What was covered?
What remains open?
What was never collected?

Merging all coverage into a single percentage weakens those answers.

Keeping the families separate makes gaps visible, evidence traceable and signoff decisions easier to defend.

The takeaway

One database should create one place to investigate coverage—not one artificial number.

A green dashboard is valuable only when engineers can see exactly what contributed to it and what did not.

👉 Explore the complete vWIZ-Coverage workflow and technical evidence on WIOWIZ

#verification #semiconductor #vlsi #testing

WIOWIZ SOCVP - Compose. Boot. Repeat.

WIOWIZ Technologies — Mon, 10 Aug 2026 15:45:23 +0000

Compose. Boot. Repeat: Building a RISC-V SoC Without Local Toolchain Setup

What if exploring a new SoC configuration started with choosing the blocks—not installing and configuring tools?

Traditional SoC bring-up often begins with environment preparation:

Install a compiler and linker
Configure the build system
Define the memory map
Create register headers
Prepare firmware
Connect everything to a simulation environment

With WIOWIZ socvp, the workflow begins by selecting the components required for the system.

Compose the SoC

A project can be created from available memory, peripherals, interrupt controllers and accelerators:

bin/socvp new my-soc \
  -blocks ram,uart0,clint,timer0,plic0,npu0,cnn0

The generated output is not simply a diagram or an empty folder.

It includes:

my-soc/
├── socvp-project.yaml
├── firmware/
├── generated register headers
├── build files
└── output directories

The selected catalogue blocks become a structured project that is ready to build.

The versioned SoC contract records the selected blocks, while generated headers keep the firmware’s register names and addresses aligned with the project configuration.

Build with the packaged toolchain

The compiler and linker are included inside the socvp package.

bin/socvp build my-soc

The build does not depend on a separately installed host compiler. This makes the environment more portable and helps different machines build against the same fixed toolchain.

Boot the composed system

The resulting project can be booted using the same workflow as the packaged systems:

bin/socvp boot my-soc

The objective is not merely to generate an architecture. The composed project must execute firmware and produce a checked result.

Modify and repeat

Engineers can update the generated firmware, rebuild the project and inspect it in Studio:

bin/socvp build my-soc
bin/socvp studio my-soc

This creates a compact exploration loop:

Choose blocks
     ↓
Generate project
     ↓
Build firmware
     ↓
Boot and check
     ↓
Modify and repeat

The takeaway

A composition tool should deliver more than a block diagram.

It should turn selected components into a firmware project that can be built, booted and evaluated—without making the first experiment wait for a lengthy host setup.

👉 Explore the complete “Compose. Boot. Repeat.” workflow on WIOWIZ

#riscv #semiconductor #soc #embedded

WIOWIZ - Wave: Protocol Transaction and Memory Viewers for Debug

WIOWIZ Technologies — Mon, 10 Aug 2026 15:39:24 +0000

Beyond Raw Waveforms: Protocol Transaction and Memory Debugging with vWIZ-Wave

Signals show what toggled. Engineers still need to understand what happened—and where the resulting data came from.

Raw waveforms are essential for RTL debugging, but they are often the slowest way to investigate a system-level failure.

In a complex SoC:

Requests and completions may be separated by many cycles
Multiple transactions may be interleaved
Signal names may repeat across different instances
A corrupted memory value may appear long after the write that caused it

Manually connecting these events can mean scrolling through thousands of transitions.

Decode signals into transactions

The vWIZ-Wave Protocol Transaction Viewer converts recorded signal activity into meaningful operations.

A decoded transaction can contain:

Start and end time
Address and direction
Request and completion
Payload and status
Scoped source instance

The decoded PCIe transaction remains connected to the exact waveform interval that produced it.

Selecting a transaction moves the waveform directly to the corresponding interval. Engineers can inspect the higher-level operation and the underlying signal evidence without manually rebuilding the transaction.

This approach can support protocol debugging across interfaces such as PCIe, I²C, SPI and UART.

Reconstruct memory with write provenance

Finding an incorrect value is only the beginning. The important question is:

Which write produced it?

The vWIZ-Wave Memory Viewer reconstructs memory contents at the active cursor using recorded writes and available reset information.

Each reconstructed memory value retains a link to the write event that produced it.

A selected cell can guide the engineer back through the evidence:

Incorrect value
       ↓
Producing write
       ↓
Protocol transaction
       ↓
Source instance
       ↓
Raw waveform interval

Why this shortens debugging

The symptom may appear during a processor read, while the cause occurred much earlier during a bus transfer.

Connecting protocol transactions, memory state, hierarchy and waveforms to one cursor creates a more direct route from symptom to source.

The viewers do not replace raw signals or invent missing state. They organize the evidence already captured by the run and make its meaning easier to follow.

The takeaway

Waveforms tell you what changed.

Protocol and memory viewers help explain what the change meant, which block caused it, and where to continue debugging.

👉 Explore the complete vWIZ-Wave protocol transaction and memory-viewer workflow on WIOWIZ

#semiconductor #vlsi #verification #debugging