SystemVerilog Avestra SVA

After the Webinar: Where Agentic Assertions Earn Their Keep

Simon Bennett

October 5, 2026

WATCHTOWER BRIEF · FUNCTIONAL VERIFICATION · AGENTIC AI

AiT × AVESTRA · A VIEW FROM THE WATCHTOWER

Agentic assertion generation is worth a serious look, provided you evaluate it on your own RTL, with your own reviewers, before you trust it.

IN BRIEF

What it is. Avestra Studio first analyzes a design spec against its RTL, flags inconsistencies and suggests fixes, then generates SystemVerilog Assertions, temporal domain (SVA) coverage and a coverage-driven testbench.

Who benefits. RTL designers writing assertions while intent is fresh, DV engineers building suites, and the leaders accountable for verification capacity and tape-out dates.

What it does well. Focus, shift-left spec/RTL findings with suggested fixes, deep SVA domain knowledge, reviewable output, and private-cloud deployment.

Where it falls short today. Accuracy figures are self-reported, it is digital only, and brownfield assertion ingestion is early.

How to try it. A bounded, side-by-side evaluation on one real block, scored by your own experts against criteria agreed in advance.

On September 22, Ashok Mehta, founder of Avestra and author of the reference handbook on SystemVerilog Assertions, ran a live session called Assertion-Driven Silicon Success. Before that session, our team spent several hours in product training and a technical deep dive with Ashok, working through the architecture, the generated output and the hard questions a skeptical verification lead would ask.

This post is our take from the seller's side of the table. It covers where we think the approach creates real value, who benefits, where it falls short today, and how we would try it before committing to it. For the problem itself, start with our earlier brief, SystemVerilog Assertions in the Agentic Era.

What does Avestra actually do?

Avestra Studio reads a design specification and the RTL that implements it, flags where the two disagree and suggests fixes, then produces SystemVerilog Assertions, temporal domain (SVA) coverage and a coverage-driven testbench that run in a standard simulator flow (Questa, VCS or Xcelium).

Three things separate it from pasting RTL into a chatbot

IT CHECKS THE SPEC AGAINST THE RTL AND SUGGESTS FIXES FIRST

Before generating any assertions, it finds the places where the implementation disagrees with the document and suggests fixes the designer can act on. That finding alone can be worth the run.

IT IS A PIPELINE, NOT A PROMPT

Specialized agents interpret the spec, analyze the RTL, generate properties, check for conflicts and re-loop before output is finalized.

IT DRAWS ON CURATED DOMAIN KNOWLEDGE

The knowledge base is built from Ashok's patents, his three SVA and coverage books, and his training curriculum, material a general model has not been trained on.

The point of all three is to avoid the failure modes that make raw LLM assertions dangerous: properties that are wrong, assertions that simply restate the RTL logic they are supposed to check, and vacuous passes that look green while checking nothing. Avestra reports an incorrect-assertion rate of around 1% against roughly 30% or more for general-purpose models used ad hoc. Those are Avestra's figures; we treat them as the claim to test, not the conclusion.

Who gets the value, and doing what?

The value lands with two groups of engineers and the leaders accountable for their schedules. One correction we took from Ashok early: this is not only a verification tool. Designers write assertions too, and they may get the most out of it.

RTL / ASIC / FPGA DESIGNERS

Doing: Writing a block and handing it to DV
Assertions get written at RTL time, while design intent is fresh, and the designer, the person best placed to debug a failure at its source, sees spec/RTL disagreements and suggested fixes before handoff rather than weeks into simulation.

DV ENGINEERS

Doing: Building assertion suites and closing SVA coverage on a new or changed block
A first complete, reviewable set of assertions and SVA coverage in minutes instead of days; time shifts from authoring to judging, and DV can focus on subsystem and SoC-level verification, where Avestra also generates assertions across the design hierarchy.

VERIFICATION ARCHITECTS AND PRINCIPAL DV

Doing: Owning methodology and reviewing the hardest properties
Expert practice is encoded in a repeatable flow, so it scales past the two or three people who really know SVA.

