Hardware From Specifications Using AI

There is a lot of excitement these days surrounding the idea that AI could make it possible to go from a specification to a design with absolutely no hardware skills. Well, get in line, because this is the umpteenth potential technology that was going to make that possible.

Don’t get me wrong, it just might do it, but will this be an implementation that is reliable, have decent performance, use the minimum possible energy, be secure from hacks, work under extreme conditions, be cost effective — and have all the software necessary to turn it from a piece of silicon into a viable product?

Thirty years ago, I worked on products that were designed to go from a specification, enable hardware/software partitioning onto a predefined platform, and then enable the hardware to be synthesized and implemented using an enhanced flow starting out with high-level synthesis. And I was not alone. Most of the major EDA companies and many of the leading-edge semiconductor companies were behind this effort and a lot of money was poured into it. We can only see a couple remnants of that today — high-level synthesis (HLS) and virtual prototyping.

Two things railroaded the effort. First, it was the same time that notions of IP were entering into the picture. This meant that not all of the design would start from a specification that had to be implemented. Instead, a significant portion of the problem became one of selection and integration. This new methodology finished up being very successful and significantly reduced design times, even though its impact on verification was much less. This is why teams now spend more hours on verification than on design.

The second issue was a lack of models. To build a virtual prototype you needed verified models at the correct level of abstraction and the appropriate performance. Those three words — models, abstraction, performance — pretty much killed the efforts, even though some do survive and are doing quite well within limited-scope applications. The key is that abstraction and performance are opposing concepts. To get performance you have to give up something in terms of abstraction, and vice versa. But the more abstract you become, the greater the potential gains have to be, such that fidelity of results does not mean that your noise is greater than your signal.

The next effort was an extension to high-level synthesis, which could take software and create hardware from it that could be implemented in FPGAs. It was thought that this would increase the number of hardware developers by a hundredfold, and software engineers would be able to do this without a lot of hardware knowledge. It was thought that any hardware, no matter how inefficient, would still be better than software running on a single-threaded CPU. The problem was that the solution was expensive. It was not that easy to integrate the FPGA with the CPU, which was still required to run the pieces that couldn’t be turned into hardware. And the context switch times between them often exceeded the speedup that was gained.

AI does have a few things going for it. The first is that it may be able to quickly and accurately generate models with the correct abstraction for the task at hand. That ultimately means many models, each with a different set of characteristics. One model to do architectural analysis, a different model for performance (timing, power, etc.) analysis, and yet another model that can be used for verification. The cost of doing model validation is high, and if this cannot be significantly reduced then it is a non-starter.

The next thing is that systems these days are software-centric. Even custom CPUs start with the application they are meant to run and look at how the CPU can be tailored to the workflow. Unlike the FPGA solution, this is an extension of the processor that targets frequently executed code and is tightly integrated, meaning there is no context switch. It can thus target much finer granularity of acceleration. But every such processor still has to be verified, and as already mentioned, this takes more time than design. So by Amdahl’s Law, it has smaller gains in terms of development costs than may have been expected.

But I hear you say, AI will make it correct by construction, meaning you don’t have to do verification. My response: I have never in my whole career seen a specification that is complete, correct, and unambiguous. Tell me you are prepared to go to silicon without performing verification and I will run for the hills, far away from your product. This is the biggest problem, and I do not see any indication that this will be solved in the near future.

Let’s go back to the demise of ESL. It was about IP. AI has a good chance to do IP selection and integration. The IP blocks have been pre-verified, and while you still need to do some level of integration verification, this might be manageable. It is even possible that small chunks of it could be run through HLS to put in some custom algorithms or acceleration. The HLS flows do have some fairly advanced verification built into them, including sequential equivalency checking to ensure that what was generated by the tool matches the input specification.

But you still have to find out if the specification is correct, and you cannot use the same tool to do it that was used for design. Verification is about comparing two things so that you can find the differences.

Whenever I hear someone say it will be possible to generate hardware using AI, I first want to find out about their expectations, the limitations they are willing to consider, and the business model that goes along with the product they want to make. After that discussion, I may be willing to admit that the venture stands a chance, but I don’t think we are there yet for many cases. How long before we get there? No one knows for sure.