Expanding the Scope of Specification Automation
Late last year, I published a blog post that summarized what had transpired for Agnisys over the course of 2021. That was an occasion to think about how much our company and our products have expanded over time. A few weeks ago, as we prepared material for the virtual DVCon event, I again considered how much has changed for our customers and for us over the last few months. I also recalled that it was only about a year ago when we took a high-level view of our overall solution and published the following diagram in one of my posts:
For the first time, we captured a complete view of our solution for specification-driven automation. The key is capturing as much of a system-on-chip (SoC) or IP specification as possible in executable formats and then generating as much as possible from these specifications automatically. This saves a lot of schedule time and manual effort in the early stages of a project and continues to save even more every time the specification changes. This diagram shows executable specifications for registers and memories, custom sequences, and SoC-level connections, plus a library of IP for standard functions and interfaces.
From these inputs, our tools automatically generate the register transfer level (RTL) design, models and sequences for testbenches complaint with the Universal Verification Methodology (UVM), C/C++ headers and code for drivers and other low-level software, and high-quality documentation. Every team on the project received and benefits from the generated files. The RTL code becomes part of the hardware design, the UVM files are incorporated into the verification testbench, and the C/C++ code runs in verification, pre-silicon validation, and post-silicon validation in the bring-up lab. The generated documentation is used by all teams to ensure consistency and is often incorporated by technical writers in user guides, user manuals, and other product documentation.
Of course, the story did not end there. In addition to adding dedicated support for field-programmable gate array (FPGA) designs, we have expanded our solution twice over the last year. The first major enhancement, as I discussed in a blog post last fall, was generating properties complaint with the SystemVerilog Assertions (SVA) standard. These are generated along with the other files from input specifications and from our IP library. These properties can be executed by the verification team in the UVM simulation testbench, and they can also drive formal verification tools, sometimes run by designers and sometimes by the verification engineers.
We announced the second major expansion of our solution just before the Design Automation Conference (DAC) in December, and it was covered very nicely by SemiWiki. This is our first use of artificial intelligence (AI) and machine learning (ML) as part of our solution. We now generate custom SVA properties in addition to those we already had available. What’s novel and highly unusual is that the specification format for the assertions is natural language, specifically English. We found that our users tend to think about design intent in natural language, such as “if signal B goes high three cycles after signal C goes low, signal A should be asserted” or “the arbiter’s GRANT signals should be one-hot.”
Our engineers created iSpec.ai, an AI/ML-powered technology that can translate English statements of design intent into SVA. Because ML applications learn by example and get better over time as more types of examples are provided, we fed many different types of descriptions into iSpec.ai and made sure that the generated properties were correct. However, given the wide range of expression available in English, we wanted even more examples. We set up iSpec.ai as a crowd sourced site where anyone can try converting their descriptions automatically into SVA.
Perhaps I’m being a bit premature in making this update, since iSpec.ai is still an evolving technology that will get even better as more engineers try it and the ML algorithms learn from the results. But what we have available today is quite robust and the feedback from users has been very positive. I encourage you to go to the site, submit some English descriptions, and try using the SVA we generate. We also generate English descriptions for existing SVA, which is valuable to understand assertions in licensed IP or inherited code.
I can assure you that the story is not over and that our solution will continue to evolve. We’re already working on adding more specification input formats and generating more types of code to benefit IP and SoC project teams. There is so much more than we can accomplish and so many ways that we can provide even more value to our users. Please continue to read this series of blogs and monitor our website to keep tabs on our progress. The future of specification automation is very bright indeed.