DV MANAGERS AND DIRECTORS

Doing: Staffing parallel programs against a fixed tape-out date
More throughput from the same team, and earlier visibility of spec gaps, with suggested fixes, before they slip the schedule.

VP ENGINEERING, CTO, INTERNAL AI TEAMS

Doing: Delivering on an AI-in-engineering mandate safely
A bounded, auditable use case with reviewable artifacts, deployable in a private cloud so RTL never leaves the building.

The strongest fit is digital ASIC, SoC, CPU, accelerator and networking work with heavy assertion use, real schedule pressure and senior DV talent stretched across programs. It is a weak fit for analog or mixed-signal-only programs and for teams that barely use assertions today.

What does Avestra do well?

FOCUS

Avestra does one job, spec/RTL analysis with suggested fixes followed by SVA and SVA coverage, rather than promising the whole flow. That makes it easier to evaluate and easier to slot into an existing methodology.

SHIFT-LEFT FINDINGS AND FIXES

Spec/RTL inconsistency detection, with suggested fixes, pays off before a single assertion is reviewed. A mismatch caught and corrected at handoff is far cheaper than one found during regression.

DOMAIN DEPTH, NOT JUST MODEL ACCESS

Any team can call a frontier model. Few can encode three decades of SVA methodology, curated examples and cross-checking into the workflow around it.

REVIEWABLE OUTPUT

Assertions are artifacts an engineer can read, simulate and reject. Nothing goes to sign-off unseen, which makes this a sensible first AI use case in a conservative organization.

FITS THE FLOW YOU HAVE

Output runs in your existing simulator. Nothing in the sign-off toolchain is displaced.

DEPLOYMENT OPTIONS

Private-cloud and self-hosted deployment, with a model-agnostic pipeline, answers the first question every IP-sensitive security team asks.

Where does it fall short today?

THE ACCURACY CLAIM IS SELF-REPORTED

Avestra reports under 1% on five public OpenCores designs, but independent benchmark results were pending at the time of our training. Until they publish, the only number that counts is the one you measure on your own block.

DIGITAL ONLY

Assertions need a clean clock, so analog and mixed-signal blocks are out of scope beyond their digital portions.

BROWNFIELD IS EARLY

Ingesting and improving an existing assertion library, which is where many teams actually live, is on the roadmap rather than proven.

NARROW BY DESIGN

Broader agentic DV platforms cover debug, regression triage and RTL generation as well. If you want one vendor for everything, a focused tool will look small.

GARBAGE IN, GARBAGE OUT

The spec/RTL cross-check is only as good as the spec. Teams with thin or stale specifications will get less, although finding that out is itself useful.

EARLY REFERENCES

The product is young and named production references are limited, so expect to be an early adopter with the leverage and the risk that brings.

Avestra's accuracy number is the claim to test, not the conclusion. The only number that counts is the one you measure on your own block.

How should a team try Avestra before adopting it?

Run a bounded, side-by-side evaluation on one real block, with success criteria agreed before anything is generated. A generic demo proves very little; your RTL, your reviewers and your simulator prove a lot.

01 · PICK ONE MEANINGFUL DIGITAL BLOCK

Use one with a usable spec and RTL. A protocol controller, FIFO, arbiter or bus interface works well. A representative slice is fine; you do not need to hand over a full IP.

02 · BASELINE THE MANUAL PROCESS

Record engineer hours, assertion count, review effort and known gaps from the last time your team wrote SVA for something similar.

03 · AGREE ACCEPTANCE CRITERIA UP FRONT

Decide what “good” means before the run, so nobody grades on a curve afterwards.

04 · RUN AVESTRA AND KEEP EVERYTHING

The spec/RTL findings and suggested fixes, the assertions, SVA coverage, testbench and traceability back to source.

05 · HAVE YOUR OWN EXPERT SCORE IT

Your most skeptical verification engineer, not the vendor, decides which properties are correct and useful.

06 · SIMULATE IT IN YOUR NORMAL FLOW

Look for vacuous passes, false failures and SVA coverage contribution.

07 · RUN THE SAME BLOCK THROUGH A FRONTIER MODEL

