Last in a short series on what DAC 2026 actually told us about the state of EDA.
DAC chose an interesting tag line this year - "DAC, The Chips to Systems Conference." I don't think that was a marketing accident. Everyone in the room knows a chip doesn't ship alone anymore - it ships inside a board, inside a system, inside a fleet, inside a customer's actual field experience. The name is trying to say the aperture has widened.
It's a strange kind of déjà vu for me, because I walked a room through almost exactly that argument from Room S-3B this year. Three eras, in the telling I gave: the first era turned transistors into logic, the second turned logic into systems-on-chip, and the one we're in now is turning chips into AI systems - silicon that has to be validated against a real workload, not just a test vector. DAC picking "Chips to Systems" as its new name isn't a coincidence so much as the conference catching up to an argument its own attendees have been making on the floor and in the presentations for a year.
Walk that same floor, though, and ask the two phrases everyone reaches for - end-to-end and top-to-bottom - to define their own edges, and the answers narrow fast. Almost every vendor means the same thing by them, and it's a smaller claim than the name on the building.
In this year's telling, "top" usually means intent or architecture - spec capture, requirements, maybe a system model, feeding downward into RTL. That's genuinely new ground; five years ago "top" meant RTL itself. "Bottom" usually means tape-out, occasionally stretched to include physical signoff or, in the more ambitious pitches, first-silicon bring-up.
That's real progress. It is not, by any definition a systems company - or the customer holding the finished product would recognize, top-to-bottom. It's top-to-bottom of the pre-manufacturing design flow. Everything before the fab, one continuous model. Everything after the fab is, in most of these narratives, someone else's problem.
The framework I use to make that argument concrete runs six layers, intent down to yield. Layer one turns requirements into a single traceable, executable spec instead of a document nobody reopens after kickoff. Layer two is architecture exploration - candidate topologies filtered by power, performance, and area, increasingly proposed by AI models trained on the space of good designs, then handed off to interconnect and chiplet IP that's been qualified block by block rather than assumed correct. Layer three is where AI-assisted RTL and embedded firmware actually get written against that spec. Layer four is verification and validation - formal proof that the RTL matches the intent, backed by RF and test infrastructure that exercises it under real conditions rather than a datasheet's assumptions. Layer five is where yield and reliability data trace a fab surprise back to the design decision that caused it. And underneath all five sits an orchestration layer - the compute, workflow, and licensing kept moving across tools and clouds so the rest can actually run, plus a digital thread meant to connect the whole picture rather than just sit inside one slice of it. In the version John and I use internally, we color most of that a single sequential thread and a smaller piece amber, cutting across it - because not everything in this picture hands off in one direction only.
Stated that way, the incumbents' roughly three-quarters of tool spend sits almost entirely in layers two through four. That's not a knock on the tools - they're genuinely excellent at what they do. It's a fact about where the money has historically gone, and it means nobody with real scale has had a structural claim on layer one, layer five, or the seams between any of the six. The seams, not the layers, are the open ground.
And even a six-layer map that reaches all the way to yield has an edge. It stops, in most tellings including my own, somewhere around first silicon and early production. What happens to a part across its actual service life - two years, five years, three product generations - still sits almost entirely outside this picture.
Push higher than intent and you hit something most of this framework doesn't claim at all: the software and workload decision that comes before anyone commits to silicon. I've argued that for intent to survive a lifecycle it has to be explicit, executable, provable, and profitable. Apply that same four-part test one level higher, to the workload decision itself, and most organizations fail all four: the workload isn't written down as a spec, it can't be run as a benchmark, nobody's agreed what "correct" means for it, and no one's actually costed what chasing it will return. Any lifecycle that starts at intent is already one layer down from where the chip's fate gets decided.
Layer five, in the architecture above, already reaches into yield - a real, working connection back from the fab into design decisions, running today. Push past that, though, into the chip's full service life, and the honest boundary keeps moving. Returns, warranty claims, root-cause reports written by a support engineer six months after a customer complaint - all of it usually lives in a ticketing system that has never once talked to a design database.
I've written before about telemetry as the shift-right signal that closes part of this loop - the on-chip instrumentation that reports what silicon actually did once it left the building. That's necessary, but it's not sufficient. Telemetry tells you what happened. It doesn't, by itself, get that story back into the hands of the person who owns the next design review.
Here's the version of this problem that should worry people more than it does: the same defect showing up generation after generation of a product line, not because anyone's incompetent, but because nobody left behind a way to extract it.
Picture a decades-old USB controller block, inherited from an acquisition, integrated into three generations of SoCs by three different teams, none of whom overlapped in time. The RTL still simulates clean. What's missing is everything that isn't RTL - the errata list a departed verification engineer kept in his own notes, the known corner case that was worked around in firmware instead of fixed in silicon, the field failure from two products ago that got patched at the driver level and never made it back into a spec.
There are pieces of this portfolio built for almost exactly this gap. A digital thread meant to carry a part's lifecycle record - provenance, verification history, manufacturing data -across every team and company that ever touches it, so an inherited block doesn't arrive as a black box. A separate discipline, further up the stack, built to qualify interconnect and chiplet IP before another team ever unwraps it. And a formal-proof layer that can tell you, with certainty, that today's RTL matches today's intent.
None of those, on their own, close this gap, and that's worth being honest about. A digital thread only carries what someone bothered to write into it. Formal proof tells you a block is correct right now; it has nothing to say about the workaround someone quietly built into firmware three products ago, or why. The tooling to hold an IP block accountable for its own history exists in pieces. Getting every team, on every generation, to actually feed it is a discipline problem as much as a technology one, and nobody, including us, has fully solved it.
The candidate causes span the entire stack. It could be display-controller timing on the SoC. It could be the HDMI PHY, on either end of the link. It could be EDID handshake behavior in firmware. It could be the panel's own timing controller. It could be signal integrity in a cheap cable or a marginal connector. It could be a driver-level power state change nobody flagged as display-adjacent. Each of those pieces was designed, verified, and signed off by a different team, at a different company, using different tools that have never once shared a data model.
The tools to catch a good share of this earlier already exist, scattered across different corners of the same six-layer picture. Virtual prototyping can model a system's cross-domain behavior before a single board exists. RF and test infrastructure can exercise a physical interface under real signal conditions instead of a spec sheet's assumptions. Embedded firmware, written against the same intent as the RTL it sits on top of, can carry known workarounds forward instead of quietly reinventing them. Every one of those exists today, as a point solution, at some vendor. None of them shares a data model with the others, which is exactly why the actual fix, today, looks like a war room: representatives from the silicon vendor, the panel supplier, the board OEM, and the driver team, twenty-plus engineers in a lab or on a call, logic analyzers and protocol analyzers out, burning days or weeks to find one root cause that should have been visible from data every one of those teams already had. The cost of that debug regularly exceeds the cost of the defect it's chasing.
Notice how much of that flicker example was firmware and driver behavior, not RTL. That's not an edge case anymore. Across a growing share of designs, whether a chip is "good" is decided as much by the driver stack, the compiler, and the OS-level power and thermal management sitting on top of it as by anything in the RTL itself.
One layer in the architecture above already treats firmware as a first-class citizen, written against the same spec as the RTL rather than bolted on afterward, and a separate one exists specifically so software and hardware teams can co-design against a virtual platform before silicon even exists. Both are proof the industry knows how to do this. Neither has made it onto the DAC mainstage as anything more than a niche session, run in a different room, for a different audience, than the RTL and verification tracks next door.
John and I have said publicly that we've got a year to push for a different narrative before DAC lands in San Jose in 2027 - the city where, frankly, this event belongs. Here's what I'd want that narrative to include, stated plainly rather than as a pitch.
IP provenance as a first-class topic. Not a session on documentation best practices - a real conversation about whether verification history, known issues, and field escapes can travel with a block as structured metadata, so the next team to inherit that fabric isn't starting from zero.
Cross-company debug as its own discipline. The flicker problem, and a hundred versions like it, deserve a track of their own: what would it take for silicon, board, and driver teams to share enough of a common data model that root cause takes hours instead of weeks and one lab instead of three companies' worth of engineers.
Software in the main hall, not the side room. Driver, firmware, and compiler engineers sitting in the same sessions as RTL and verification engineers, because that's genuinely where the boundary of "the chip" now sits.
Business outcomes, not tool speed, as the actual agenda. I said in that same keynote that the value in this next era shifts from tool speed to business outcomes — time-to-market, quality, and margin — which moves the buyer from an engineering team optimizing productivity to an executive team optimizing revenue impact. A CFO-level view of what a single design decision actually costs, and an orchestration layer keeping compute, workflow, and licensing moving underneath the whole thing, are both already running today, account by account, inside pieces of this picture. That's evidence the architecture is buildable. It isn't evidence that DAC, as a conference, has caught up to it yet.
None of this is solved. I want to be honest about that, including for the thesis we've built at AiT - we've named the shape of the gap more than we've closed it. But naming it accurately is the necessary first step, and it's a more useful use of a year than another round of demos. See you in San Jose.
Simon Bennett is Principal Solutions Consultant and Co-Founder of AI Tech Sales, and a former Synopsys and Intel IP and EDA veteran. The Watchtower Brief is the firm's editorial series on the changing shape of the semiconductor lifecycle.