RTL verification for semiconductor and RISC-V teams
Know what failed. Know what to do next.
We investigate RTL failures, close defined coverage gaps, and build checks for your design. Start with one problem and an agreed result.
Where we help
Start with what is blocking your team.
Choose the problem closest to yours. Open the service for its full scope and deliverables.
RISC-V
Coverage
Correctness
Data across clocks
RISC-V verification
Turn an architectural requirement or failure report into checks your team can inspect and rerun.
- 01
Define the rule
Identify the required behaviour and its configuration or software assumptions.
- 02
Exercise the RTL
Use tests or properties to expose a violating sequence.
- 03
Hand over the evidence
Record the result, proposed correction, and remaining limits.
Concept illustration
What you receive
- A test plan tied to the agreed architectural requirement.
- Reproduction scripts, run settings, and evidence for observed failures.
- Checks of the proposed correction and any remaining unknowns.
Public examples you can rerun
A halt request lost between states.
A controller fault can cause a brief request to halt to be lost at a state transition. In this public demonstration, ordinary tests pass, but targeted timing checks expose deliberately introduced faults in a real RISC-V controller.
Real upstream controller. Synthetic faults. Module-level scope and assumptions are recorded.
- 01
Establish the baseline
Run the ordinary checks on the original controller and each seeded variant.
- 02
Test the boundary
Move the request around the transition and check which event the controller services.
- 03
Isolate the failure
Confirm the cause, check nearby timing scenarios, and preserve the source, logs, and instructions needed to repeat the checks.
What comes back to you
An answer your team can work with.
A sample investigation handover.
The finding
What the checks established, any identified cause, and what remains open.
The evidence
The agreed tests, properties, logs, and traces behind the conclusion.
The handover
Run instructions, assumptions, and limits so your team can continue the work.
Working together
Start with one defined problem.
Bring one failing test, unexplained result, or coverage gap. We review feasibility and agree what to investigate before work begins. Confidential project material is shared only after an NDA and an agreed exchange process.
- 01
Describe the blocker
Describe the design and issue using only non confidential context.
- 02
Agree the work
Inputs, deliverables, access, and completion criteria in writing.
- 03
Review the result
Walk through the findings and rerun the agreed checks in your environment.
Bring us the verification problem that is holding up your team.
Share the problem in a few lines. We will discuss the scope before any confidential project material changes hands.
Discuss a verification problem