Has a chip ever been released that was entirely free of design errors? Not likely. Although today’s design teams are expected to meet the demand for ever more efficient and powerful ICs, the individuals on these diverse and disparate teams are mere mortals, and not superhuman, despite ever expanding expectations. 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 acknowledge the significant difference between a show-stopper bug that can’t be fixed without a chip turn versus a minor issue that can be resolved by a software workaround with 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.
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 thesestatistics 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. This issue is compounded as multiple teams read and interpret the same specification. RTL designers, verification and validation engineers, embedded programmers, lab bring-up teams, technical writers, and others are involved.
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.
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 within production programs. In fact, we’re able to generate documentation of such high quality that technical writers can include it in their user manuals. Because all these files are generated from the same specification, they are always consistent. This eliminates whole classes of bugs due to 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 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.