Three Key Aspects Of IP Quality

It’s no secret that today’s huge system-on-chip (SoC) projects require massive amounts of design reuse. No team, no matter how talented, can design a billion or more gates from scratch. They use extensive borrowing of RTL code from previous and related projects, plus hundreds of thousands of instantiated IP blocks from internal libraries, open-source repositories, development partners, and commercial providers. Not all IP blocks are equally reusable; far too many have lingering bugs and limitations. SoC integrators have every right to expect—and demand—that IP developers produce high-quality designs.

There are three main dimensions to IP quality. The most obvious is functional correctness: the design must do what its specification promises and be complaint with any relevant industry standards. This requires a sophisticated simulation testbench and tests, almost always built on the Universal Verification Methodology (UVM), that achieve high coverage. A comprehensive set of properties (assertions), proven by formal verification, is highly desirable as well. The IP provider must employ a robust verification process combining at least static checks, formal analysis, and simulation, possibly augmented by emulation or FPGA prototyping, and document the coverage achieved to the IP user.

Quite often, the IP provider includes the testbench, tests, properties, and run scripts along with the RTL design and user documentation to deliver a complete IP package. This enables users to run out-of-the-box tests to watch the IP design in use, which can be a very effective way to understand it better. Some components in the IP testbench are relevant at the full-chip level, so the SoC verification team can integrate these into their top-level testbench. Assertions can nearly always be reused at higher levels, including the full SoC. If the user makes any changes to the IP RTL code, the testbench components, tests, and assertions may need modifications as well to reflect the altered or enhanced functionality and to ensure functional correctness of the final design.

The other two dimensions are less obvious but also highly important. One is IP robustness, which has several aspects. The design and verification code must be capable of running efficiently in any commercial simulator and the properties must work in any formal verification tool. The RTL code must be acceptable for logic synthesis tools and mappable to any target silicon technology meeting the desired power, performance, and area (PPA) results. The code must not contain any troublesome language constructs that could cause unexpected behavior or make it hard for the IP user to modify and customize the IP block without unintentionally breaking its functionality.

Any changes to the code demand the final attribute: IP readability. If the IP user can’t comprehend the code, it’s impossible to add new features or delete features not needed for the SoC’s target applications. Even if no IP changes are made, debugging chip-level verification test failures may require understanding what is happening inside the IP block. Generous and informative comments are part of the solution, but there is more that the IP provider can do to help. Using standard coding styles, appropriate variable names, and consistent formatting makes both design and testbench code much more understandable and maintainable.

The IP user documentation is effectively part of the readability attribute. Some aspects of the design that may not be readily discernible from the RTL code can best be explained using words in a user guide. The documentation must describe how the user hooks up the IP block and integrates it into the SoC. The IP provider must ensure that the documentation is fully consistent with the design and that it is updated as the design evolves and new features are added. One increasingly popular way of accomplishing this task is automatically generating some or all of the user documentation from the IP design, often guided by pragmas (special comments) embedded in the RTL code.

Fig. 1: Key aspects of IP quality. Source: AMIQ EDA

All three aspects of IP quality can be delivered more easily when the provider uses an integrated development environment (IDE) and an associated linter, both tuned for hardware design and verification code. The IDE detects and offers “quick fix” proposals for many types of design errors “on the fly” as they are typed in so that they can be resolved immediately. This is far more efficient than tracing back from test failures found in IP verification or, much worse, during IP deployment at the user site. The IDE helps create correct-by-construction design and testbench code by providing auto-complete for identifiers and templates for common language constructs.

As described above, it is possible for code to be functionally correctly but still of unacceptable quality. The IDE’s checks warn about dubious constructs, including those that are not supported across all popular simulation and synthesis tools, those that are interpreted differently, and those that run inefficiently. The IDE offers automatic refactoring to improve the code without changing its functionality. The linter performs additional checks, covering not just language constructs but also UVM testbench code. The IDE checks for compliance with relevant standards, including SystemVerilog and UVM, specifically warning about use of constructs that are deprecated or marked for future removal. All these types of checks can be run in batch mode or interactively in the IDE.

The IDE supports IP readability and maintainability by automatic reformatting to meet industry best practices and conform to project-wide or company-wide coding guidelines. IP providers can customize how white space is handled, constructs are aligned, and long lines are broken up. The IDE offers a wide range of different views to help the IP provider develop the design more quickly and efficiently, while meeting quality requirements. It generates schematics and state machine diagrams for the design and traces signals through multiple blocks. It also displays the design and testbench hierarchy, helps navigate through it, and provides hyperlinks to jump between synchronized views easily.

Fig. 2: Examples of IP and SoC quality checks. Source: AMIQ EDA

The IP user also benefits from using the IDE. The diverse views and navigation features make it much easier to understand the RTL and testbench code. When modifying IP blocks and when writing code for custom portions of the SoC, the user should be running both the IDE and the linter to gain all the same advantages as the IP provider. For example, if the user wants to rename a signal, the IDE can do so automatically and consistently through all levels of the design hierarchy. Correct, robust, and readable design and verification code is a requirement for every IP and SoC project. The IDE and linter enable development teams to deliver on all three aspects of design quality at every level, from the smallest IP block to the largest SoC.

Tom Anderson created this post for AMIQ EDA. It was contributed as a guest blog by ClioSoft.