AI RTL Generation versus AI RTL Verification

I should admit up front that I don’t have a scientific answer to this comparison, but I do have a reasonably informed gut feel, at least for the near-term. The reason I ask the question is that automated RTL generation grabs headlines with visions of designing chips through natural language prompts, making design widely accessible. No doubt this has a lot of media appeal, an attractive place to invest AI $$. But the realities of chip design today don’t support that bet and are more aligned with investment in AI-assisted verification. Verification may not be as glamorous as design but looks like a much more compelling target for AI investment today.

Where are the real costs in design?

Years of analysis in the semiconductor industry (e.g. this Wilson report) confirm that on average 50% or more of IC/ASIC project time is spent in verification. Projects require as many verification engineers at peak as design engineers (the people building RTL) and even design engineers spend half their time in verification. Verifying RTL is a major time- and resource-consuming sink in chip design.

That verification far outweighs RTL design should not be surprising in an age where IP reuse and design reuse dominate. Few organizations have the luxury to start from a clean sheet on each design. Even startups will use commercial IP. Silicon Catalyst portfolio companies can tap into a wide range of IP, from Arm for example, at no up-front cost. There will always be some differentiating content requiring from-scratch development or extensive redesign but the hard part there is the innovation and making the idea practical in a competitive PPA envelope, not in creating the RTL.

Challenges for RTL creation

I can’t find a definitive “first” paper on using GenAI to create RTL but there are plenty of recent papers. These continue to show progress, at about the same rate as parallel efforts in software generation, intriguing but not up to hands-free usage.

More common is usage as an assistant – think of an extended auto-completion operation. A designer might describe in a comment what a following always block should do and ask the auto-completer to create that block. An emerging measure of how successful that operation is in practice, whether for RTL or software, is the rate at which the designer/programmer accepts the generated logic. Fairly consistently this seems to be around 25%.

25% is not bad for an autocompleter. How often do you accept an MS-Word or text message autocompletion? I don’t most of the time, but sometimes it’s useful. RTL auto-completion is more complex than sentence completion, so hats off to RTL generators for getting this far.

Why isn’t the acceptance rate better? There are multiple reasons. Lack of a sufficiently broad training corpus and ambiguities in the comment prompt are two obvious examples. Another revealing example is that, without additional coaching, a bot will assume the timing depth of an expression depends on the number of terms in the expression, not recognizing that arithmetic expressions are more costly than logic expressions. For some other examples see this paper.

The core problem is that generating quality RTL is a lot more complex than current systems can rise to, even for an always block. Does it support PPA targets? Does it create security or safety holes? Is the implementation intuitively reasonable and is it readily maintainable by an RTL designer?

Could more of these problems be solved in time? Quite possibly, which is why I think RTL creation moonshots are worth supporting. But we shouldn’t confuse those efforts with near-term ROI.

Opportunities in RTL verification

A big opportunity for return should be in debug, representing 47% of verification effort according to the same Wilson report. Despite years of study, in debug we still haven’t advanced far beyond debugger IDEs, which certainly help visualize behavior but do little to triage or root-cause bugs in aid of compressing debug time. (there are some point solutions, e.g. for triaging CDC violations.)

Promising signs can be seen in agentic approaches to debug, from startups like ChipAgents and Bronco AI. Triage – reducing and assigning a pile of bugs from a regression to sub-teams for further analysis – might be the biggest contribution here. As engineers we tend to obsess about how to automate root cause analysis for hard corner cases, but more effort is likely consumed in triage around the bulk of less complex bugs than in a few anomalous cases. Initial root-cause isolation (did this error come from module A or module B) can drill down to approximate fault locations, to avoid wasting engineer time on trying to debug a problem that isn’t in their code after all.

Agentic methods should be ideal for this sort of analysis for two reasons. First they can learn from expert engineers how they would approach triage and rough root-causing. Second, because they are agentic they should be able to run additional trial simulations to confirm or rule-out preliminary guesses.

This approach to debug builds on verification know-how and methods that have been in refinement for years. Success here, even partial success, could show significant ROI. Contrast that with an as-yet unquantified level of investment to improve RTL generation quality, where we also don’t know what value we can assign to partial success.

Food for thought.

Also Read:

Scaling Debug Wisdom with Bronco AI

CEO Interview with David Zhi LuoZhang of Bronco AI

ChipAgents Tackles Debug. This is Important

CEO Interview with Dr. William Wang of Alpha Design AI

Share this post via:

• 
• 
• 
•