Blank-file testbenches.
Weeks of drivers, monitors and scoreboards before the first real test runs.
AI verification for chip teams
Find the bug before silicon does.
Akrida reads your spec, writes and runs the UVM testbench, triages every failure, and files real design bugs with the log and waveform attached.
Now onboarding a small group of design partners.
Example: Akrida reads requirement REQ-WR-2, writes a UVM testbench, finds a WSTRB bug in simulation, triages it as a design bug and files an issue.
- Writes SystemVerilog UVM
- Runs on Verilator
- Files to GitHub Issues
The problem
Verification is where tape-outs slip.
Every block starts with a blank testbench. The spec lives in a PDF, the tests in a repo, the failures in a log, and the bugs in a tracker that doesn't know which requirement they broke.
14%
Only 14% of chip projects got first silicon right in 2024, down from 32% in 2020.
Source: Siemens EDA and Wilson Research Group, 2024 IC/ASIC Functional Verification Trend Report
Failures without answers.
A red regression could be the design or the testbench. Someone has to dig through the log to find out.
Context in five places.
Spec, tests, runs and bugs live in different tools, so nobody can say which requirements are actually covered.
How it works
From spec to filed bug, without the blank file.
-
01
Read the spec.
Akrida turns your block's spec into testable requirements and a verification plan you can review.
plan.md
REQ-WR-2 Partial writes honor WSTRB per byte lane
check: byte-lane reference model; read back after every partial write
-
02
Build the testbench.
It writes a SystemVerilog UVM environment (sequences, driver, monitor, scoreboard) on hand-verified protocol agents.
tb_v1.sv
class axil_env extends uvm_env; axil_agent agent; axil_scoreboard sb; axil_coverage cov; -
03
Run and triage.
It simulates, closes coverage gaps with new tests, and decides for every failure whether the design or its own testbench is wrong.
triage
design bug REQ-WR-2 · rdata mismatch
testbench bug fixed by Akrida, rerun
-
04
File and track.
Real bugs become GitHub issues with the failing test, log, waveform and broken requirement, closed automatically when the fix passes.
github issue
WSTRB ignored on partial writes
filedfix pushedrerun passes, closed
You review the plan and the bugs. Akrida does the rest.
The platform
One place for design and verification.
Testbench generation is where Akrida starts. The platform is what keeps your team on the same page from the first spec to tape-out.
Block workspace.
Each block gets a home: its spec, verification plan, testbench, runs and bugs, with a timeline of every RTL commit.
Spec-to-test traceability.
Every requirement links to the tests that cover it and the bugs that break it. See what's verified, and what isn't, at a glance.
Closed-loop bug lifecycle.
Bugs are filed to GitHub Issues automatically, deduplicated across runs, closed when the fix passes, and reopened if they come back.
Commit-to-regression bisect.
When a test starts failing, Akrida bisects your RTL history and points to the commit that broke it.
Shared dashboard.
Designers, DV engineers and leads see the same status: coverage by block, open bugs, and what changed since yesterday.
Benchmark
Measured, not promised.
We inject real bugs into open-source RTL and race Akrida against a frontier AI model given the same spec. Same designs, same bugs, same simulator.
Why Akrida
Not a chatbot that writes Verilog.
A general-purpose assistant can draft a testbench. It can't run it, can't tell you whether the failure is real, and forgets everything by the next commit. Akrida is built for the whole loop.
General AI assistant Akrida
Writes testbench codeWrites it, compiles it, and runs it
Leaves you to read the failing logTriages each failure: design bug or testbench bug
Starts from scratch every chatKeeps every run, bug and requirement for the block
Hands you textFiles the issue, links the requirement, closes it when fixed
Guesses at protocolsBuilds on hand-verified protocol agents
Who it's for
Built for the people who sign off on silicon.
DV
DV engineers.
Skip the scaffolding and spend your time on the corner cases only you would think of.
RTL
Design engineers.
Get tests against the spec as soon as RTL compiles, and see exactly which commit broke what.
LEAD
Verification leads.
Know what's covered, what's open and what's risky, per block, without a status meeting.
Your RTL is your crown jewels.
We know. Tell us how your team handles IP and we'll walk through deployment options on the demo call.
FAQ
Questions DV teams ask us.
Does Akrida replace my DV team?
No. It takes the repetitive work off their plate: scaffolding, rerunning, reading logs, filing bugs. Your engineers review the plan, own the hard cases and sign off.
What does Akrida need from me?
A spec for the block and access to the RTL. Akrida writes the tests from the spec, not from the RTL, so the tests check what the design is supposed to do.
Can I read and edit the testbench it writes?
Yes. It's standard SystemVerilog UVM. Edit it, check it in, run it in your own flow.
How does it tell a design bug from a testbench bug?
For each failure it checks the expected behavior against the spec, the waveform and its own testbench code. When the testbench is wrong it fixes it and reruns. When the design is wrong it files the bug with the evidence.
Which simulators and protocols does it support?
Verilator today, with standard bus protocols such as AXI4-Lite. Commercial simulators are on the roadmap. Tell us what you use on the demo call.
Where does my RTL go?
Let's talk about it on the call. We'll fit the deployment to how your team handles IP.
What does it cost?
Design partners work with us directly on pricing during the pilot.
Design partners
Put Akrida on your next block.
We're taking on a small group of design partners: chip teams who want an AI verification engineer on a real block and a direct line to the founders. Bring a spec and we'll show you Akrida verifying it.
Or email us at founders@tryakrida.com
Thanks, we'll be in touch.
One of the founders will email you to set up your demo.