Column: Silicon systems design
Design verifi cation - from experimentation to measurable capability
By Mike Bartley, CEO, Alpinum
exploring AI for regression analysis, debug assistance, log summarisation, coverage exploration, test prioritisation and knowledge retrieval. T ese are sensible starting points because they address areas where engineering eff ort is oſt en consumed by volume, repetition and pattern recognition. T e harder question is no longer whether
A
AI can help with an isolated verifi cation task, since in many cases it can. T e more important question is whether “AI in DV” measurably improves verifi cation capability. T at distinction matters. A tool that summarises logs faster may reduce local eff ort, but it doesn’t automatically improve sign-off confi dence. A model that generates tests may increase activity, but activity is not the same as verifi ed intent. A chatbot that retrieves methodology guidance may be useful, but it does not remove the need for engineering judgement. T e next phase of “AI in DV” will
therefore be less about experimentation and more about evidence. Verifi cation remains a discipline built around risk reduction, traceability, coverage closure, reproducibility and confi dence in the design before silicon commitment. AI must operate within that discipline, not outside it.
12 June 2026
www.electronicsworld.co.uk
rtifi cial intelligence in design verifi cation, or “AI in DV”, has moved beyond abstract discussion. Verifi cation teams are already
Portable stimulus approaches similarly A chatbot
that retrieves methodology guidance may be useful, but it does not remove the need for engineering judgement
AI's success in DV is hard to defi ne Verifi cation is not a collection of disconnected tasks, but a system of methods, tools, reviews, data, metrics and engineering decisions. UVM and related verifi cation methodologies exist because complex projects need reusable structure, interoperability and disciplined execution across teams and tools.
refl ect the need to express verifi cation intent across diff erent execution platforms and levels of integration. T is makes success harder to defi ne than in a simple automation use case. A local productivity gain may be
real, but still fails to improve the overall verifi cation outcome. For example, an AI assistant may reduce the time required to classify a regression failure, but if the classifi cation is not traceable, not reviewed, or not integrated into the defect and coverage process, its system- level value is limited. Verifi cation impact should therefore
be judged at the level of the fl ow: Does AI shorten debug cycles without reducing review quality? Does it help engineers close meaningful coverage gaps, or merely create more tests? Does it improve the consistency of triage across distributed teams? Does it reduce repeated investigation of the same root cause? Does it help expose risk earlier? T ese are capability questions, not tool adoption questions.
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
