Too Many Iterations? How to Avoid Three Common Problems in Semiconductor Design
Developing semiconductor intellectual property (IP), system-on-chip (SoC) designs, and complete systems is enormously challenging. Even a small error in the hardware design can require a very expensive chip turn to fix. Of course, this also delays time to market (TTM), as do any unexpected issues arising in design verification, hardware/software co-verification (also known as pre-silicon validation), and post-silicon validation in the bringup lab. Some of this is hard to avoid, due to the sheer size and complexity of today’s designs. However, there are three problems that commonly arise in the design, verification, and validation flow that can be avoided by rigorous application of specification automation.
The Imprecision of Natural Language
Every design, whether a single IP block or a room-sized massively parallel supercomputer, starts with a specification. The product marketing/management team defines the target market, talks to leading-edge customers, surveys the competition, and defines the key requirements for the product. The architecture team must then convert the description into a detailed specification from which the hardware and software teams can develop the physical product. While there have been significant advances in formal design specifications, today there is no way to completely specify a semiconductor design except with a natural language such as English.
The problem is that natural languages are inherently imprecise. Translating words into register-transfer-level (RTL) design code and programs in languages such as C/C++ is very much an inexact science. Naturally, any misinterpretation results in a system that does not operate as specified. The resulting design may not perform intended functionality, perform it incorrectly, or fail to meet performance and power requirements. Detecting these issues during verification and pre-silicon validation requires enormous resources to find them, debug them, fix them, and confirm that the fixes are correct.
The only way to get around this problem is to write specifications in a way that is precise and not subject to misunderstandings. While there is not (yet) a universal solution, there are many parts of a design that can be specified in rigorous, precise formats. Examples include registers and memories, state machines, data paths, interfaces, clock-domain-crossing (CDC) logic, functional safety mechanisms, and block interconnections. Available formats include IP-XACT, SystemRDL, state machine transitions, and spreadsheets. When your designers can write their RTL code accurately from these precise descriptions, the design is much more likely to be correct.
The Ambiguity of Natural Language
Natural languages are ambiguous as well as imprecise. There are many teams on an IP or SoC project who work from the same specification. In addition to the designers, the verification team must develop testbenches and tests, programmers must write embedded code and drivers, validation teams must run the hardware and software together, and technical writers must create end-user documentation. It is impossible for all these teams to read and interpret natural language specifications in the same way. Any inconsistencies delay TTM and consume lots of resources as the development teams figure out what’s wrong and fix it before chip fabrication.
The only way to avoid this problem is to automatically generate as many of the traditional manual files as possible. If RTL code, testbenches, and tests are all generated from executable golden specifications, there are no inconsistencies to be found and fixed during the verification process. The resulting design is correct by construction. If the drivers and embedded code that interact closely with the hardware are automatically generated along with the hardware, there are no inconsistencies to be found and fixed during pre-silicon or post-silicon validation. Not finding issues in the bringup lab means that chip turns will not compromise your project cost and schedule.
Automated generation from executable specifications, also known as specification automation, also helps with the first problem. A specification automation solution can generate RTL hardware much faster and more reliably than a designer. This saves time and resources while eliminating human errors such as typos. Similarly, generating software, verification and verification environments, and documentation directly from the specifications is faster and more accurate than manual effort.
The Evolution of Design Specifications
All the benefits outlined above would be compelling even if they only applied once on an IP or SoC project. That’s not reality; the truth is that specifications change constantly over the source of your project. Product managers continue to talk to potential customers and keep tabs on the competition, and sometimes this results in new features or requirements being added to the specifications. It is also common for implementation issues to ripple all the back to the specifications. Logic synthesis, layout, design-for-test (DFT) insertion, and other steps in the implementation process may require specification changes for resolution.
When all the hardware, software, verification, validation, and documentation files are written by humans, they must be updated manually every time that the specifications change. This introduces new opportunities for typos and different interpretations, delaying TTM as these issues are found and fixed. There is also a high likelihood that teams will get out of sync when multiple revisions of specifications are in play. Specification automation resolves the evolution problem entirely. Every time that the specifications change, the simple push of a button automatically regenerates all files for all your teams, ensuring consistency and keeping everyone in sync at all times.
Agnisys Provides the Answer
The Agnisys IDesignSpec™ Suite provides the industry’s best and most mature specification automation solution. Our suite handles all the types and formats of executable golden specifications mentioned above. It automatically generates all necessary design, verification, software, validation, and documentation files every time that specifications change. Please contact us to learn more or request a demonstration. We look forward to helping with your next project.
To get more information about how we can help you create a functionally safe system, reach out to us here.
