What’s New and What’s Next in Specification Automation?

Over the last few months, I’ve primarily shared two kinds of posts on this blog. The Design Automation Conference (DAC) in December and the transition to the New Year prompted me to look back at how much Agnisys has expanded the power and reach of specification automation, a domain that we pioneered more than a decade ago with our register automation solutions. We have found that there are many parts of a system-on-chip (SoC) design that are amenable to automatic generation of hardware, software, testbenches, tests, and documentation from executable specifications.

Of course, we’re never standing still and so I’ve also written posts covering new products and features as we’ve made them available to customers. In some cases, I’ve passed on exciting news such as last month’s announcement that our complete IDesignSpec™ Suite has been certified as compliant to the ISO 26262 and IEC 61508 functional safety standards. I find that this blog is an informal and convenient way to share information I think users will find interesting, and I hope that you feel the same.

You may be wondering where we go from here. In today’s post, I’d like to connect two threads related to my recent posts and mention some new areas of specification automation that we’re investigating. Let’s start with ISO 26262, since there are really two key aspects of supporting this standard. The first is the assessment by the independent testing and inspection organization TÜV SÜD. After a detailed investigation into our company, our development process, and our products, they certified that we meet the stringent requirements of this standard.

If you are designing or verifying chips for automobiles or other road vehicles, you can use our products in your development flow without the need to qualify them yourself. This makes it easier to satisfy the demands of your customers who insist on ISO 26262 compliance. Vehicular electronic designs have all the same elements as any other chip: registers, sequences, buses, etc. Thus, you can benefit from our specification automation solutions while remaining compliant to the standard. In that respect, you might think that you use our tools just as anyone would.

However, there is a second aspect that is equally as important. Automotive designs must operate safely in the presence of faults that could compromise functionality. These must be detected and either corrected or handled with appropriate responses. Over the years, the industry has developed a variety of methods to meet this requirement. As I discussed in another recent post, our tools generate all the logic needed to implement these methods as well as the code to check their operation as part of design verification and during self-test using the embedded processors in your fabricated chip.

Examples of safety logic include parity bits, error-correcting-code (ECC) logic, cyclic redundancy check (CRC), and majority voting for triple module redundancy (TMR). These techniques are widely used in all sorts of safety-critical designs, from tiny implanted medical devices to massive nuclear power plants. Designers for all these applications benefit from our functional safety specification automation, but developers of automotive chips get double protection. We can insert safety logic that meets the requirements of ISO 26262 while using tools that are certified as ISO 26262 compliant.

Another thread that I’d like to connect is natural language generation of assertion and sequences. At DAC, we debuted iSpec.ai, which uses artificial intelligence (AI) and machine learning (ML) technology to translate English statements of design intent into SystemVerilog Assertions (SVA). I think that this is a cool technology, and a lot of users who have tried it seem to agree. It is one of the first concrete results of our work to bring AI/ML-enabled tools into our specification automation flow. We see great promise in this area and anticipate that it will transform our user experience.

I’m excited to let you know that we just expanded our www.ispec.ai site to include automatic generation of programming sequences from English descriptions. You can type in something like “Update the values of all the fields of register Sbcs with value 0x1 and then monitor the field Sberror” and see the result in an abstract sequence. This makes it easy to check the results, and then you can use our IDS NextGen™ solution to transform this sequence into SystemVerilog code for your Universal Verification Methodology (UVM) testbench and C code for your embedded processors.

We actually developed this sequence technology before assertion generation, but it was previously available only within IDS NextGen. We have made it available to everyone on the iSpec.ai site because we believe that the ML algorithms will benefit from crowdsourcing just as our SVA generation technology has. The more diverse examples from a wide range of users, the broader our solution will be. We are looking into several other areas where it might be possible to use natural language as the front end for specification automation.

So, where do we go from here? We have lots of ideas that we are already working on. We have seen that graphical design entry systems have never really taken off. For example, there have been many tools that allowed you to specify state machines and block interconnections in a graphical editor, but most designers still write SystemVerilog or a textual specification format. Would natural language be a good way to specify a state machine? What about a bus protocol, or a processor instruction set architecture (ISA), or a floating-point unit (FPU)? We would love to hear what you think, either by commenting on this post or contacting your Agnisys rep.

Thank you in advance!

One thing is for sure, a lot of help is coming to fundamentally change how design and verification is done. Agnisys hopes to be leading that change.