AI Agents for Chip Verification Planning
Let the agent draft the plan, but keep “covered” in human hands#
An agent has turned a set of design requirements into a verification plan. It has proposed test objectives, mapped requirements to test cases, and suggested scenarios that may be missing. Before the team begins regression work, one question matters more than whether the document looks complete: can an engineer point from every proposed test back to the design intent it is meant to protect?
Recent reporting on chip teams using AI agents describes this move into verification planning. The agent can help convert design intent into test objectives, draft initial plans, map requirements to test cases, and identify areas where coverage needs stronger justification. That is useful work. It also creates a new handoff that needs an owner.
A long, sensible-looking plan is not proof that the chip is properly covered.
AI verification plan generation can hide unsupported work#
An agent is good at producing relevant scenarios. Given a requirement document, it may suggest boundary conditions, error paths, and interactions that belong in a serious discussion. But a relevant scenario and a required test are not the same thing.
One proposed test may have no named requirement behind it. Another may be tied to a requirement that has since changed, while the old mapping remains in the plan. A third may appear well supported because every requirement has a test case, yet the team cannot explain why a particular assertion or coverage goal exists or what design behavior it proves.
None of this means the agent has done something wrong. It has produced a first draft from the information it was given. The problem begins when that draft quietly becomes the record of what the team believes it has verified.
That is how a planning aid becomes an unowned part of the operation.
Requirements to test case traceability is the real control#
Verification teams already work with a hard constraint: design intent changes, requirements have dependencies, and regression time is finite. A plan needs more than a list of scenarios that sound technically plausible. It needs a way to show what each piece of verification is there to establish.
The missing control is requirement-level traceability. Every test objective, assertion, and coverage goal should point to a named design requirement. Each requirement should also show whether it has meaningful verification attached to it.
This does two things at once. It separates an agent’s useful suggestions from the work the design actually requires, and it exposes the gaps that a polished plan can hide.
A test objective without a requirement link is not necessarily bad. It may be a valuable engineer suggestion, a defensive test, or a question worth taking back to design. But it should be marked as unsupported until someone gives it a reason to exist. A requirement without a linked test, assertion, or coverage goal should be visible as uncovered, not lost in a document that looks finished.
What AI agents in semiconductor verification should return#
Our recommendation is to make the traceability matrix part of the agent’s required output, not an extra task for someone to assemble later. The plan should return the proposed verification work alongside the evidence for it.
At a minimum, the matrix should show:
- The named design requirement
- The linked test objective or test case
- Any related assertion
- The coverage goal attached to that requirement
- The source or rationale for the link
- Requirements with no verification attached
- Proposed tests with no requirement attached
- Links affected when a requirement changes
The important point is not the table itself. It is the decision right behind it.
The agent can draft a plan, find possible omissions, and keep the mapping current when the requirement record changes. A verification engineer should decide whether an unsupported test belongs in the plan, whether a requirement is sufficiently covered, and whether a changed requirement requires new verification work. Those decisions define what the team is willing to call verified.
Regression approval needs a visible stop#
A regression should not be approved because the agent generated a thorough-looking plan. It should be approved after an engineer can see and clear the exceptions: unsupported proposals, uncovered requirements, and mappings changed by new design intent.
That does not turn every plan update into a manual rewrite. It gives the agent a clear job and gives the engineer a clear review surface. Instead of reading a large document and trying to infer what is missing, the engineer can work from the places where the evidence is incomplete. This is the same reason AI agent evaluation in production needs explicit checks before a workflow goes live.
The requirement record also needs an owner when design intent changes. If that ownership is vague, the agent will keep producing mappings from an outdated version of the truth. The result may be a clean regression process built around the wrong plan.
Speed belongs in drafting. Trust belongs with the engineer who can show what every test is meant to cover. If this kind of review path needs to live inside your verification operation rather than in a separate document, Acrein Group can build and run the workflow that keeps requirement changes, evidence links, and approval decisions visible.