Verification of Third-Party CPU Intellectual Property

Agilent's ASIC Products Division provides and supports a wide range of third-party CPU IP. These cores range from low-end controllers to high-end, dual issue, 64-bit processors and complex DSPs from a variety of industry leading CPU IP suppliers. We receive both hard (GDSII) and soft (RTL) CPU IP from these partners. This article focuses on the validation of soft CPU IP.

Key factors for high quality verification of these processors include the quality of the partner's deliverables and support, the integrity of implementation tools and methods, and the IP management process.

The third-party partner's ability to provide high quality deliverables that include full verification of the non-implementation-specific attributes of the CPU is key. Primarily, this is a rigorous validation of the behavioral functionality of the processor. Thorough examination of their architectural and behavioral validation processes including tool flows, history of success, and deliverables management is vital. In the ideal case, the availability of IP "proven in silicon" helps guarantee the quality of the soft IP deliverables. However, this is not always possible, especially when early access to leading processor designs is required. In these cases, the validator must rely on the IP partners' ability to perform high quality behavioral validation. It is also highly advisable to fabricate internal test silicon prior to releasing the IP implementation. In all cases, e fforts should be focused on the validation of implementation-specific design work.

With a third-party soft core deliverable in hand, the goal is to create a hard macro design in the target foundry process. This is done with a standard cell-based implementation methodology built around the tool flow shown in the accompanying figure. The flow shows both the implementation and the verification steps. The focus throughout the flow is to base verification on the comparison of the implementation with the "golden" RTL and simulation vectors provided by the IP supplier. The first task is to verify the "out of the box" delivery. The primary activity here is running the validation vector set against the RTL code. This step ensures that the release is valid, self-consistent, and simulates correctly on the integrator's tools and compute environment. Next are technology specific implementation tasks such as modifications needed for test methodology (scan, BIST, etc.), the instantiation of specific SRAMs for cach es and other single cycle memories, and the setting of any configurable functionality options.

The correctness of these modifications is verified in two ways. First, the validation vector suites are rerun against the modified RTL to ensure that the cycle-by-cycle behavior is equivalent. Secondly, tests targeted at testing the modified areas (BIST, SRAM instantiation, configuration, etc.) are created and run. After both simulations have run successfully, the modified RTL becomes the new "golden" standard. This RTL and the simulation results are the basis for all downstream simulation checking and equivalency checking. The middle of the tool flow is based on a standard cell implementation methodology using static timing analysis (STA), simulation, and equivalency checking for functional and timing verification. Both gates to RTL and gates to gates equivalency checking are included. Employing a dual approach to timing validation offers further security. In addition to full static timing analysis (STA ), full simulation of the vector suites against the annotated gate level netlist provides further backup.

The final task in the design flow is the creation and validation of abstracted models of the IP for use by the system/ASIC designers. These include simulation and synthesis/STA models. A compiled RTL model that can be annotated with ASIC timing information is available for simulation. These models are compiled from the golden RTL and the validation suite is run against them prior to release. An extracted timing model of the CPU with all the boundary timing information is available for STA. This model is checked across a wide array of operating conditions using the annotated gate level timing as the golden model. It is guaranteed to cover both the min and max timing conditions under the range of allowed operating conditions.

The importance of third-party CPU IP verification is obvious. The quality of the functional behavior verification environment provided by the CPU architecture partner is the foundation. This verification environment must be duplicated during implementation of the hard macro IP and used as the basis for validation of functionality for any RTL changes. The verification of the gate level implementation can rely on RTL to gates based equivalency checking, STA, and application of the simulation verification environment to the timing annotated gates.

Again, the final quality of the implementation using this methodology has a foundation based on the verification environment provided by the CPU core supplier. A thorough review of the rigor and quality of this environment is essential. Ideally, the RTL will have been proven with a silicon implementation done by the supplier or another of the supplier's partners. If not, test silicon is advised prior to releasing the IP.

See related chart< /a>