Expediting processor verification through testbench infrastructure reuse

How project size affects the process
The nature of the project-to-project changes notwithstanding, approaches to processor verification depend on the scale of the undertaking. This may be massive, as in the examples of the Intel Atom and the ARM Cortex, or more moderate. Examples of the latter category include domain-specific, proprietary architectures, and also enhancements to existing ones, such as those of ARC or Tensilica.

Massive projects are attempted only by large companies that have been in the game for a considerable time. Any new processor development therefore leverages existing infrastructure and test suites (backwards compatibility with existing architectures is a frequent requirement), and new tests and testing components are added to this infrastructure as needed.

Such companies generally consider functional verification to be a core competence, and they produce and maintain their own functional verification tools almost entirely in-house. This approach makes sense - up to a point. The production and maintenance of large amounts of code (usually C or C++) costs a lot of money. Further, to get the right return on this investment a company must maintain a strong focus on the software activity. This means well-defined and managed projects for the different components of the functional verification infrastructure, with dedicated and motivated owners. As these infrastructure projects age, this kind of focus can be very hard to maintain. The constraints solver guru leaves the company, gets sick, or is hit by a meteorite, and his replacement wants to "clean up" thousands of lines of code.

Before we consider ways to reduce exposure to such risks, let us turn to the second category of projects. Processor architectures in “moderate” projects are simpler than those of their massive counterparts (at least, they start that way), and the infrastructure is built and maintained by smaller teams. The engineers involved often come from a hardware development background, and this is one of the reasons for the frequent choice of Hardware Verification Languages (HVLs) such as e, Vera and SystemVerilog. These are conceptually very close to Hardware Development Languages (HDLs) such as Verilog and VHDL, which may also be used for verification tasks. An HVL is similar in look and feel to an HDL, but it includes specialized verification features. The most important of these is a constraints engine, which is a difficult function to implement from scratch (though it typically only takes about 1% of the code in a full test generator).

The main drawback of HVL-based verification systems is that they tend to reach a saturation level, beyond which it becomes inefficient and costly to incorporate new features. HVLs may be verification oriented, but they are not processor verification oriented, and using an HVL for processor verification is a little like using Excel to manage company accounts. It’s very useful for getting started, and you need the flexibility it provides in the flow, but once a certain level of complexity is reached you also need to invest in specialized tools. At this point, if you wish to continue along the path of creating and maintaining your own tools, the only choice is to write them at the C/C++ level.

We therefore see that the “massive” and “moderate” project approaches are the same in one crucial respect: they both require a large commitment to coding and maintaining the testbench infrastructure, especially the test generators.