How to Save Time and Improve Communication Between Semiconductor Design and Verification Engineers

By Anupam Bakshi, Agnisys

It’s often said that “the secret to a good marriage is good communication” but it’s equally true that good communication is the secret to a successful IP or system-on-chip (SoC) project. Such projects are incredibly complex, with many opportunities for misunderstandings and differing interpretations. The only way to avoid these is by using shared, executable golden specifications linked by an automation process.

How It Usually Works—But Shouldn’t

IP and SoC projects involve many teams: architects, designers, verification engineers, embedded programmers, pre-silicon and post-silicon (bring-up) validation teams, and technical writers. Historically, they have all worked off a common project specification written in a natural language such as English. Every engineer on every team interprets this specification independently, manually creating the collateral files needed for the task at hand.

Natural language is inherently ambiguous, so these interpretations differ widely. That means that files created by different teams will behave differently. The verification testbench and tests may not match the hardware, the embedded code may not match the hardware, the validation environment may disagree with both the hardware and the embedded code, and so on. There may be issues even within a single team, such as two designers disagreeing on how a shared interface should behave.

Inconsistent specification interpretations are particularly troublesome on the hardware-software interface (HSI), for which the designers develop the register transfer level (RTL) hardware and the programmers write the code to control it. If there is any disagreement between their interpretations, the design will not work as intended. If these differences are not found before the design is taped out and fabricated, the result will be post-silicon bugs requiring very expensive chip turns to fix.

How Teams Try to Fix It—But Don’t

Project teams know that relying on individual interpretations of a specification is problematic, so they try to mitigate the risks. They establish online specification annotation and notes systems, bug tracking tools, scrum meetings, and other methods to try to improve communication between and across teams. These help, but they can’t compensate for the inherent weaknesses in a project flow based on natural language specification and manual interpretation.

Project teams try to detect disagreements as part of the process. Verification should, in theory, find all design bugs. Validation should, in theory, ensure that the hardware and software are working together as a system. Unfortunately, there are always gaps in these efforts. Coverage metrics intended to catch these gaps are always incomplete. The problem is especially acute for pre-silicon validation, when it’s usually impossible to run every bring-up lab test before tapeout.

Inaccurate interpretations may be an even bigger problem than inconsistent interpretations. If everyone involved in the project interprets the specification in the same incorrect way, then the design will “work” in a manner that doesn’t match its specification and the end product may miss its target. Verification and validation won’t catch such issues, which may not be found until the bring-up lab or even after the chip is shipping to customers.

Changes Make It Worse—Every Time

This whole situation would be bad enough if it happened only once on each IP or SoC project. The teams would develop their collateral files based on the specification, perform verification and validation to try to resolve differences, and fix what they missed with a chip turn—if the whole project isn’t canceled at that point. However, the annoying reality is that every specification changes many times over the course of a project.

There are several reasons for this. Sometimes what the architects dreamed up is too hard or costly to implement in silicon. Functionality may move back and forth across the HSI. Competitive offerings or emerging market opportunities may require that new features be added to the design. Resolving issues with design power, performance, and area (PPA) may require changes that ripple all the way back up to the original specification.

Whenever a specification undergoes a manual change, every project team must interpret that change, assess the impact, and manually update their files. This offers entirely new opportunities for misinterpretations and differing interpretations. Updates can be out of sync as well. Verification and pre-silicon validation must be repeated on the changed design, adding enormous cost to the project and delaying tapeout. This happens for every change. Every. Single. Time.

How It Should Work—and Can

There is a better way, and it involves three key changes to the chip development flow:

• Using an executable golden specification rather than a natural language specification
• Generating as many design, verification, software, validation, and documentation files as possible automatically from the executable specification
• Repeating this process for every specification change

“Specification automation” is the industry term for this approach. There are numerous executable specification formats available, and artificial intelligence (AI) has even made it possible to use natural language for certain aspects. Tools can automatically generate a wide variety of files from the specifications, both initially and every time that a specification changes. Verification and validation becomes a much faster process since there are no inconsistencies to find and fix.

The executable specifications themselves become the vehicle for communication among all the project teams and engineers. The result is an IP or SoC design that is correct by construction, consuming far fewer project resources and enabling a much faster tapeout. All this is fully achievable today with the Agnisys IDesignSpec™ Suite of products. Agnisys pioneered the domain of specification automation and is the clear industry leader.

Conclusion

Project engineers no longer have to manually interpret specifications and rely on informal methods to communicate among themselves about how the design should work and how changes impact it. An automated flow based on executable golden specifications saves project time and provides smooth communication. Every SoC and IP development team can easily adopt the Agnisys solution and share in these benefits.