AI for EDA for AI

I’ve been noticing over the last few years that electronic design automation (EDA) vendors just love to talk about artificial intelligence (AI) and machine learning (ML), sometimes with deep learning (DL) and neural networks tossed in as well. It can get a bit confusing since these terms are used in two distinct contexts. The first is the use of EDA tools to develop chips for AI applications, which are some of the largest and most complex designs being developed today. Of course, self-driving cars and other autonomous vehicles are the most popular examples. It’s easy to see why; being able to replace human drivers and all the multi-faceted decisions they make requires a ton of powerful AI software running on specialized hardware. The system must be optimized for image recognition, ML, natural language processing (NLP), real-time responses, and more. AI shows up other applications as well; speech recognition in particular is everywhere.

I guess that’s obvious, but the other context is the use of AI techniques within EDA tools. That is not as widely known despite the tendency of EDA vendors to trumpet such usage. At times I’ve wondered if it’s all a lot of hype to jump on the AI bandwagon, but at this point I think it’s clear that there are at least a few, and perhaps many, places in the EDA sphere where AI and ML really do apply. For example, vendors have announced implementation tools (logic synthesis, floorplanning, and place and route) that use ML from past projects and the results thus far on the current project to improve chip power, performance, and area (PPA). In addition, AI-based recognition of error signatures can speed debug of failing tests during chip verification. Just before DAC, another example caught my attention: Agnisys announced the use of AI to translate English descriptions of design intent to SystemVerilog Assertions (SVA), and vice-versa. I had not heard of AI/ML being used for this purpose before, so I decided to learn more.

The first thing that struck me was that the press release announced a “technology” and not a product. It sounded as if the translation was available to anyone at iSpec.ai so I checked it out. I was pleasantly surprised to find the site just as advertised. Users can type in some English text and push a button to generate SVA or enter some SVA code and generate the English equivalent, and then provide feedback on the results. I don’t claim to be an assertions expert, but I tried some English examples and the underlying algorithms seemed to handle them just fine. I wondered why an EDA vendor would offer this site for free rather than charging for the technology in a product, so I asked Agnisys CEO and founder Anupam Bakshi for more information.

Anupam described this as a crowdsourcing site and said that they made it free and open specifically to gather many different examples of how engineers think about design intent and describe assertions in natural language. He said that they performed initial training on the algorithms using assertion examples gathered from many sources, including an industry expert who literally wrote the book on SVA. But they knew that this would not be enough to create a robust technology that users could rely on, so they created the site and announced its availability to their users. Their R&D engineers carefully studied all the examples provided and, especially when users provided feedback that the results were not perfect, provided guidance to the tool as needed to learn from these additional examples. By the end of this process, they were comfortable letting everyone try it out. Anupam remarked that the technology is not yet “done” and that it will continue to improve in capacity and flexibility with additional crowdsourcing and lots more diverse examples.

Having said that, he stressed that what’s available now is powerful and valuable. He pointed out that the developers focused on robustness, necessary given the inherent ambiguity of natural language. He demonstrated the resilience of the algorithms by typing in a bunch of examples with typos in the English text, and the generated SVA was still correct. I was impressed that typing “onenot” instead of “onehot” and “bicycles” rather than “cycles” didn’t cause confusion; I guess that’s truly intelligent AI in action. It seems to me that iSpec.ai will be immediately useful for many types of assertions. I won’t yet go as far as to predict that users won’t have to learn SVA at all, but that seems like an entirely possible outcome as the technology matures further.

Users who do want to learn and write SVA will doubtless benefit from the translation in the opposite direction, using the generated English descriptions to double-check that their assertions specify what they intended. Anupam mentioned two additional uses: understanding and documenting existing assertions. Engineers often license IP blocks or inherit designs from other sources, and these may contain SVA that they didn’t write. Translating them into text could help the users to figure out what these assertions do. This process could also be used to document assertions, whether self-written or inherited, in verification plans and specifications.

I found this whole topic fascinating, and I suggest that everyone interested in assertions visit iSpec.ai and try some examples. I think you’ll be impressed and, if you do fool the AI with a novel way to express design intent, just provide feedback and rest assured that the Agnisys team will use your clever example to enhance and expand the technology for the benefit of all users. That’s what crowdsourcing is all about. Have fun!

Also read:

What the Heck is Collaborative Specification?

AUGER, the First User Group Meeting for Agnisys

Register Automation for a DDR PHY Design