DAC 2026: What We Saw Between Chips and Systems

Our CEO, Yuri, went to DAC 2026 in Long Beach and came back saying it was one of the most useful conferences he’d been to in a while. His second conclusion was less flattering: next time, we send an engineer. There’s only so much a CEO can pull from a conversation that starts on chiplets, drifts into verification methodology, and lands somewhere in EDA tooling and heterogeneous compute. The DAC 2026 trends behind that conclusion were hard to separate into neat hardware and software categories.

DAC rebranded a few years back as “The Chips to Systems Conference,” and walking the floor, the name holds up. People have been saying “hardware and software are converging” for a decade, but this year it showed up in the actual session titles and booth conversations, not just a keynote slide: system-level modelling sessions sitting next to RTL verification talks, a “Systems & Software Deployment” track that exists because enough of the program stopped fitting cleanly under “chip design.” Fewer session titles told you whether the presenter’s day job was closer to a fab or a kernel tree.

The line between hardware and software engineering has gotten harder to point at.

AI agents showed up, and they brought a lot of infrastructure with them

Roughly 55% of DAC’s 2026 technical program covered AI and design in some form. Every outlet already wrote that headline. The more interesting question is what makes these agents work at all.

Every credible agentic workflow on the floor depended on a stack of existing engineering infrastructure: verification environments, simulators, emulators, design databases, formal checkers, proprietary runtime data collected from someone’s existing testbench, orchestration to sequence all of it. None of that infrastructure goes away just because an agent shows up to use it.

Synopsys’s two new agentic workflows, which we’ll get into below, follow that shape exactly: new cloud orchestration (Microsoft Discovery for one, NVIDIA’s Nemotron stack for the other) layered on top of tools Synopsys already had, its VCS simulator and its Fusion Compiler implementation tool.

Cadence’s product lineup makes the same point even more plainly, because it never pretended one agent could cover everything. Instead of a single generalist, Cadence built four separate agents, each scoped to a different slice of its existing tool stack. ChipStack handles front-end digital design and verification: RTL generation, testbench creation, regression, debug. ViraStack handles analog design, built on Cadence’s existing Virtuoso analog IP libraries, since analog circuits don’t automate the same way digital RTL does. InnoStack handles the digital back-end: placement, routing, timing and power closure, signoff. AuraStack, the newest of the four, extends the same idea into PCB and packaging design. An orchestration layer called AgentStack sits above all four, routing work between them so an engineer can work at the level of intent instead of sequencing each stage by hand.

None of those tools- VCS, Fusion Compiler, Virtuoso, the placement and routing engines – get replaced by the agent sitting on top of them. Each agent becomes another user of its tool, scoped to one domain, sitting next to the engineers who still decide what that tool is supposed to check for in the first place. That’s a distinction we’ve written about before: AI can run the check, but someone still must define what counts as passing.

Verification might be AI’s killer app, and it’s boring

Ask which AI capability gets the demo slot at a chip conference, and the answer is RTL generation: point a model at a spec, watch it write working Verilog. Ask which one actually shows up in the numbers vendors are willing to publish, and it’s something a lot less exciting. Debugging failed verification runs eats days or weeks of engineering time per failure, and that’s exactly where automation pays for itself. DAC 2026 backed that up with harder numbers than the usual demo reel.

Synopsys’s two agentic workflows, the ones mentioned above, are aimed at two different problems. The first, built with Microsoft Discovery, targets debug closure: an AI-powered verification and root-cause-analysis pipeline. In early evaluations, Synopsys reported 25 to 40 percent reductions in debug cycle time, framed as saving “many weeks of engineering effort” and labelled explicitly as early-stage results, not production-wide numbers. AMD is evaluating this specific workflow for upcoming products, though evaluation isn’t deployment at scale.

The second workflow, built with NVIDIA, targets coverage closure instead. It compresses what Synopsys called weeks of manual coverage work into hours, with a reported 50x faster path to validated RTL and 20 percent additional coverage. Again, both figures are Synopsys’s own comparisons against a baseline without agents, not third-party audited benchmarks.

Other vendors told similar stories about different pieces of the same problem. Undo builds runtime-recording tools for debugging C/C++ and SystemC systems; at DAC, it pitched itself as the layer that gives AI agents the execution context to do root-cause analysis accurately, instead of guessing from logs and waveforms. ChipAgents presented a joint paper with STMicroelectronics on an agentic verification methodology spanning spec interpretation through test generation and debugging, reporting sharp reductions in time spent on formal assertion generation and UVM environment setup. Vendor-reported, from a specific engagement, not an industry average.

