Accelerated Verification Process Automation

Abstract

The Verification Problem

System design projects are extremely large and complex, an average design today is over one million gates, with 5-9 increasingly complex interfaces, and short design schedules. This is creating a verification crisis, causing teams to run orders of magnitude more simulation cycles. In addition, directed tests are not easily created or maintained and the interface interactions have grown exponentially. The team must also verify that the design adheres to the specification at each abstraction level, and each level requires a different execution engine.

Considering all this, combined with the ever-increasing cost of implementation as geometries continue to shrink, the cost of failure has never been higher.

VPA: Maximizing Verification Effectiveness

In recent years, HDL simulation technology itself has matured to the point where order-of-magnitude performance gains are no longer being seen. This has led savvy verification engineers to focus on getting more verification value from available simulation cycles. Furthermore, the development of sophisticated verification environments means additional time at the front end of verification, and as these environments become more sophisticated, time-to-simulation increases as well.

Verisity's Verification Process Automation (VPA) solutions address both of these concerns; their aim is to simplify and automate the creation and maintenance of sophisticated, scalable, unit- to system-level verification environments, and enable a coverage-driven methodology which focuses the verification effort on those areas of the design which have been inadequately exercised, eliminating brute-force verification efforts which rely on quantity of testing rather than quality to determine verification thoroughness.

In addition to a fundamental constrained-random, coverage-driven methodology, VPA comprises Verisity's e Reuse Methodology (eRM), which simplifies the creation of reusable verification IP and the System Verification Methodology (sVM), which encapsulates sophisticated system-level verification technology targeted at SoC verification and hardware/software co-verification.

At the same time, verification engineers have long recognized the need to move beyond software logic simulators for particular verification problems. Among these are:

• Long simulations requiring extensive run-time to get the device under test (DUT) to a particular state;
• Large DUTs with so much HDL that they have prohibitively slow performance in a software simulator, in terms of cycles per second;
• The need for in-circuit emulation of the DUT in its target hardware system.

Acceleration and emulation technologies for this target space have shown impressive gains over software simulation speeds, but at the same time the verification methodology employed for acceleration hasn't shown a great deal of improvement. Obviously, the way to maximize verification effort is the combination of both approaches: the development of an accelerated VPA methodology.

Reuse of verification IP is an important aspect of VPA. Reuse improves not only verification productivity (reuse drastically cuts development time), but also quality (the experience gained in developing a verification IP tracks with it) and predictability (the application and time it takes to apply a verification component to a problem is well known).

Two different aspects of reuse are well known: vertical, or within various integration models of a design, from unit- to system-level; and horizontal, from one project to another which share follow-on protocols and modules. VPA introduces a third axis of reuse, one that runs through the various technologies employed across the life of a project, through high-level architectural modeling, HDL simulation technology, acceleration and post-silicon verification, as shown in Figure 1.

Figure 1 Verification Environment Reuse

But how do we develop effective accelerated environments that can be used along the length of all three axes, while still leveraging the power of VPA? To start answering this question, let's look at how accelerated environments have evolved.

The Evolution of Accelerated Verification Methodology

Pure accelerated testbenches require coding the testbench in synthesizable HDL, such as Verilog or VHDL, which restricts the constructs available. These limitations make all three aspects of an effective verification environment difficult: sophisticated stimulus generation, automated checking and functional coverage. Without these aspects, synthesizable HDL testbenches are likely to verify less of the design, not detect errors when they do occur and give ineffective feedback about how much of the design has been verified, and therefore the very long and fast runs they enable can give a false sense of security.

Another approach is to couple an accelerator with an effective verification engine running in software, and to treat the accelerator as the DUT in this mixed environment. In this model, the verification environment can employ engines which powerfully enable generation, coverage and checking. The verification environment interacts with the DUT on the accelerator when necessary, to drive stimulus or monitor device output behavior or internal state.

One limitation of this approach is that in most cases, interaction with the DUT is of high frequency, generally at the base frequency of the device or a small multiple thereof. A verification environment running in software and interacting with the device on every clock does not allow the accelerator to run at anywhere near a speed at which it is capable.

