Docs

Needs Python 3.11 or newer.

If pip says externally-managed-environment (Homebrew's Python does), use pipx or a virtual environment:

Check it with akrida --version.

Akrida is invite-only for now. No invite code? Join the waitlist.

Enter your email and invite code, then the 6-digit code we email you (good for 10 minutes). Next time, only your email and a new code.

Use the email you use on this site, so checks from the terminal show up on the home page.

From a script, in two steps:

akrida whoami shows who is signed in and the runs left. akrida logout signs this machine out.

Set up your project folder once, then check the design:

The spec: a .pdf, .md or .txt file, up to 10 MB. The Verilog (optional): .v, .sv, .vh and .svh files, folders or globs, up to 512 KB in all. Without it you still get the test plan and the testbench. Akrida finds the top module, or asks if it can't tell.

Flags on akrida run override akrida.toml for one run. akrida status shows the settings, your sign-in and the latest check.

Checks run in Akrida's cloud, so you don't need a simulator. The terminal shows each step and a link to follow the check here. Ctrl+C stops following, not the check: akrida run --resume CHECK_ID picks it up again (the first 8 characters of the id are enough).

Every file is saved in your project as the check goes, in .akrida/checks/DESIGN-ID/: each plan revision, the testbench, logs, waveforms, coverage, and check.json (what was checked and how far it got). akrida pull CHECK_ID fetches them later, for example for a check started on this site.

When the check ends, we email you what it found, and your terminal rings if it is still open.

Options:

--review-plan

Stop after the test plan for your review. --no-plan skips the review. With neither, it asks.

--review-testbench

Stop after the testbench for your review. --no-testbench-review runs it straight away, the default.

--coverage 90

Coverage target, in percent. Default 100.

--max-rounds 8

Most rounds on the simulator. Default 12, up to 20.

--top fifo

The top module, when Akrida can't tell.

--name fifo_v2

A name for the check. Default: the top module, or the spec's file name.

--repo owner/name

Where design bugs become issues. See Design bugs on GitHub.

--plan testplan.md

Use this test plan instead of writing one, such as an earlier check's testplan.md.

--testbench tb.sv

Use this testbench too, with the plan it came from. Changing the plan in review writes a new one.

--no-email

No email when the check ends.

--dry-run

Keep issues in .akrida/issues, off GitHub.

--yes

Ask nothing: approve the plan and the testbench, and keep the defaults.

--json

Print only a JSON result, for scripts.

With review on, the check stops after the test plan, before any test is written. The terminal shows the requirements; you can approve, ask for changes in plain words, edit it yourself, read it in full, or stop and come back later. Each change makes a new revision that shows what changed.

Edit it yourself opens the plan in $EDITOR. What you save becomes the next revision, still waiting for your approval. No AI is involved.

The same review is on the check's page here: approve in the browser and the terminal carries on. Nothing runs while a plan waits.

With --review-testbench, or review_testbench = true in akrida.toml, the check stops again once the testbench is written, before anything runs. The terminal shows the file, its size and what changed since the revision before. You can approve it, ask a question about it, ask for changes in plain words, edit it yourself, read it, or stop and come back later.

A question, such as why a check waits two cycles, gets a short answer, and the testbench stays as it is. A change request makes a new revision, still waiting for you. A rewrite that can't run is not kept: you keep the revision you had, with a note on why.

Edit it yourself opens the testbench in $EDITOR. What you save becomes the next revision. It must keep the tb_top module and the akrida_test class. No AI is involved.

The same review is on the check's page here, with every question and its answer: approve in the browser and the terminal carries on. With --yes, the testbench is approved as written.

Connect once and each design bug becomes an issue, with the spec's rule, what should have happened, what happened, the log line and a waveform. Issues go to the --repo repository, or else the one in akrida.toml (akrida init suggests this folder's GitHub remote). To change it:

The repository must already exist. No repository yet? Create one (for example with gh repo create), add it as this folder's remote, and run akrida github repo again.

Issues are filed from your machine with your own GitHub token, which stays there: your gh auth login sign-in, GITHUB_TOKEN, or a token with the repo scope:

Without GitHub, every issue is written to .akrida/issues, ready to file yourself.

1. 1Reads the spec (a PDF becomes text) and finds the design's ports.
2. 2Writes a test plan: each rule in the spec becomes a requirement, with the scenarios that prove it.
3. 3Writes a SystemVerilog UVM testbench from the spec, the plan and the port list. With testbench review on, it waits for your approval.
4. 4Runs your design in Verilator, in rounds. A failure caused by its own test gets the test fixed; a break from the spec is a design bug. It adds tests for scenarios not reached yet, until your coverage target is met.
5. 5Reports each design bug with the spec's rule, what happened, the log line and a waveform of the ports. Every file is kept.

The AI sees only your top module's port list, never the rest of the RTL, so its tests can't copy the design's mistakes. When a test fails, the spec decides who is right. More in How it works.

Exit codes from akrida run, for CI:

0

No design bugs, and the coverage target was met. Also when there was no Verilog and the plan and testbench are ready.

1

Design bugs found.

2

No design bugs, but the coverage target wasn't met.

3

The check couldn't finish, for example the Verilog doesn't compile or you aren't signed in.

Each check, from the terminal or this site, uses one run from your invite code. Everyone signed in with the same code shares its runs. akrida whoami and the home page show how many are left.

A check that fails on our side gives its run back, for example when the AI model is down. A check you cancel, or one whose Verilog doesn't compile, still counts.

Need more runs? Email founders@tryakrida.com.

60 minutes

of work per check.

$8

of AI model use per check.

12 rounds

on the simulator by default, up to 20 with --max-rounds.

10 MB

for the spec, and 512 KB for all the Verilog together.

5 changes

and 10 questions in a testbench review.

At the time or money limit, a check writes no new tests. It finishes the round it is in and reports every design bug found so far; coverage may end below your target.

When every machine is busy, a new check waits in a queue and shows its place in line.

akrida login

Sign in.

akrida whoami

Who is signed in, runs left, and whether GitHub is connected.

akrida logout

Sign this machine out.

akrida init

Set up this folder: spec, Verilog and GitHub repository, saved in akrida.toml.

akrida run

Check a design: plan, testbench, rounds, bugs.

akrida status

This project's settings, your sign-in and the latest check.

akrida pull CHECK_ID

Bring a check's files into .akrida/checks/. No id: the latest check.

akrida plan

Write and review the test plan only. Uses a run too.

akrida runs

List your checks.

akrida open CHECK_ID

Open a check on this site.

akrida github connect

Connect GitHub so design bugs become issues. Also repo, status and disconnect.

akrida --help

Every command and option.

Questions, or something broken? Email founders@tryakrida.com with the check's link.