How to Make Your Specifications Golden
When we started providing specification automation solutions, we focused on supporting as wide a range of formats as possible. Now that we have introduced our IDesignSpec™-AI (IDS-AI) solution, we even handle natural language specifications for specifying your system-on-chip (SoC) and IP designs. You can choose something simple and unstructured such as a text document, PDF, HTML page, or Markdown file. You can also represent your specification in a structured, inherently machine-readable format such as SystemRDL, IP-XACT, YAML, or XML With the wide range of options that we support, you don’t need to worry too much about which formats you choose. But you do need to ensure that your specifications meet the requirements to be considered golden.
The Importance of Golden Specifications
The whole purpose of your specifications is to capture the architecture and intended behavior of your design. From this, our tools generate a very wide range of files for design, verification, programming, validation, test, and documentation. This process works best if you use golden specifications in your project flow. A golden specification provides a single authoritative source of truth for your complete SoC architecture and its intended behavior. All your project teams rely on shared golden specifications for many aspects of their jobs.
Not every specification is golden, perhaps because it does not have a high enough level of quality. It might be written for a single team and inappropriate to be shared across your project. To fall back on a cliché, all specifications are not created equal. Further, even excellent, high-quality specifications are not truly golden unless they are treated appropriately by your teams. This post considers several key attributes of golden specifications, including completeness, unambiguity, precision, consistency, accuracy, accessibility, and traceability.
Capture the Complete Design Architecture
Golden specifications must capture the complete architecture of your SoC design. This includes IP blocks; custom design components; design hierarchy; buses, networks on chip (NoCs), and other inter-component connectivity; clocks and resets; memories and register sets; and external interfaces. This information may all be within one file, or spread across multiple files in different formats. What’s important is that the complete set of specifications contains all the architectural elements of your design. There should be nothing outside your specifications and no gaps that could lead to missing information in the files we automatically generate from your golden specifications.
Specify in an Executable Format
In the past, executability has meant using only strictly defined, machine-readable formats such as SystemRDL. With the emergence of AI, natural language can also be used for executable specifications. However, flexibility in formats does not imply that absolutely anything is executable. For AI to make any sense of specifications, the engineers writing them need to follow all applicable syntactic and semantic rules. Everything in the specification should be parseable, including FSMs, look-up tables, interrupt tables, sequences, and connectivity diagrams. When natural language is used, it must be written in a way that minimizes ambiguity and reduces the chances for misinterpretation.
Be Unambiguous and Precise
Every architectural requirement should have a clear interpretation. Gathering information from golden specifications should not depend on assumptions or undocumented knowledge. It is also vital to eliminate ambiguity. This is not an issue for standard formats that are designed to be machine readable. Natural language is inherently ambiguous, so you should write in a way that keeps generative AI (GenAI) from having to guess. If you mean for the word “or” to be an exclusive-or, use the English “either/or” construct to make this clear. Any ambiguity or imprecision creates problems for all tools reading the specifications and prevents them from being truly golden.
Be Consistent and Accurate
Specifications must be non-contradictory and consistent across all aspects of the architecture and design. This is equally true for specifications than span multiple files for formats since the chance of errors is higher. Accuracy is just as important as consistency. Every part of the specification must be fully aligned with the true design and functional intent. Since code is generated from golden specifications, specification review should be just as rigorous as traditional code reviews. Senior architects and design leads should sign off on all golden specifications to ensure that they accurately represent the design that is intended.
Make Specifications Accessible
Because golden specifications are shared by all project teams, they must be accessible to everyone. The specifications must contain sufficient information to support design, verification, validation, integration, firmware/software programming, and other downstream activities. Each team must be able to generate its necessary files from the same single source of truth. When specifications are updated, they must be propagated to all teams at the same time so that generated files are always consistent. Chasing down regression failures because the testbench and the RTL design were derived from different versions of the specification is a huge waste of time.
Provide Traceability
There are several dimensions to this attribute. Architectural requirements should be traceable from the original intent through the specification and into hardware and software implementation, verification, and validation processes. In addition, the project team must ensure traceability from each generated file back to the version of the golden specifications and the specific tools used. This is good project management discipline, but in addition this type of traceability is required by many industry standards for robust development and functional safety. Many customers will not design in a new SoC that did not follow the specific rules and guidelines of the relevant standards.
Control Changes and Versions
Golden specifications must be version controlled, with clear documentation of any changes for each revision. This is necessary so that teams can assess the impact of changes and know exactly which specification version they should be using. Meeting the accessibility goals described above requires a robust versioning and propagation process. Every architectural change must be identifiable, reviewable, and traceable. Golden specifications must have clear ownership and a defined mechanism for approving changes, including a detailed review process like the one used to ensure consistency and accuracy.
Conclusions
It’s not simple to ensure that your SoC or IP design specifications have all the attributes to be considered golden. However, the effort is clearly worth it. You can use IDS-AI to generate files for all project teams automatically and consistently. You can update all these files immediately and uniformly whenever a specification changes. This saves significant project resources, accelerates closure, brings in the tape-out date, and shortens your time to market (TTM). Please ask your Agnisys representative or contact us to learn more.
Join Our Upcoming Webinar on Golden Specifications
How can golden specifications help accelerate IP/SoC development and improve design quality? Join our upcoming webinar, “How Does Golden Specification Lead to Faster, Higher-Quality IP/SoC Development?” to explore how IDS-AI™, our Agentic AI solution, brings intelligence and automation to the chip development process. The session will introduce the different AI agents within IDS-AI™ and demonstrate how they help structure design intent, identify missing or inconsistent specification information, automate key tasks across RTL generation and verification, and support a more efficient specification-driven workflow. The webinar will also feature live demonstrations of the Extract Agent and Spec Check Agent.
This is the first webinar in our IDS-AI™ series, followed by dedicated sessions exploring individual agents and their applications in chip development.
Date & Time: October 29, 2026 & 10:00 AM PST
Register now to discover how Agentic AI can help improve specification quality and support faster, higher-quality IP/SoC development.
