Simulation environments
Build a testbench that predicts the right answer, detects mismatches, and makes each run easy to inspect.
How the check works
Drive the design. Compare its answer.
Apply inputs
Directed and random tests exercise the block.
Predict and observe
A reference model predicts the answer; the testbench reads the design output.
Compare results
Mismatches fail the test. Coverage records which scenarios ran.
Concept illustration. A passing simulation checks the scenarios that ran. It does not prove every possible input sequence.
What you receive
- The testbench, its build files, and run logs.
- A report of the checked scenarios, with coverage where supported.
- A results summary your regression can read.
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.
Problem, approach, and required inputs
The problem
A testbench that only drives inputs will pass while whole classes of behaviour go unchecked. Without a model of the right answer and a record of what was covered, a green run tells you very little.
What we do
We build a cocotb or UVM testbench with a reference model that predicts the right answer, directed and random stimulus, and automatic checking. The simulator, supported coverage features, and required scenario counts are agreed before work starts.
Inputs agreed after scoping and NDA
- The block and its interfaces.
- A specification or interface description of the expected behaviour.
Related public demonstration
Public demonstration, not a client result
A Python testbench that checks itself
A reference model, random stimulus, and a coverage count per operation.
Technical details
How the result is checked
Runs retain logs and the supported scenario or coverage reports. The cocotb example records operation counts. The executed UVM example checks scoreboard transactions; its Verilator run does not collect class covergroup coverage.
Tools used for this kind of work
- cocotb
- UVM
- Verilator
- Icarus Verilog
Scripts are handed over as agreed in the scope. 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