Has a chip ever been released that was entirely free of design errors? Not likely. While today's design teams must fulfill the demand for efficient ICs, the individuals on these diverse teams, though not superhuman, make mistakes in coding RTL designs and miss things during verification. Consequently, mistakes are made when coding register-transfer-level (RTL) designs and things get missed during verification. While completely eliminating errors may be a lofty goal, at Agnisys, we pursue it with relentless passion.
Winner of the “BBVA Foundation Frontiers of Knowledge Award in Information and Communication Technologies,” Alberto Sangiovanni Vincentelli, a Professor at the University of California in Berkeley, was acknowledged earlier this year for his outstanding contributions which led to the birth of the electronic design automation (EDA) industry – an industry devoted to the development of new tools, technologies, and methodologies aimed at addressing the burgeoning problems of the modern semiconductor industry.
Today, EDA companies are doing their best to reduce the number and severity of errors. At Agnisys, we recognize the distinction between a show-stopper bug requiring a chip turn and a minor issue resolvable with a software workaround and minimal performance impact. Those of us in EDA are working diligently to reduce your burden and address your challenges so you can focus on delivering ever more complex chips and IP (intellectual property), to better meet the discriminating (yet often fickle) needs of today’s highly competitive marketplace.
The Trouble with Specifications
Because we understand the pain felt by our customers, at Agnisys, we’ve placed our laser focus on specification automation. Having done so, our customers frequently tell us we have the broadest solution in the industry.
There are several reasons why we chose this particular focus. It turns out that incorrect specifications, and incorrect or divergent interpretations of specifications, are major sources of chip bugs. This has been demonstrated over the years by anecdotal evidence as well as formal surveys. A short list of particularly noteworthy news items from the past few years, such as “Tiny Chips, Big Errors,” “Tiny Chips Cause Giant Error Correction Challenges” and “FYI: Today’s computer chips are so advanced, they are more ‘mercurial’ than precise – and here’s the proof” only further support what we all know to be true about the trouble with IC specifications: they pose a serious impediment to the delivery of today’s increasingly complex chips.
One key point of reference is the Wilson Research Group Functional Verification Study, which has been sponsored every two years by Siemens EDA (formerly Mentor Graphics) for some time. Harry Foster, Chief Scientist Verification for the Design Verification Technology Division of Siemens EDA; and Co-Founder and Executive Editor for the Verification Academy, does a nice job summarizing the results, with these statistics from the 2022 study highly relevant to our discussion:
- Incorrect or incomplete specifications are the root cause of more than 55% of functional flaws in field-programmable gate arrays (FPGAs)
- Changes in specifications are the root cause of more than 50% of functional flaws in FPGAs
- Incorrect or incomplete specifications are the root cause of more than 45% of functional flaws in application-specific integrated circuits (ASICs)
- Changes in specifications are the root cause of more than 40% of functional flaws in ASICs
There are three big reasons that specifications cause so much trouble. First, most are written in a natural language, such as English, which is inherently imprecise and ambiguous. An engineer reading the text may not interpret it correctly. Multiple teams, including RTL designers, verification and validation engineers, embedded programmers, lab bring-up teams, technical writers, and others, compound this issue as they read and interpret the same specification.
These teams may interpret the specification differently. Not surprising, given its imprecision. This leads directly to design errors, as when two designers implement a shared interface inconsistently. It also results in unnecessary debug work and delays the project schedule, as when the testbench coded by the verification team doesn’t align with the RTL hardware. Different interpretations by the programmers and the designers create problems all the way into field usage by customers just as highlighted by the news items I had cited above.
The third big issue is that IC specifications evolve constantly over the source of the project. Even if every team somehow interprets the text the same way, every specification update ripples to changes in the hardware design, verification and validation code, embedded programs, and documentation. Regrettably, every such iteration consumes precious project resources and can lead to new opportunities for divergent interpretations and resultant bugs.
Delivering Industry-Leading Specification Automation
We’ve chosen to focus on specification. This is why we developed our IDesignSpec Suite: to eliminate IC specification imprecision, differing interpretations, and manual iterations. As the EDA industry leader in specification automation, we’re enabling you to specify your IC design in executable, unambiguous formats, and then automatically generate the greatest number of chip-related files available in the market today. Our solution generates the RTL code directly from the specification, producing an IC design that is correct by construction.
But we don’t stop there. Agnisys also generates models and test sequences used for verification, as well as embedded code used in validation, the bring-up lab, and production programs. In fact, we’re able to generate documentation of such high quality that technical writers can include it in their user manuals. As all these files originate from the same specification, they maintain consistent coherence. This eliminates whole classes of bugs due to the manual interpretation of ambiguous text documents.
Best of all, you get these same benefits many times on your project. Each time your specification changes, you just push a button to automatically re-generate all the output files (i.e. synthesizable RTL, UVM RAL, C headers, and documentation), updated as needed to reflect the changes. There’s no manual effort involved, and the files used by every team remain synchronized and consistent. Thus, we directly tackle and eliminate two major causes of functional flaws as reported by the Wilson survey.
You can specify much of your IC—registers, memories, programming sequences, state machines, data paths, inter-block connectivity, and more—in the executable format today. And because we listen closely to our customers, and develop in anticipation of their needs, we’re always adding new capabilities and supporting additional design styles. Once you have the specification, you can automatically generate all the files mentioned previously, and update them instantly whenever you change the specification.
Driving Towards First Silicon Success
Like you and your chip design teams, we’re mere mortals, and therefore, unable to perform miracles. Consequently, you can’t (yet) write a single specification for an entire system-on-chip (SoC) from which we generate all hardware and software. However, we’re constantly innovating to expand the scope of our solution. One particularly active area is the use of artificial intelligence (AI) and machine learning (ML) to infer more information from specifications in a wider range of formats, including some natural language. If you are interested in this space, please visit ispec.ai.
Make sure to watch this blog as I keep you posted on our evolution and report on case studies from actual customers willing to share their real-world experiences. While we may never learn how to release chips entirely free of bugs, we do know how to eliminate some of the major root causes of bugs, greatly increasing the chance for you to have first-time silicon success. But don’t take my word for it. Contact us today to request a demonstration or schedule a solution discussion with a member of our team to see how working with Agnisys can improve your design and reduce errors.
There are multiple causes for design errors, but some of the most common are related to the design specifications and how they are distributed and maintained throughout the product development lifecycle. Learn how to address this issue by reading The IC Designer's Guide to Automated Specification of Design and Verification, for Better Products.
