The goal of all these efforts is to get through a project using fewer verification resources, to shorten the pre-silicon phase during the critical design period, and to reduce the error rate at First Silicon. The Intel Communication Group achieves this by means of the following methods:

Hardware Verification Languages

The first important change concerns the hardware verification language. At Intel's design centre, the team responsible for the verification decided to adopt Specman Elite and the verification language 'e' from Verisity in order to create the RTL verification environments and automate the test processes. The tangible advantages were abstract tests, on-the-fly checks, abstract data types, and the ability to reuse verification components more extensively. However, this alone was not enough to achieve the required quantum leap.

Coding in Specman Elite can be performed by both hardware and software designers. However, it does require a versed user to be effective. Since such skilled users were barely available, it presented a problem, because building up high-level experience with the RTL design engineers within the team was essential.

Random Tests

Random tests are also made possible with the use of Specman Elite. Initially, randomness was limited to the tests performed on packet lengths and the data within the packets. As progress increased, however, the design team began to design the environment to include more extensive random components.

Random tests require a robust environment, the ability to obtain statements about the respective actions, and initially appear less intuitive to the designer. By guiding the test sequences on the basis of information about functional coverage, the team can see from the very beginning how effectively a test sequence covers the design being tested and how well the test is progressing. The previously common approach of defining test situations must be replaced by the definition of coverage points. If a methodical approach is followed here, test overlaps are avoided just as thoroughly as untested areas. Feedback is also provided about which critical areas require particular attention.

Module Verification

Module verification involves creating environments and testing modules as individual, isolated functional units with the goal of making integration and testing smoother. Integration is facilitated because the individual modules are first tested in isolation. Testing also proceeds more smoothly because errors have a strong impact on test time.

Coverage-Oriented Testing

Coverage-oriented testing (Fig. 1) is an iterative process. The term describes steering the test sequences on the basis of information about functional coverage. From the outset the team can see how effectively a test sequence covers the design under test and how well the test is progressing.

Defining coverage points leads in an organised way to a detailed feature list. This can also happen in a very early phase of the design process, and provides the environment developer with information about how robust the module needs to be in order to generate valid and invalid stimulus signals.

By testing module by module and filtering out logic errors early on, the environment developer has the opportunity to check his interfaces for integration of the complete chip. The designer can also use simple, comprehensible environments with Specman Elite in their entirety without electrical aids and correction tools, while maintaining the integrity of fast differential signals.

Design Patterns

Among the most frequently reused patterns are bus function models (BFMs). In various projects, reusable BFMs repeatedly reduce the integration time for verification and give the engineer the opportunity to design simple scenarios for the entire environment before production. For a real quantum leap, however, it is necessary for the engineer to find a range of useful models for problems arising in other projects. In areas where the team itself has no know-how, other groups, consultants, and further resources should be used to incorporate these patterns into the knowledge base for the current project.

The following list names some paradigms that can be transferred from one project to another or adopted from other groups. Each variant addresses the testbench problem from a different angle:

Integration of a new project should encompass the following elements: mapping the signals to reused BFMs; importing all relevant data structures from existing projects; populating tables about the register layout and mapping reset and initialisation processes; as well as booting the test items in various operating modes within a few days. The team should concentrate on what distinguishes the new project from its predecessors.

Side Effects

These methods have produced a number of unwanted side effects that are often decisive for the success of other solutions. Some of the side effects noted by the Intel Communication Group are listed below.

Random tests can filter out environment-related bugs more quickly and lead to clearer, more robust modules and environments. This in turn facilitates reuse and enables a smooth course of coverage-oriented testing.

Creating module-oriented environments has essentially two effects. First, the verification team gains a sound understanding of the microarchitecture of the designs. Second, it is an effective solution for determining the coverage points and internal checks (constraints and assumptions) at the RT level. This sound knowledge, combined with the white-box checks and the coverage of the design at various levels, has several effects:

Defining coverage points leads in an organised way to a detailed feature list. This can also happen in a very early phase of the design process and provides the environment developer with information about how robust the module needs to be in order to generate valid and invalid stimulus signals.

Abstract modelling helps in the training and retention of verification experts. The design lead and the creation of design patterns lead to an expansion of the experience base, which in turn attracts and retains more capable engineers. The persons responsible also recommended familiarisation with the various eVCs offered by different manufacturers of validation components, as well as the literature describing existing design patterns. With seamless integration, the company encouraged the RT designer to work at the block level and fix bugs while simultaneously being prompted by the verification team to take a look at the coverage results. The verification team works on integrating the remaining features into the environment and incorporating the integrated features into random scenarios. The checks and coverage statements from the block level are transferred to the highest hierarchy level and used there.

Bringing It All Together

Intel initiated this transformation in two organisations in which the design centre suffered from quality deficiencies and deliveries that were not on time. The first step was the insight into the necessity of switching to a different tool. Both had suffered from quality deficiencies and untimely delivery. The Intel Communication Group chose Specman Elite, since it already had experience gathered with it.

The next step was modular verification. The design team laid out the schedule for modular verification, since it is the prerequisite for seamless integration. Here the engineer had the opportunity to quickly familiarise the verification engineers with the tool and introduce white-box checkers and the coverage aspect.

The next step was to organise a training session for the older verification engineers. Here they had the opportunity to familiarise themselves with the existing design patterns and contribute their ideas for additional design patterns. Those responsible also recommended familiarisation with the various eVCs offered by different manufacturers of validation components.

Once all the features of the environment had been successfully integrated into the design, the random tests could be taken up at full speed. The verification engineers worked with the RT designers on the constraints needed for the random tests to achieve the specified coverage targets. As soon as the required coverage was achieved, the final RT description for use in the back-end phase could be released.