Siemens took a different angle from Synopsys entirely. Every agent’s decision in its Fuse EDA workflow must clear a deterministic physics engine before it’s allowed to proceed, full stop, before anything ships anywhere. Whether Synopsys’s or Cadence’s agents run an equivalent check internally, we genuinely don’t know; neither company framed its announcement in those terms at DAC. What Siemens puts front and center is a question every one of these vendors will eventually have to answer: who signs off on what the agent decided, and what proves it was right. It’s a question we’ve dug into directly in how regulated-industry engineering practices apply to AI-assisted work.

Worth being plain, too, about who all this tooling is actually for. Synopsys, Cadence, and Siemens sell into organizations that already run full verification departments, and AMD and NVIDIA are the ones doing the evaluating. None of them are priced or built for a two-person startup. Verification has never been the glamorous part of the job, and it looks like it’s about to become the first one AI gets paid to do, for the companies that could already afford to throw more engineers at the problem.

Software is arriving before silicon

None of this is new on its own. Virtual platforms and pre-silicon software development go back decades; teams were running early software against emulators in the 1990s, long before “shift left” became a phrase people said out loud. What’s worth pulling out of DAC 2026 is which part of that old workflow AI is starting to take over, and DAC gave two separate examples pointing at the same shift.

The clearer one was a Samsung presentation in the Systems & Software Deployment track. Automated Android testing normally runs post-silicon, with unattended flashing, reboot, and recovery against a physical device. The presenter moved that workflow onto emulation instead, using fastboot virtualization to control the device without native fastboot support. Running the tests on emulation is the familiar shift-left move; the newer piece is an on-premises LLM triaging the kernel panics that turn up during testing, judging whether each one is a real bug or just bring-up noise. A Synopsys executive who tracks this area called it a continuation of a pattern he’s watched build over several DAC cycles: pulling post-silicon workflows earlier, ahead of the point where changing course gets expensive.

Siemens showed a version of the same shift from the vendor side. Its DAC 2026 sessions covered pre-silicon digital twin platforms meant to catch issues earlier in the design, and pitched emulation and prototyping as central to hardware and software verification at scale, not as a fallback for teams still waiting on real silicon.

We’ve run a version of the same problem ourselves for more than a decade, on an ongoing pre-silicon project with a chip vendor. We’ve built and maintained more than 100 device models across over 1,000 platform configurations. That virtual environment supports firmware, BSP, kernel, and driver development roughly six to nine months ahead of target hardware, generation after generation. Sorting through failures across that many configurations has been manual work, done by engineers reading logs one at a time. Tooling like what Samsung described at DAC is exactly the kind of thing that would save real hours on a program like that.

Chiplets create more boundaries for somebody to debug

Chiplets and multi-die architecture got a lot of attention at DAC 2026. Chip-level chiplet architecture and packaging aren’t our area, so we’ll skip predicting where that goes next; our work sits at the embedded and system-software layer.

Splitting a chip into multiple dies moves complexity to the boundaries between the dies, rather than removing it. Every additional die boundary is another interface, and every interface brings its own problems. Initialization has to be sequenced correctly across dies. Security domains must be established and verified at each boundary. Components that share state need to stay coherent. And when something breaks, the failure doesn’t always belong cleanly to one side of the boundary, which makes it harder to localize. Splitting a monolithic design into chiplets solves real problems: yield, cost, reuse across product lines. It also creates more places where two well-tested components meet and something unexpected happens at the seam.

For the software and firmware layer specifically, more die boundaries generally means more bring-up and integration work, not less. Whatever runs on a given die still needs firmware that understands where its own boundaries sit and what’s on the other side of them. That’s not a chiplet-architecture problem. It’s an embedded software problem, and chiplets are generating more of it.

What happens after first silicon

DAC’s own exhibitor prospectus lists “Post Silicon Services” as its own category, sitting alongside IP/Cores, Verification, and Physical Design. It’s real. It’s also one of the smaller categories on that list, well behind IP/Cores or Verification in size. Nobody puts a keynote on stage to talk about firmware maintenance in year five.

That’s a strange gap for an industry that spends real engineering money on exactly those years. Our own ARM platform engagement is a version of it. Seven-plus years of firmware and lifecycle work, starting at first silicon bring-up. Boot firmware across UEFI, U-Boot, and ATF. Linux BSP maintenance across three distributions. Silicon errata, customer-specific configuration, L2/L3 support, and more than 100 firmware releases. Most of those engineering hours landed well after the milestone everyone remembers. Most of the decisions that made those years manageable, or turned parts of them into a slog, were made earlier, before the chip existed.

A conference calling itself “Chips to Systems” is more literally accurate every year. Chip and system, pre-silicon and post-silicon, design and support, all keep getting harder to draw a clean line between. DAC’s own program hasn’t fully caught up to its name yet. Neither has most of the industry’s attention, judging by which years get stage time.

Which is probably as good an explanation as any for why Yuri came home convinced that next year, he’s bringing an engineer. Whoever that engineer is will need to know chip design, verification, firmware, and a decade of post-silicon support, because that’s apparently the job now.