Skip to content
Rivoryxa Technologies

Bug reproduction and root cause

We investigate a bug report, work to reproduce the failure, and check a proposed fix against the same requirement.

How the check works

The same check follows the bug through the fix.

A magnifying lens isolates a fault in a logic path. An interrupted trace is compared with a corrected trace and a rerun arrow.
  1. Reproduce the failure

    Find an input sequence that exposes the reported behaviour.

  2. Explain the cause

    Trace the failure back to the responsible logic.

  3. Check the fix

    Apply the same check to the revised design.

Concept illustration. If the failure does not reproduce, the result records the checks, assumptions, and remaining unknowns.

What you receive

  • A reproducing test or counterexample trace when the failure can be reproduced.
  • A cause analysis with supporting evidence and remaining unknowns.
  • The result of checking the same requirement on the fixed revision, when available.
  • If the failure does not reproduce, a record of the checks, assumptions, and remaining unknowns.

When this is useful

  • A failure appears in a long regression or on an FPGA, but not in a short test.
  • A fix went in and nobody can show the original failure is gone.
  • Two teams disagree about whether a report is a real design bug.
Problem, approach, and required inputs

The problem

You have a failure report but cannot make the failure happen reliably. Without a reliable replay, nobody can confirm the cause or show that a fix really works.

What we do

We express the expected behaviour as a test or property and investigate the reported revision. If a violating sequence is found, we use it to isolate the cause and check the same requirement on the revised design. Tool limits or incomplete assumptions may leave the result unresolved; the report records those limits.

Inputs agreed after scoping and NDA

  • The failure report and available logs.
  • Access to the RTL revision it was seen on, under NDA.
  • The proposed fixed revision, if available.

Related public demonstration

Public demonstration, not a client result

From a missed timer interrupt to a verified fix

A RISC-V machine timer with a seeded bug, taken from failing test to counterexample, root cause, proven fix, and closed coverage holes.

Technical details

How the result is checked

The trace can be inspected in a compatible waveform viewer. The property and the run scripts are included, so your team can replay the failure and repeat the check on the fix.

Tools used for this kind of work

  • SymbiYosys
  • Yosys
  • Verilator
  • SystemVerilog Assertions

Scripts are handed over as agreed in the scope. Properties are standard SystemVerilog Assertions and can be adapted to a commercial tool. If we have not tested your simulator or flow, the scope says so.

Discuss this problem.

Tell us what you are trying to verify and what is blocking you. A person replies, and the scope comes back in writing after a call.

Discuss a verification problem