search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Column: Silicon systems design


Assisted verifi cation: Sign-off still depends on engineering intent


By Mike Bartley, CEO, Alpinum


draſt ing, regression triage, debug support, log summarisation, coverage analysis and knowledge retrieval. Used carefully, these capabilities can reduce snags in daily engineering work and enable teams to handle the increasing scale of modern verifi cation environments. However, there is a critical distinction


A


that must not be lost. AI can accelerate verifi cation activity, but it does not remove sign-off responsibility. T e judgment that a design has been suffi ciently verifi ed remains an engineering decision. It depends on intent, evidence, assumptions, risk and review discipline. It can’t be delegated to a tool simply because that tool can generate more tests, process more logs or produce a confi dent summary. Verifi cation is not a volume exercise.


More tests do not automatically mean better verifi cation. More coverage data does not automatically mean higher confi dence. More debug summaries do not automatically mean stronger root-cause understanding. T e purpose of verifi cation is to establish whether the design behaves as intended under the conditions that matter. T at is why verifi cation intent becomes even more important in the AI era.


rtifi cial intelligence is moving fast into design verifi cation. Teams are already exploring AI assistance for test generation, assertion


AI can accelerate verifi cation activity, but it does not


remove sign-off responsibility


Activity is not the same as confi dence A common failure pattern in AI adoption is to mistake output for progress. A team may use AI to generate additional tests, suggest assertions, classify failures or summarise regression results. These outputs may be useful, but they are not inherently meaningful unless they are connected to a defined verification objective. Verifi cation teams have long


12 July/August 2026 www.electronicsworld.co.uk


understood that metrics need interpretation. Code coverage, functional coverage, assertion pass rates and regression results are essential indicators, but they are not sign-off decisions by themselves. A design may show strong coverage numbers while still missing an important architectural scenario, a protocol dependency, an invalid assumption, or a system-level interaction. AI can amplify the same problem. It


can produce plausible tests that don’t target the highest-risk behaviour. It can draſt assertions that look syntactically correct but are semantically incomplete. It can summarise failures in a readable way whilst omitting the causal detail needed for engineering judgement. T e question, therefore, is not whether AI helped the team do more; the question is whether it helped the team verify the right things with stronger evidence and better traceability.


The meaning of verifi cation intent Verifi cation intent is the engineering defi nition of what must be checked, why


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