Skip to content
Rivoryxa Technologies

Find the right check for your design.

Choose the part of verification that is holding you up. Explore the scope and deliverables for each service below.

RISC-V

Check architectural behaviour, debug, interrupts, and the assumptions behind the result.

RISC-V verification

Turn an architectural requirement or failure report into checks your team can inspect and rerun.

When this is useful

  • A RISC-V subsystem behaves differently from the requirement or reference model.
  • An interrupt or control sequence needs a short, reproducible test.
  • You need evidence for a specific processor integration question.
View the full service

RISC-V architectural tests (ACT4)

Compare your core against architectural expectations, with a result for every test in the agreed matrix.

When this is useful

  • You need architectural test results for a named RISC-V core configuration.
  • An ACT4 run fails and the source of the mismatch is unclear.
  • You need to repeat the same architectural checks after an RTL change.
View the full service

Debug, interrupt, and exception verification

Check how the controller handles a debug halt, an interrupt request, or an exception.

When this is useful

  • Debug entry and interrupts arrive close together.
  • Single step or return from debug behaves unexpectedly.
  • A controller change needs a focused regression around debug, interrupts, or exception priority.
View the full service

Coverage

Investigate design behaviour your tests have not reached.

Coverage closure

Find out why coverage has stalled, with a test, proof, or supported waiver for each resolved item.

When this is useful

  • Coverage has stalled short of the target and more random runs do not move it.
  • A sign off review is coming and the waiver list has no evidence behind it.
  • Nobody is sure whether some holes can be reached at all.
View the full service

Correctness

Check expected behaviour and document the result.

Bug reproduction and root cause

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

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.
View the full service

Formal verification and SVA

Check the rules your block must satisfy, including scenarios simulation may miss.

When this is useful

  • Control logic, an arbiter, or a protocol state machine keeps producing late bugs.
  • A formal run passes but nobody can say what it actually checked.
  • You want the same checks to keep running in your regression.
View the full service

Simulation environments

Build a testbench that predicts the right answer, detects mismatches, and makes each run easy to inspect.

When this is useful

  • A new block needs a testbench and the team has no time to build one.
  • The current testbench checks too little to trust a pass.
  • You want tests that run on free simulators in continuous integration.
View the full service

Verification automation

Run agreed verification jobs, collect their evidence, and keep missing or failed checks visible.

When this is useful

  • Regression runs rely on manual setup and log inspection.
  • Results need to be traced to the exact source and configuration.
  • Missing tools, timeouts, or incomplete reports are difficult to distinguish from design failures.
View the full service

Data across clocks

Check the logic that moves data between independent clocks.

Asynchronous FIFO verification

Check for lost, duplicated, or reordered data as it moves between independent clocks.

When this is useful

  • A design adds a FIFO or handshake between two clock domains.
  • An intermittent data error appears only on hardware.
  • A CDC review needs checks that keep running in regression.
View the full service

Agree the scope. Then start the work.

We define the inputs, deliverables, and completion criteria together before work begins.

See the engagement process

Not sure where your problem fits?

A short description is enough to start. We will clarify the scope before any confidential project material is shared.

Discuss a verification problem