The conflicting demands of higher performance, lower power, and simpler physical interconnect have driven the recent development of highly complex SoC interfaces such as AMBA® 4 ACE®, MIPI LLI, DDR4, NVM Express, and Ethernet 40G/100G. These interfaces have compounded the difficulty of design verification at all levels of development—IP creation, SoC integration, and hardware/software system integration. These interfaces touch every area of electronics development but are most visible in mobile platforms and the server, networking, and storage systems that together comprise the infrastructure for cloud computing. To make the verification task more manageable, teams are increasingly using verification IP (VIP). But what should they look for in a VIP solution? This article lays out some best practices.
The most basic requirement is availability of VIP for the interfaces that are present in the design. A typical mobile applications processor has about 30 standard interfaces including several new Mobile Industry Processor Interface (MIPI) protocols. The first issue to consider is which interfaces need the most attention. In a typical case, six or eight of the interfaces will have new or substantially redesigned IP associated with them. Those are clearly the ones on which to focus verification cycles and the ones that will benefit most from the use of VIP.
Many of the newest protocols in mobile and cloud infrastructure platforms may have only one available VIP source. That makes the choice pretty easy! But if there is more than one source, then the next factor to consider is the maturity of the VIP offering. Given that advanced VIP components are themselves fully functional designs with all the state machines that design IP components contain, finding VIP that has already proven its reliability in the verification of multiple designs is a top priority.
Ideally, the VIP should not only have been used to verify a number of previous designs, but also used in applications that match your own design. For instance, a DDR interface in a video subsystem will have different stress points than one that services a CPU subsystem. You don't want to stumble into hidden VIP bugs because the VIP has never been used in your particular application.
Having mentioned DDR, it's important to note that VIP comes in two fundamental types: interface VIP and memory models. Interface VIP is used to verify both the host and target sides of an interface where the end points are typically IP blocks embedded in an SoC or ASIC. On the other hand, memory models represent a physical part manufactured by a memory vendor, or an embedded memory with a well-characterized interface. Generally, more is known about the memory including electrical specs and signal timing, so memory models provide a tailored VIP implementation whereas interface VIP provides a generic VIP implementation. In addition to these selection criteria, multiple memory models should be available covering all the memory vendors whose memories may be used in the target system, so that plug-and-play compatibility can be verified.
As noted earlier, verification is performed at different levels: IP, SoC, and hardware/software system integration. The focus of IP verification is to perform exhaustive corner-case testing against the protocol specification. To facilitate this testing, the VIP should contain extensive embedded assertions to automatically detect protocol violations, as well as test suites and verification plans to speed the verification process to closure. The test suites should support both a directed test approach and constrained-random simulation in a manner that fits seamlessly into the user’s existing environment.
This brings up one of the most challenging aspects of VIP selection. Given the wide array of verification languages and methodologies in use today, no single language or methodology will serve the needs of all users. The standardization of the Universal Verification Methodology (UVM) and availability of UVM class libraries for the SystemVerilog, e, and SystemC™ languages is a great step forward in standardization, but most companies have a mixed-methodology environment today and many are likely to have a mixed-language environment for years to come. So, finding VIP that supports multiple methodologies and languages is yet another requirement.
The other big verification environment factor is VIP support for the logic simulator or simulators being used. Typically, most large electronics companies own a mix of simulators from the "big three" EDA providers. Users need the ability to run on any of these simulation platforms seamlessly. This can be an elusive goal as there may be subtle differences in the way simulators process SystemVerilog code. Such inconsistencies can place speed bumps in the path of verification progress. VIP should be selected that yields identical results across all the simulators in the regression farm.
Finally, every SoC verification engineer knows that logic simulators can only deliver a fraction of the cycles per second needed to perform full-chip verification. To fully verify an SoC, hardware acceleration is required to radically boost performance. With various methods of acceleration, performance ranging from 100 to 10,000 times faster than logic simulation is possible. This is fast enough to run complex functional test scenarios and even perform hardware/software integration. The issue, however, is how to stimulate the interfaces to keep up with the engine performance. That’s where accelerated VIP (AVIP) plays a crucial role. With AVIP, interface traffic can now be generated to keep pace with the accelerated design-under-test.
The list of considerations discussed in this article should help you navigate through the range of VIP solutions to find the one that best matches your application and environment. Using these selection criteria should give you a great head start on eliminating the bugs from your next design!
Tom Hackett is a product marketing manager supporting the Cadence VIP Catalog. Tom manages outbound marketing for the VIP Catalog and product marketing for storage protocols. Prior to this role, Tom served for 20 years in various sales and sales management positions at Cadence and other design automation and IP companies. He began his career as a design engineer with Texas Instruments.
Tom holds a BSEE from West Virginia University. He is active in several storage-related standards organizations and is a longtime volunteer with the Boy Scouts of America.