Verification of the UltraSPARC microprocessor

Abstract

The overall veriJication approach used in the design and development of the fill custom 64 bit UltraSPARC microprocessor will be described. A balanced hierarchical approach was critical in validating a design with this level of complexity. The tools, developed internally and externally, which aided the verijication effort will also be described. The environment was flexible enough to support various revisions of major tools. The method developed could easily be applied to derivative and next generation microprocessors.

Postsilicon validation methodology for microprocessors

“…1,3,7,9,11 Many vendors have successfully achieved this goal in spite of the differences in validation methodologies employed, indicating reasonably distinct validation approaches can work out successfully. [1][2][3][4][5][6][7][8][9][10][11][12][13][14] Generally the vendors have used a combination of directed stress tests, randomized generators, and directed random test generators in validation. 9,14 Pseudorandom testing using randomized generators is effective for combinational design.…”

“…16,17 Tests based on the reference checking principle without assuming a fault model have mainly been used in commercial processor validation. [1][2][3][4][5][6][7][8][9][10][11][12][13][14]18 While formal models and techniques have helped in addressing a class of problems like validating finitestate machines of control logic, a large body of informal techniques are routinely employed in achieving satisfactory validation mainly because of the enormity of the validation space of complex microprocessors. 15 A large portion of the postsilicon effort is more relevant to manufacturing than design validation.…”

“…Most of the presilicon validation is done either on a register transfer-level (RTL) simulator or an emulator and has been the primary technique successfully used by a number of commercial manufacturers. [1][2][3][4][5][6][7][8][9][10][11][12][13][14] After the first silicon is ready, postsilicon validation is done in a system environment to flush out bugs missed in presilicon validation. Typical reasons for this are the slow simulation speed that prevents running a large number of tests, tests requiring long execution times, testing done close to release in a hasty manner, tests not run in a particular mode, innovations in circuit technology, and so forth.…”

Verification of a microprocessor using real world applications

“…Verification very often takes up more than half of the whole design time for complex microprocessors [5]. Various design verification methodologies with the relevant environmental setup for an effective verification have been proposed and/or used now [1,2,3,4,5,6]. For the case of designing next-generation microprocessors, microcontrollers, and DSP processors which already have a large number of firmwares and application softwares running on them, the requirement on the backward compatibility with the previous products or the full compliance with all relevant softwares makes the verification process more and more difficult, error-prone and time consuming.…”

“…Hardware emulation, which was introduced to reduce the simulation time also contributed to the in-system verification, i.e., verification of the target design in the real system environment [2,3,4]. However, emulation cannot be used for the verification of all the design levels, because emulation requires the design description as a gate-level netlist, which can be obtained only at the final stage of the design process.…”