Column: Silicon systems design


Figure 1: Evidence-grounded AI engineering loop


technically capable agent consistently wrong. An obsolete verification plan can lead it to optimise the wrong coverage target. A previous debug conclusion may no longer apply after an RTL change. Recent EDA agent architectures are


property holds under a defined model. An agent can say that a test covers a requirement. A traceable verification plan can show whether the requirement was actually mapped, exercised and reviewed. An agent can explain a regression failure. Te simulator log, waveform, seed and design revision provide evidence that can confirm or contradict that explanation. Te strength of an AI-assisted workflow


therefore depends less on how confidently the model evaluates itself and more on the quality of the external evidence available to challenge it.


External evidence is necessary, but not sufficient EDA has an advantage over many open- ended AI domains: engineering workflows already contain executable checks. Compilers, simulators, formal engines, lint, CDC/RDC analysis, reference models, assertions, scoreboards and sign-off checks can provide feedback that is more concrete than an LLM’s own judgement. Siemens, for example, has described self-verifying EDA agents that continuously validate decisions against deterministic, physics- based engineering engines. However, a passing tool result still needs


interpretation. A simulation can pass while missing an important scenario. A formal proof can be valid for the property supplied while the property itself expresses the wrong requirement. A scoreboard can agree


with a flawed reference model. Coverage can increase without materially reducing functional risk. Te question is not simply “Did the tool


pass?”. It is “Did the right tool evaluate the right engineering question, against the right revision, with the right assumptions, and does the result provide evidence for the intended requirement?” Tat distinction is central to trustworthy


AI-assisted engineering. An AI agent may plan and execute engineering activity, but trustworthy outcomes depend on controlled context, governed tool access, external evidence and independent acceptance criteria.


Controlled context comes before autonomous action An AI agent can’t work reliably from RTL alone. It may need specifications, verification plans, testbench architecture, assertions, coverage models, previous failures, waivers, coding rules and sign-off criteria. This is where retrieval-augmented


generation, or RAG, can become engineering infrastructure rather than a generic AI feature. The objective is not merely to give an agent more documents. Retrieved context should be authoritative, version-controlled, permission-aware and traceable to its source. A stale specification can make a


therefore combining domain-specific RAG with controlled orchestration. Siemens’s Fuse EDA AI Agent, for example, incorporates an EDA- focused RAG framework, multimodal engineering data and Model Context Protocol support for agent and tool integration.


The role of controlled tool access Giving an agent access to engineering tools creates another assurance problem: authority. An agent that can invoke a simulator differs from one allowed to alter formal assumptions, change a waiver, modify a verification plan, or declare a coverage target complete. Tool access should therefore be scoped by role, project and action. Interfaces such as the Model Context


Protocol (MCP) are useful because they can provide a structured mechanism for exposing approved tools and data to agents. But the protocol itself does not make an action safe. Engineering organisations still need authentication, authorisation, input validation, audit trails, version control and approval gates. NIST’s 2026 AI Agent Standards


Initiative similarly highlights secure and interoperable interaction between autonomous agents, external systems and internal data as an important requirement for broader agent adoption. In semiconductor environments, these controls are particularly important because an agent may interact with sensitive design IP and engineering systems whose outputs ultimately influence release decisions.


www.electronicsworld.co.uk October 2026 13


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