Are You Ready for Spec-Driven Verification?

Quick recap: verification is checking that your implementation of a design matches the in-house design/test specification. In contrast, validation means checking that the implementation matches design intent as defined by a customer specification, use cases, etc. Let’s focus on verification; for simplicity I’ll use “design specification” as a proxy for both design and test. This spec is developed by an in-house architect who reads the customer spec, maybe augmented by discussion with customers and/or application engineers, and translates it into a representation more closely aligned with in-house platforms, IP and expertise. Most often this will be one or more PDF documents with descriptions of objectives, tables, block diagrams, timing diagrams, state machine diagrams, register maps, and often explicit or implicit references to other documents. Verification teams read this document to guide building their verification collateral.

This mapping from human understanding to tests is neither a one-time step nor error-free. Customer requirements evolve, architect understanding evolves and human reading of requirements, from architect to implementation to verifier teams, all present multiple opportunities for misinterpretation. Can automating spec interpretation, through agentic processing, mitigate these problems? Yes, if handled carefully.

Systematically eliminating interpretation errors

Analysis must start with a detailed knowledge base built on an understanding of the spec – likely represented by more than one document. In an ideal spec-driven flow, a design team should be able to upload PDFs, timing and block diagrams, protocol standard specs and design collateral. From this a spec-driven verification system should build a robust knowledge base from which it can generate test collateral.

That collateral should include a readable test plan, progressing from basic tests, to bring up tests, to stress tests, to complex feature coverage. These should particularly stress bug-prone areas, for example recent design updates as detected in RTL commit info. Together with the test plan it should generate a testbench architecture and full UVM testbenches, including UVM agents, clocks and resets, with appropriate monitors, drivers, memory models, coverage properties and scoreboard reference models as required by the spec.

You should be able to see, side by side with a generated test objective, a more detailed breakdown of how the the verification agent intends to implement that test. I have emphasized before the importance of building trust, in agentic systems, an essential characteristic in any worthwhile verification flow. If you notice a mistake, you should be able to correct that mistake and have the system learn from that correction.

Regression tests then should provide an at-a-glance summary of any failures, triage clustering, automated root cause analysis and localization to RTL, testbench or spec errors. When a coverage point is claimed, you want to see the corresponding pages in the spec, again building trust that the system truly understood the objective. Also with opportunity to correct mistakes.

What if the spec is wrong?

A systematic approach to verification must consider the possibility of errors in any phase of this pipeline, from spec to design to verification. What might spec problems look like? There could be inconsistencies within the spec itself, or between the spec and the design. There may also be ambiguities in the spec which could lead to more than one possible implementation in the design, or multiple possible test implementations. These should be detected and corrected (by you) up front. Another possibility is holes in the spec – behavior implicit in how functionality is defined but not specified in detail. I’m not sure yet how these might be handled.

MooresLab at DAC2026

I have written about MooresLab before, a fairly new venture founded by design alumni from Microsoft. They have been busy advancing their MooreIP full-stack AI platform: a verification agent (VerifAgent™), a signoff agent, a debug agent, a coverage agent, along with planned spec agent and design agent components. In my most recent discussion with Shelly Henry (CEO of MooresLab). I was favorably impressed not only by the range of features covered in this agentic tool suite but also by the level of investment in methods to build user trust. A consideration which I think will separate the leaders from the also-rans in this space.

On the spec agent, remember the live newspapers in the Harry Potter series? Imagine specs with similar dynamic graphics!

Well worth checking MooresLab at booth #826 in this year’s Long Beach DAC. In the meantime, you can get more background HERE.