Reply to thread

Message: [QUOTE="Bombastus, post: 92371, member: 2178"] In February 2026, Siemens introduced agentic verification workflows that generate RTL, run lint and CDC checks, and build verification plans. The important part is not the agent producing more work on its own. It is what gets to judge the work before the agent moves on. A chip-design agent can plan a task, write code, call an EDA tool, inspect the result, revise the design, and keep going for hours. Every extra autonomous step also creates another chance for a plausible mistake to survive. [B][URL='https://goldmidi.com/community/threads/tsmcs-y-j-mii-likens-ai-to-a-3-year-old-superman.77753/']The verification boundary for AI-assisted chip design[/URL][/B] matters because semiconductor workflows already contain something general-purpose AI lacks: tools that can reject an answer for concrete technical reasons. Verification therefore has to sit inside the loop, not at the end of it. An agent that writes RTL and then asks another language model whether the code looks right has barely changed the trust problem. A useful gate hands authority to a compiler, linter, simulator, formal engine, coverage checker, CDC tool, or physical signoff engine whose result is tied to the design itself. [HEADING=2]Agentic EDA changes where verification happens[/HEADING] Traditional automation often runs a prescribed flow and reports failures to an engineer. An agent can react to those failures, choose a new action, modify files, rerun tools, and continue without waiting for a person. Cadence, Siemens, and Synopsys all announced broader agentic design or verification systems during 2026, pushing the industry from isolated AI assistance toward longer multi-tool workflows. Longer autonomy makes local checks more important. A bad assumption near the start can contaminate dozens of later decisions if the system only validates the final output. Siemens now describes self-verifying EDA agents that continuously send decisions through deterministic, physics-based engines before proceeding, while its verification toolkit exposes lint, clock-domain crossing, simulation, formal, and debug functions directly to agentic workflows. Project context needs its own gate as well. Hardware languages are less forgiving when an agent invents a signal, misunderstands an interface, or ignores an elaborated hierarchy. New EDA interfaces can expose compiled project databases to agents so generated Verilog, SystemVerilog, or VHDL is checked against the design that actually exists instead of relying on generic model memory. [HEADING=2]Formal checks can constrain the agent step by step[/HEADING] One promising approach makes the agent build hardware through small, verifiable transformations rather than generating an entire RTL block in one shot. A 2026 [B][URL='https://arxiv.org/abs/2606.19387']stepwise formal hardware generation framework[/URL][/B] lets an LLM choose from predefined transformation rules, checks whether each rule can legally apply, and preserves correctness as the design becomes more concrete. The distinction is easy to miss. Verification after generation asks whether a completed artifact passes. Verified construction limits which moves are allowed while the artifact is being created. An agent can still choose a poor path or hit a dead end, but the framework can reject an invalid transformation before the error gets buried under later code. Block-level verification agents are moving in a similar direction. One 2026 system split functional verification into 31 stages and attached an automated checker to every stage, rather than trusting one long chain of model decisions. Its reported results reached 98.5 percent code coverage and 100 percent functional coverage on some evaluated modules, although those benchmark results do not establish full-chip production readiness. [HEADING=2]A passing tool result is not the same as correct intent[/HEADING] Hard gates solve only the questions they are given. A simulator can show that a test passes, and a formal engine can prove a property, yet neither can determine whether the original requirement was misunderstood. If an agent converts an ambiguous sentence into the wrong property, flawless verification may simply certify the wrong target. Recent hardware work is attacking this earlier boundary by tightening specifications before RTL generation. Controlled natural-language scenarios can be converted into formal properties that remain readable to engineers while giving verification tools something exact to evaluate. It is a less glamorous step than autonomous coding, but specification quality decides what every downstream checker is actually proving. Coverage creates another trap. High code coverage shows which implementation structures were exercised, not whether the verification plan captured every meaningful behavior. Functional coverage is closer to intent, but only when the chosen coverage model represents the right scenarios. An agent should therefore be allowed to generate tests and chase coverage holes while engineers retain authority over requirements, waivers, sign-off criteria, and changes that redefine intended behavior. The safest architecture is not an AI that has somehow learned never to be wrong. It is an agent surrounded by gates with different kinds of authority. Language models can plan and propose, while compiled design knowledge, simulation, formal reasoning, coverage, and physics-based sign-off keep deciding whether those proposals deserve another step. [/QUOTE]

Name