Specification engineering is gaining traction as a potential solution to the verification bottleneck.
Key Takeaways:
EDA vendors and their customers are looking at a different way to tackle the semiconductor verification bottleneck, combining AI with massive simulations to create a single reference point for designs.
The goal is to reduce the time to sign off with better coverage and more confidence by leveraging a “golden specification” that is precise, complete, traceable, and AI-amenable. If this approach is successful, it would amount to the ultimate shift left. There are still more pieces needed, but this correct-by-construction strategy could have a significant impact on the verification process.
“It is, or should be, a living, machine-readable, executable artifact that serves as the unambiguous semantic anchor for hardware, firmware, and software teams simultaneously,” said Ashish Darbari, CEO of Axiomise. “Tools like SystemRDL and IP-XACT represent a step in this direction, but they remain largely register-map-centric. The deeper problem is that a specification is only truly golden if every stakeholder in the ecosystem can consume it in their own language of choice — RTL engineers, formal verification engineers, UVM testbench writers, firmware developers, and system architects — without a lossy manual translation step in between. That re-translation is where spec drift begins.”
The next step is to extend the golden specification from a human-readable contract to an authoritative, AI-interpretable foundation that drives an AI-native chip design and verification flow, effectively the ground truth against which all generated RTL, testbenches, and analyses are evaluated. “Without such a reference, correctness becomes undefined,” said William Wang, CEO at ChipAgents. “Its requirements have evolved in two key directions. First, from primarily human-readable documents to AI-readable, structured, and executable representations that can be consumed by agentic systems. Second, toward maintaining an even higher standard of precision and completeness, since while AI can surface obvious inconsistencies, subtle or deeply embedded specification errors remain difficult to detect and can propagate at scale.”
What exactly is a golden specification?
Most engineers equate a golden spec with validation, but the definition has changed in recent years with the rise of multi-die assemblies and advanced packaging.
“Ten years ago, the golden spec could primarily define design intent, interface requirements, functional behavior, and verification expectations,” said Satish Radhakrishnan, head of GTM Semiconductor and Electronics at Vinci. For today’s multi-die, chiplet, and 3D designs, that is no longer sufficient. The specification also needs to capture the physical context that determines whether the system will actually work — native geometry, materials, stack-up, interfaces, thermal boundary conditions, mechanical constraints, applied loads, power maps, and expected thermal or thermo-mechanical behavior.”
Others agree. “Ten years ago, it was mostly a static functional description of a monolithic SoC,” noted Guillaume Boillet, vice president of strategic marketing at Arteris. “Today, the specification must capture system-level behavior across heterogeneous dies, with the network-on-chip interconnect becoming a central element. Beyond coherency protocols across dies, chiplet systems require detailed specifications for bring-up, discovery, security, telemetry, error handling, and quality-of-service management between independently developed dies. Fortunately, the industry is making strong progress toward standardizing die-to-die interoperability.”
At a DVCon panel earlier this year, there was a lot of discussion about how AI could substantially reduce the time it takes to verify and debug a design. That hasn’t fully materialized yet. Real progress will depend on a much more complete and flexible spec.
“The new bottleneck is clarity of specification, which goes back decades to the old thinking about splitting the verification engineers from the design engineers,” said Frank Schirrmeister, executive director for strategic programs, System Solutions, at Synopsys. “They were treated as two cohorts, because if you drink your own bath water, that’s not good for finding something new. Remember the executable spec that Alberto Sangiovanni-Vincentelli talked about 30 years ago that never really happened? We fixed one side, and that worked pretty well. We decided that if we fixed the RTL and modeled it as a hardware instance at any given point in time, and there’s a digital thread, then I can do something useful with the variations of that over time. I can do software development, and that’s a nice market. But we didn’t abstract everything. We fixed the hardware, which gives you the boundary, and then you can develop software on top of it. So now is there an executable spec that’s hardware/software and golden, from which everything can be derived?”
In theory, AI will make it possible to do many iterations of a design and come up with an optimal solution. But orchestrating all the steps in the design through verification process is an enormously complex task, even with AI and massive computing capabilities. Given that, does the golden spec apply equally across different parts of the design flow? For example, “golden” in the context of design rule checking (DRC) is a different consideration, albeit an extremely important one. Here, the golden spec or golden reference is no longer a simple static notion of correctness. It’s an evolving, ecosystem‑driven standard of trusted accuracy that must keep pace with rapidly growing complexity. This is especially important for advanced nodes, 3D/chiplet designs, and multi‑vendor flows, and is increasingly anchored in foundry-authored rule decks, close collaboration with key customers and partners, and emerging industry standards to manage risk, yield, and interoperability.
“[DRC] ‘golden’ is really just a way to say, ‘What do we have confidence in with respect to accuracy?” said John Ferguson, senior director of product management at Siemens EDA. “The problem is that we’re in a space where we don’t know what the accurate answer is. You can do a lot of things. You can do a lot of mathematical theory. You can make measurements on silicon or whatever you want. But there’s no guarantee that any of those are right. Particularly with measuring silicon, it’s difficult because the silicon varies across the wafer. It varies from wafer to wafer, from lot to lot. There are a lot of issues there, and that’s just for a 2D design.”
Deciding what is golden can vary. “It is an issue of what you have done that has consistently delivered good results to you, and based on that, we’re going to say, ‘Okay, I have faith in this. It’s worked for me 100 times before. I’m confident it’s going to work 101,'” Ferguson said. “That’s how we evolve from it, and that remains the same.”
Thinking bigger
One of the unstated goals here is to leverage the learnings of the chip industry and apply them to big systems of systems, an idea that EDA companies have been promoting for years, but without much success. What’s changed is the introduction of massive simulations coupled with increasingly sophisticated large language models, which can glue together various steps in a much larger flow.
“MBSE (model-based systems engineering) can be used to lock this in at the front end, at a higher level, but that goes to the same question about how to separate the design path and the implementation path from the verification path,” Schirrmeister said. “To do that, you need something that is the golden truth above that, or as an input to that, as the input to both, two different interpretations. I’m in meetings every day where my interpretation of what happened is somewhat different from the next guy, because I’m listening for different things. The same happens in implementation. In that DVCon panel, it was the question of how to specify these things so that they can actually be verified, and you can have all the implementations?”
Consistent interpretation is a prerequisite to making this work, and that extends well beyond just semiconductors. “The industry has defined systems in different ways, and if you talk to the big chip guys, they say anything above a chip is a system,” said Chris Mueth, senior director of new markets and strategic initiatives at Keysight EDA. “They even go further. They say anything above chip implementation is a system. If you’re going to put the chip in something, that something is going into something else, which is going into something else. There’s a hierarchy involved here. So, when you say golden specification, it’s tied to an end product that you’re selling.”
The possibilities are endless. “In the MBSE space, they deal with systems of systems, which are big things like aircraft carriers, trains, and the like. Imagine starting the design process there. They do functional descriptions, and eventually, out pops a specification for something, and likely, multiple things. They don’t really have those high-level tools in that space. They don’t deal with design specs or requirements management. The thing this touches on is that there’s a golden standard in how you even begin this. You begin with the requirements management for the end product. Let’s say it is a radar or a wireless module of some sort, like a wireless handset. There, you’ll see that requirements management will have environmental specs, mechanical specs, and electrical specs for that level that it’s supposed to be. Then, as you break down that level into more blocks, each of those has specs, and eventually you get a chip back at that level.”
Striving for consistency
A decade ago, the golden spec primarily had to answer whether a block does what the architect intended? The scope was largely contained within a single die, and the teams consuming the spec were mostly within the same organization, often on the same floor.
Today, the requirements have multiplied across several axes. According to Axiomise’s Darbari, they include:
“A spec that diverges from the implementation mid-project is worse than no spec,” Darbari said.
But what does the spec define that becomes a requirement further in the flow? “That’s the whole question of requirements and definitions, and whether it is complete enough at the spec level to allow implementation and verification,” Schirrmeister said. “Then there are requirements tracing and checking against the initial requirements. Does it allow all that in the flow down?”
Schirrmeister said the tools to do this are not quite ready to automatically connect these Dynamic Object-Oriented Requirements Systems (DOORS) types of things and then trace them down. “If I now implement that in block XYZ, did I meet all requirements? AI allows us to take this to the next level of productivity, which allows us to check for a module. I have seen this in bigger companies, where people look at the specs for a block within a chip within a system, and in that spec they basically say, ‘Does that satisfy the requirements I have somewhere in DOORS or whatnot, and somewhere at the more UML-ish SYSML-ish level, and do I need all those? Now with AI, with the new levels of productivity, you can connect all those and figure out if the spec is consistent. Does my spec for this portion perhaps conflict with something that is done at the meta level as a spec that combines all of those? So spec engineering is essentially a newly emerging discipline to make sure that you see all these things and have all these things specified correctly in advance.”
This is a big leap from the days of a single, authoritative PDF handed down by a chip architect. Ten years ago, the minimum viable golden spec was a written architecture specification, a register map, and a set of waveforms or timing diagrams. Verification engineers would then write assertions and testbenches by reading that document — a manual, error-prone, and non-reproducible process.
At that time, writing high-quality specifications was more manual and more error-prone. Today, AI assists in authoring, validating, and refining specs, but also raises the bar for rigor and formalism.
“As a result, design flows are becoming increasingly spec-driven, with the specification no longer a static artifact but a central, living source that orchestrates the entire development lifecycle, fundamentally redefining both how specs are written and their role across the chip design and verification stack,” ChipAgents’ Wang explained.
As AI becomes more embedded in chip design workflows, the golden spec will need to become more executable and physically verifiable. “The question is no longer only whether a design matches a written spec, but whether engineering teams can continuously compute, reproduce, and validate the physical consequences of design decisions against trusted baselines,” said Vinci’s Radhakrishnan. “In that sense, the next golden specification will not just describe the system. It will help define a deterministic, reproducible physical baseline that can be used across design iterations, teams, and increasingly complex semiconductor ecosystems.”
Multi-die assemblies
All of this becomes more challenging with multi-die and chiplet architectures, which introduce a specification explosion problem. A monolithic SoC has one set of internal interfaces. A chiplet assembly has as many specification surfaces, as each die boundary is now potentially a standards compliance frontier. The components of a credible golden spec for such systems include die-level functional specs, interface and protocol compliance, and system-level properties.
“Perhaps the most sobering addition to the golden spec is a requirement that did not exist prominently a decade ago — a formal answer to the question of whether this is the right system to build,” Darbari said. “Spending tens of millions of dollars on design and verification only to discover during system integration that certain behaviors stall, hang, or cannot be implemented consistently across chiplets is not a verification failure. It is a specification failure at the system level. This is the distinction between verification (did we build it right?) and validation (did we build the right thing?) — and today’s golden spec must address both.”
It’s here that multi-die assemblies also begin to provide a glimpse of how verification can be scaled to specifying much larger systems, not just chips. “Everything is getting much more complicated for something like design rule checking,” Ferguson said. “It used to be a few hundred rules. Now it’s thousands and thousands of rules, billions of transistors, and hundreds of millions of wires. It’s crazy. If you expand on that and say, ‘I’m going to go into a 3D space,’ it’s even more complex. You have new materials, new stresses, issues with how to let the heat out, or at least ensure that the heat is not causing me a problem. If you’re creating a new 3D-IC, or a new kind of interconnect, now you have to add that into the requirements, and you’re back to starting with not knowing what the right answer is. I’m going to lean on the one that I’ve used the most in the past, and I hope that’s going to be correct. Ultimately, what happens if it’s not correct? We’re going to find some yield issues at a minimum, and that will turn into an iteration of going back to what the spec was that we started with. What’s the theory behind it? Was that incorrect? If it’s incorrect, we correct the spec, and we adjust accordingly moving forward. If the spec was correct and the tool was not doing what it’s supposed to, well, that’s a bug. We’re going to fix that bug, and we’re going to come back and still go forward. So at least it puts it in a situation where once, if you’re somebody doing the manufacturing, whether it’s an OSAT or a foundry, if you’re in that position, then you get stuck on what your golden is. It’s pretty rare for the golden tool to change.”
What’s needed to complete the picture is a formal requirements management system for multi-hierarchy design, which differs from functional requirements at the MBSE level, said Keysight EDA’s Mueth. “These are things that, when you do a design, you’re given a spec that is something the engineering team can execute on. If it’s a functional level description of behavior at a high-level, the engineering team will say, ‘I don’t have enough to work on. I can make something up myself, but it might not meet your requirements.’ It has to be something that would be called design, and something that you can execute on this. This is more of a problem today, especially when things are more integrated.”
Conclusion
With the pace of change, no one can confidently predict what flows will look like in two to three years. Specs, diagrams, and methodologies will have to evolve, with tooling that can re-check requirements, consistency, and equivalence as AI capabilities change.
“Specification engineering becomes the art of being precise enough to avoid misunderstandings underneath,” Synopsys’ Schirrmeister said. “How often do you have a prompt you use, and that darn thing comes back with something completely unexpected like, ‘No, you should know that when I ask this, I’m asking it in this context.’ ‘Okay, I’ll get the context of the problem correct now.’ That is the type of new art for the specification that needs to be built.”
And if all goes as planned, verification will become more manageable, verification engineers will have more confidence at sign-off, and the door could crack open a little wider to a much larger verification space.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply