Column: Silicon systems design
Agentic AI is changing design verifi cation
By Mike Bartley, CEO, Alpinum
complete workfl ows. However, autonomy in execution must not become authority at sign-off . AI in design verifi cation is entering
A
a new phase. Early AI-assisted tools focused on individual tasks: summarising logs, grouping regression failures, generating code and identifying coverage patterns. T ese capabilities reduced repetitive eff ort, but remained reactive. An engineer asked a question and the tool produced an answer. Recent announcements from Cadence,
Siemens and Synopsys show that this shiſt is moving from research towards commercial EDA workfl ows. Rather than responding to one prompt at a time, an AI agent can be given an objective, form a plan, invoke tools, inspect results and decide what to do next. In verifi cation, this could mean moving from a system that generates one assertion to one that reads a requirement, creates candidate properties, runs a formal engine, analyses the result and recommends the next investigation. A copilot suggests an action. A
verifi cation agent pursues an objective through a sequence of actions.
From AI assistance to AI action Verifi cation environments already
In design verifi cation, a passing regression doesn’t prove that a design is correct; it only shows that no failure was
detected under the conditions exercised
contain automation. Regressions schedule tests, coverage tools merge results, formal engines explore state spaces and debug platforms help engineers trace failures. Agentic AI does not replace these engines; its potential role is to coordinate them.
12 September 2026
www.electronicsworld.co.uk
rtifi cial intelligence (AI) is progressing from assisting with individual verifi cation tasks to planning, executing and adapting
Consider an uncovered transition
in a power-management sequence. A conventional assistant might explain the RTL or generate a test. A verifi cation agent could identify the relevant requirement, inspect existing tests and assertions, generate a candidate sequence or property, run simulation or formal analysis, examine the outcome and refi ne its approach. Also, verifi cation agents can’t
be treated like ordinary soſt ware- development agents. Verifi cation has a more diffi cult defi nition of success. A coding agent may be judged
successful when its code compiles and passes a test suite. In design verifi cation, a passing regression doesn’t prove that a design is correct; it only shows that no failure was detected under the conditions exercised. Higher coverage doesn’t
automatically mean greater confi dence. A generated test may reach a new state without exercising important architectural behaviour. A property may be proven while encoding the wrong requirement. An incorrect assumption may over-constrain
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