Use a good prompt. If the specialized pipeline is not clearly better on the same input, you have your answer.

08 · TRANSLATE THE RESULT

Put it in capacity, schedule and risk terms your VP will recognize.

What to measure

TIME TO FIRST USABLE SUITE

Elapsed time, manual baseline vs. Avestra

CORRECTNESS

% of assertions accepted without semantic correction

REVIEW BURDEN

Engineer hours to inspect and repair the output

COMPLETENESS

Required behaviors and corner cases actually covered

TRACEABILITY

Each property linked to a spec requirement or RTL behavior

SHIFT-LEFT FINDINGS AND FIXES

Spec/RTL inconsistencies found before simulation, and how many suggested fixes your designers accepted

SVA COVERAGE VALUE

Temporal domain coverage holes addressed, useful cover properties added

Do it with a designer and a DV engineer in the room. Watching the same output through both lenses tells you quickly whether the value sits at RTL time, at verification time or both. Avestra expects to open hands-on evaluations on customer blocks in late October; in the meantime, Ashok is happy to walk teams through the approach and help scope one.

Our bottom line

Avestra is not a replacement for verification judgment. It is a focused, domain-deep way to catch spec/RTL disagreements and get suggested fixes before they become regression failures, then get a reviewable first assertion suite out of a spec and RTL quickly. For designers and DV teams under real schedule pressure, that is worth one well-run evaluation.

It also fits the larger shift we describe as EDA 3.0: specialized AI agents that challenge each other's work across the lifecycle, rather than one monolithic tool. We explored that idea in What Falls Between the Silos.

Frequently asked questions

What is Avestra Studio?

Avestra Studio is an agentic AI system from Tuple Technologies that reads a design specification and RTL, flags spec/RTL inconsistencies and suggests fixes before any assertions are generated, then produces SystemVerilog Assertions, temporal domain (SVA) coverage and a coverage-driven testbench for standard simulators such as Questa, VCS and Xcelium.

What kind of coverage does Avestra generate?

Temporal domain coverage, also called SVA coverage, built from assertion properties. Design coverage has three parts: code coverage, functional coverage, which measures the testbench, and SVA coverage. All three need to come together before tape-out. Avestra delivers the SVA coverage part; it does not generate functional coverage.

How is agentic assertion generation different from prompting an LLM?

A single prompt produces one unchecked answer. An agentic pipeline splits the job into stages, such as spec interpretation, RTL analysis, generation and conflict checking, and re-loops until the output passes its own checks, which targets incorrect, tautological and vacuous assertions.

Who benefits most from AI-generated SystemVerilog Assertions?

RTL designers who can write assertions while design intent is fresh and act on suggested spec/RTL fixes before handoff, DV engineers building assertion and SVA coverage suites, and engineering leaders who need more verification throughput without adding proportional headcount.

Does Avestra replace formal verification?

No, it complements it. Avestra generates verification intent and collateral; a formal engine proves properties. Well-formed assertions are the input both simulation and formal flows depend on, so better assertions make every downstream engine more useful.

How accurate are Avestra's generated assertions?

Avestra reports an incorrect-assertion rate of around 1%, compared with roughly 30% or more for general-purpose LLMs used ad hoc. These are vendor figures, so teams should measure correctness on their own designs during an evaluation.

What is the best way to evaluate an AI assertion tool?

Run one representative digital block through the tool and through your manual baseline, agree acceptance criteria first, have your own expert score correctness and usefulness, simulate the output in your normal flow, and compare time, review burden, spec/RTL fixes and SVA coverage value.

If you missed Assertion-Driven Silicon Success, email me at simon@ai-techsales.com and I'll send you the recording link. If you want to scope an evaluation on one of your own blocks, covering spec/RTL analysis with suggested fixes and SVA generation, reach out and we will set it up with Ashok's team.

Simon Bennett, CSO and Co-Founder, AiT

Keep reading

ICTK PUF

The Key That Was Never Written Down: Hardware Identity for the Post-Quantum, Chiplet Era

chiplets Photonics yieldWerx