These limitations lead naturally to transaction-based interfaces to acceleration, where a software environment is coupled with HDL transactors in the accelerator to enable a more efficient communication between software and the accelerator. On the positive side, this approach does enable faster execution; on the downside they require a "roll your own" interface and a verification environment that's an amalgam of synthesizable HDL and high-level software. In addition to the difficulty in synchronizing verification environment changes with the custom accelerated transactors, there are now two different environments for verifying specification adherence: one for simulation, one for acceleration. Additionally, of course, there is still a lack of sophisticated constructs on the acceleration side for protocol checking and functional coverage.

Verisity's eCelerator was developed to address these limitations. eCelerator implements a buffer-port based approach to interacting with the DUT; this decoupled communication enables the accelerator to run for longer periods, at higher speeds between interactions with the verification environment. High-frequency VE components are still written in the e verification language, but are then compiled to hardware modules, which can then run alongside the DUT in the accelerator; buffer ports convey generated stimulus into the DUT and observed data back to the verification environment.

eCelerator represents the state-of-the-art in combining powerful e-language verification environments and high-speed acceleration boxes; while other accelerated verification approaches remain stuck in the past, it enables optimizing acceleration cycles through coverage-driven methodology. And coupled with eRM, this solution allows reuse vertically, horizontally and along the infrastructure axis as well. But the underlying technology in typical accelerators can still be limiting to the verification engineer.

Limitations of Cycle-based Accelerators
In discussing the development of an accelerated verification environment, we're not just describing environments made from scratch, but also existing software-only environments newly targeted at accelerated platforms. Whether we're developing or converting such an environment, we need to be aware of the underlying simulation, acceleration or emulation platform infrastructure since this will determine what capabilities can be migrated from the verification environment.

Many accelerators on the market today are cycle-based in nature and require any accelerated code to be written within that paradigm. DUT and testbench components targeted for acceleration must do all their work within the span of a fundamental clock tick; the longest path within this clock is one determining factor of overall accelerator speed.

This can constrain what can be done in a verification environment which is to be mapped to the hardware. While an intelligent compiler can optimize the translation of verification language code into accelerated units, there are hard limits on what it can do before the constructs available to the verification engineer are restricted.

One fundamental limitation of cycle-based technology is the inability to allow a relaxation of events to occur. In a typical Specman Elite verification environment, for example, many events can happen in zero simulator time; these events may be emitted manually - in a time-consuming method (TCM), for example - or as the result of a temporal expression, and relaxation proceeds. But in a cycle-based accelerator, it's not possible to have an indefinite relaxation of events; rather, the testbench compilation software is forced to choose one event evaluation paradigm.

The SpeXtreme Solution

• An e RCC compiler which translates e units into accelerated modules;
• A buffered transaction-based interface to communicate between accelerated and non-accelerated units;
• ReConfigurable Computing (RCC) acceleration technology with event-based behavioral processors;
• Acceleration methodology guidelines to simplify development and reuse of accelerated verification environments.

The testbench compiler translates a verification environment which has been partitioned between accelerated and non-accelerated modules; what follows is an introduction to the partitioning process.

Designing for Acceleration
The primary consideration when developing an accelerated verification environment is the hardware-software interface. Every task switch between the accelerator and the software verification environment is detrimental to performance; the worst case is a software module which accesses the DUT on every clock. Such an environment is unlikely to run any faster than one running purely in software. Effective partitioning on the e side, therefore, is essential to high-performance accelerated environments. A properly partitioned verification environment has these properties:

• Units with high-frequency access to the DUT are compiled into the accelerator;
• These units are connected to the rest of the environment on the software side through buffer ports;
• As much as possible, access to the DUT should be restricted to accelerated e units.

Figure 2 shows a typical Specman Elite verification environment structured in accordance with eRM. The units of the environment run at various speeds relative to the device under test (DUT): interface checking and coverage run at the same order of magnitude as the DUT; sequence drivers and high-level checkers run at a slower transaction speed; and the highest-level checking and coverage units run even slower. Bus functional models (BFMs) and transaction collectors bridge the world between the DUT and the lower-frequency components, and so it is here that partitioning between accelerated and unaccelerated units occurs.

Figure 2 Specman Elite verification environment

The same environment partitioned for acceleration is pictured in Figure 3. The frequency-bridging units have been partitioned into unaccelerated and accelerated units, with the latter compiled into accelerated modules and placed alongside the DUT in the accelerator.

