SoCs require a new verification approach

SoCs require a new verification approach
By Al Czamara,
February 25, 2002 (8:15 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020225S0074

Al Czamara, director and principal consultant at Zaiq Technologies, provides some tips for system-on-chip verification in this contributed article. He suggests a "vertical slice" approach to intellectual property (IP) verification, along with the use of verification IP and static methods. Zaiq provides system-level design solutions, including verification software, reusable IP blocks and design services.

As system-on-chip (SoC) designs become a driving force in electronics systems, current verification techniques are falling behind at an increasing rate. A verification methodology that integrates separate but key technologies is needed to keep up with the explosive complexity of SoC designs.

A SoC verification methodology must address many more issues than were prevalent even a couple years ago, in particular the integration of purchased and in-house intellectual property (IP) into new designs, the cou pling of embedded software into the design, and the verification flow from core to system. Several key concepts are important to understand, including the transition from core to system verification, the re-use and integration of multiple sources of cores, and the support needed to optimize core re-use.

By now most engineers and managers have heard that design verification consumes between 50-80 percent of the design project, by recent estimates. And, with silicon capacity doubling every 18 months, according to Moore's law, the verification problem - directly proportional to the square of capacity - is doubling every 6-9 months!

There are two major problem areas with SoC verification today that keep the verification bottleneck with us -- IP core verification, and the SoC verification methodology.

SoC IP integration
The verification of today's IP cores tends to be inward focused. For example, the verification of a PCI-X IP core would test the bus modes and address space. This verifi cation is useful, and helps provide information on the core functionality to the IP integrator.

However, all this verification does not help a great deal at the system level, when the PCI-X core is connected to the rest of the system. How should the software team write drivers involving this IP core? What if the core needs modification? Will there be any architectural issues that arise when it's too late to change the core? All these make IP use, and reuse, challenging.

With today's SoCs integrating increased amounts of IP, understanding the requirements for effective use & reuse of internal or 3rd-party IP cores is critical, as well as how IP use effects SoC verification. Several key issues are as follows:

Modification - most IP cores used today are modified. Access to developers is not always an option, especially with internal IP. Modifying complex IP is even more difficult.

Integration - most IP cores do not provide protocol checking and monitoring code to be used in the target verification environment. Unless the interface is a standard bus (such as ARM's AMBA), there is generally little help available for the design and verification teams.

System verification - an outward focused verification suite, that allows the IP core to be tested in-system, is necessary, and if one is not provided with the IP core, then it usually created and debugged by the verification team and/or the IP provider.

Taken together, the above usually mean unwanted surprises for the SoC developer. To mitigate some risk, it is therefore required to have a tight relationship between the SoC developer and the IP provider. There is another way, however, as shown in the figure below.
Figure 1 - IP veritical slice integrated into an SoC

A complete block of IP, which includes hardware, software API, verification code, protocol checkers and monitors, and documentation, permits encapsulation of the IP block - a complete "Vertical S lice" of IP. Successful encapsulation of IP means that designers will gain the most leverage from the IP block, and reliability and predictability of using that block are increased significantly. It is easier to understand, install, modify, and debug the block. System-level architectural verification will be much simpler as well.

SoC verification methodology
There are also shortcomings with today's methodology in the face of the growing use of SoCs. Individual designs that were once an entire system are now blocks in an SoC. The associated verification strategy with many of these blocks was not designed to scale up to a higher integration level. If the methodology does not permit easy integration of block-level verification code into a system-level SoC environment, then the project verification will become a major bottleneck to the entire system.

The successful SoC verification methodology must be able to integrate multiple in-house or third-party IP cores, effectively migrate testin g from the block to the system-level to maximally leverage testing, integrate software such as drivers and diagnostics, debug, and provide for the adoption of HDL acceleration and formal verification.

It is important to understand that SoC verification does not imply a homogeneous environment. There are lots of tools and methods out there. IP comes from many sources, internal and external. A solid verification methodology must be able to incorporate verification code from a number of sources, tools, languages, and methods. A successful methodology is a collection of tools integrated in open and documented platform. The most effective way to improve the quality of results, shorten the development time, and decrease costs is with a careful, consistent verification methodology used throughout the project!

One effective technique for SoC verification is to use pre-defined verification IP. These can take two forms:

Verification Components (VCs). These are generally stand-alone verificati on building blocks that are based on industry standards, and that can be plugged into a verification environment and provide "instant-on" validation. They ideally incorporate monitors and protocol checkers, bring-up tests, efficiency routines, and sometimes a standard conformance suite, and are designed for use at the block level up to the system level with no modification. An example is a 1-Gigabit Ethernet verification component.
Verification Platforms (VPs). These are generally an integration of multiple verification components, specific data generators, score-boarding mechanisms, and a high-level verification suite that are targeted at a specific domain application. An example is a Storage Area Networking verification platform, which includes Fiber Channel, Gigabit Ethernet, and PCI-X VCs, a packet generator and scoreboard, and iSCSI support.

Using VCs and VPs effectively in an SoC project can save 50-70 percent of the project time normally spent on verification.

Finally, it's important to recognize domain-based verification techniques. Telecommunications domain verification differs from computer domain differs from ATE. Each has its own special requirements, even though there are many similarities. Verification tests are becoming more complex, taking significant engineering effort to develop.

If tests are written using a good methodology, and from a domain focus, then they can be used at multiple levels from block to system level, and from project to project. This type of test should be viewed as a form of IP, with all the reuse, management, and methodology issues that are part of any type of IP. A good VP will encapsulate the domain knowledge. The moral: Tailor the verification solution to the problem, not the other way around.

The Future
More use of SoCs, which leverage "vertical slice" IP, and which are driven by a good verification methodology and open environment, will help keep the verification bottleneck at bay. However, the ever-increasing capacity of silic on, and therefore the complexity of the verification problem, will eventually cause the methods above to become inadequate. New verification techniques and methodologies will be needed.

Enter static methods. Currently, formal verification is used routinely to verify various netlist transformations during a chip's physical design. Also, RTL to gate comparisons are done now by some companies to eliminate or at least minimize gate-level regressions, saving considerable verification time -- weeks to months for some large designs. If we could eliminate or at least minimize RTL verification using static methods, it's quite possible we could eliminate the verification bottleneck.

The current problem with formal verification of RTL - which essentially means verifying the RTL against the design specification - is that the English language is not well suited to airtight specification of electronic designs. What's needed is a formal specification language. Two examples of work being done in this area are Intel's formal property language initiative, and the SpecC initiative.

Here's how this could work. The SoC architect or designer would write a specification in SpecC, for example. Using translation tools, the designer would generate an English-language specification for humans to read, HDL code for architectural simulations, and a netlist for physical design. The specification would truly be the reference from which the design is built. As with logic synthesis now, formal verification would be used to sanity check the translations. All this would be done without any design verification, as we know it today.

However, in the near term, static methods will not eliminate the verification bottleneck. The source of the bottleneck is not tools, but rather the incomplete and self-inconsistent way that people create new architectures. Verification takes a long time because those inconsistencies must be found and fixed. It is unlikely that a tool will be able to determine intent from a specification in the near future.

References
1. Hal Alles, Role of static methods in HDL verification, Integrated Communications Design, June 18, 2001, pg.42.
2. Sean Dart, Integrate tools for effective verification, Integrated System Design, September 2001, pg. 56.
3. Gabe Moretti, Your core, my design, our problem, EDN, October 11, 2001.
4. O. Petlin, A. Genusov, L. Wakeman, Methodology And Code Reuse In The Verification of Telecommunications SoCs, Proceedings of 13th IEEE ASIC/SoC Conference, September 2000.
5. Kan Lau, System specs drive Multiprocessor SoC, Integrated System Design, October 2001, pg. 30.