Figure 3 Verification environment partitioned for acceleration

But it's not partitioning alone which results in optimal performance, but also the addition of buffer ports. Buffer ports are e constructs which serve to minimize the frequency of task switches between the accelerator and the software environment; they buffer the stimulus driven to the DUT and the monitored data returned to the verification environment. A well-partitioned verification environment can generate stimulus in batch, producing multiple data items to be driven into the DUT, and do its checking in batch with the monitored DUT output. In this way, the accelerator can run several transactions before requiring interaction with the software environment.

Enabling an Incremental Migration Path
Partitioning an existing verification environment for acceleration must be accomplished for optimal performance. However, it is possible to start migrating an environment to acceleration without doing all the work it takes to achieve the optimal partitioning. SpeXtreme employs a mixed-access capability which allows verification environment units on the software side to access the DUT directly, without requiring buffer ports or a corresponding accelerated unit.

In this way, SpeXtreme provides a faster path to performance for existing verification environments; by allowing both accelerated and non-accelerated modules access to the DUT, SpeXtreme enables the incremental migration of the environment to the optimal methodology. This allows engineers to migrate units to acceleration over time, choosing those first whose migration would represent the largest performance gain.

This technology also allows units which access the DUT at a reasonably low frequency to do so easily; examples of this might be:

• Initial device setup by direct access;
• Corner case stimulus where occasionally data items may be generated based on the DUT state;
• Final white-box device checking where additional visibility may be required.

To enable this migration, the SpeXtreme solution includes profiling tools to identify critical-path blocks. The principle behind these profilers is that verification environment units which access DUT signals most frequently are primary targets for acceleration. The profiler therefore samples a typical run and determines which blocks would be best migrated immediately, and which can wait. From this, the verification engineer can make an intelligent choice not only about effort prioritization, but about leaving some blocks unaccelerated for the flexibility of accessing DUT signals on the software side.

The Benefits of Behavioral Technology
SpeXtreme employs Verisity's ReConfigurable Computing (RCC) technology. With RCC's behavioral processors, behavioral code can be mapped directly into accelerated technology. Since high-frequency portions of the e environment are compiled into accelerated technology, RCC technology translates directly into new possibilities for writing high-level verification environments; not only do behavioral processors enable a wider range of coding styles to be employed, but the event-based nature of the technology enables a higher-fidelity correspondence between the execution of the verification environment in software vs. on the accelerator.

In addition to broadening the range of what can be implemented in hardware for both the DUT description and the verification environment, SpeXtreme's e behavioral processors can make the hardware that is synthesized faster and more efficient. While cycle-based accelerators often require creating long-path hardware to implement functionality in one clock cycle, with event-based technology, an iterative module can be compiled which has a shorter path and smaller footprint.

All of this means that not only will existing verification environment code be easier to migrate to accelerated technology, but methodologies for accelerated verification will be less restrictive, easier to learn and implement, and they will fit better in acceleration than ever before.

Acceleration Methodology
SpeXtreme, like all Verisity products, is developed along with a methodology for effective implementation. As part of Verisity's VPA vision, SpeXtreme comes paired with an acceleration methodology, with recommendations on best practices in order to easily implement solutions optimized for performance, reuse, and ease of implementation. By developing the acceleration methodology in cooperation with our users, it provides an encapsulation of all best-known methods, accelerating environment development and further easing the adoption of effective accelerated verification environments.

Acceleration methodology applies the time-proven best-known methods developed in eRM and sVM, and extends them to include:

• Partitioning methodology for acceleration;
• Guidelines for reuse, for developing verification environments which can move from architectural modeling through simulation and into acceleration;
• Acceleration-specific guidelines on optimizing the interface between software and acceleration.

These guidelines can be used to simplify the crafting of verification environments which can be easily moved between acceleration and simulation. Just as important, it improves the quality of verification by eliminating multiple verification environment development, ensuring a single model for verifying specification adherence across all technologies

Summary

Verisity's SpeXtreme greatly simplifies the migration and creation of verification environments for accelerated technology. With its e behavioral processors and e RCC compilation technology, more flexibility than ever is available to verification engineers for accelerated environments, and in acceleration methodology, verification engineers have the tools they need to maximize the quality, productivity and predictability of their efforts.