Reuse is the design mantra of today. It's so much a part of design strategy that there's now a guide, Reuse Methodology Manual for System-on-a-Chip Designs, by Michael Keating (Synopsys, Inc.) and Pierre Bricaud (Mentor Graphics Corp.), to help standardize the processes to ensure reusable designs. Increasingly, companies are relying on purchasable, off-the-shelf, high-quality intellectual property (IP) cores to build around rather than create their own. Additionally, software tools and HDLs often introduce their own challenges into the IP process while you're trying to push IP to market with the highest level of verification and deliver it to customers who have different development processes. Essentially, ensuring that delivered IP is successful requires careful IP-core verification.

ARM's (Cambridge) system-on-a-chip (SOC) group designs on-chip IP peripherals, called Prime Cell Peripherals, which include UARTs, LCD controllers, general purpose I/O, and other peripherals. ARM's goal is to deliver IP components that target as many design applications as possible. This means our IP has to be powerful, but without being so specific in functionality that it limits its application possibilities. The greater the functionality, the more design possibilities for IP macrocells, and the wider the market. Soft IP components often address this issue by adding the ability to be configured. But therein lies a dilemma since it can geometrically increase the verification task.

Verifying the many possible applications in which a design will be used and ensuring that the IP checks out in both VHDL and Verilog requires careful verification processes within a controlled design flow. Some components require specialized verification strategies and tools in-house because of the kind of device they are. Such was the case with a recent design of a liquid- crystal display (LCD) controller for our line of advanced microcontroller bus architecture (AMBA) bus-based Prime Cell Peripheral products.

IP core verification issues

In general, as well as in the case of the design of the LCD controller, our company's designers and verification engineers must keep in mind the deliverables, which include: verified, synthesizable IP in register transfer level (RTL) Verilog and VHDL; verification test code and testbenches compatible with the leading simulators in Verilog and VHDL; synthesis and scan insertion/ATPG scripts; integration vectors (ARM core-specific code for manufacturing test) and test benches in Verilog and VHDL, as appropriate; reference cell library; and supporting documentation.

For the most part, IP macrocell verification faces challenges similar to any other design, but the requirements to deliver verified RTL in both VHDL and Verilog format multiply the issues. In addition, because some of the company's IP macrocells are configurable, verification must consider the different kinds of configurations possible for both VHDL and Verilog. Finally, since designers can pick their own combination of Prime Cell Peripherals to use in their designs, system verification must consider the combinations of possible Prime Cell Peripheral productsýin both languages. Thus, the complexity of the verification task is equal to multiplying all configuration, combination and HDL types.

Environment and design flow

In ARM's SOC Group, ensuring verifiable designs starts with a workable design and verification flow that includes accurate specifications and the use of design standards (see Figure 1). Proven, formal procedures are necessary to develop high-quality, reusable IP. These processes include a list of deliverables expected at each stage of the process and include go/no-go reviews.

Figure 1 - ARM development flow

Formal procedures are followed through each step in the design process with regular peer-group design reviews to ensure high-quality IP.

Regular peer-group reviews are key to the process to ensure all aspects of the design and verification meet the company's standards. A ýspiral design-flowý is used in order to move the design as far through the tool flow as early as possible to isolate and fix problems. This model includes delivery of RTL sources at various ýcheckpointsý during the development cycle. IP is then, periodically and iteratively, integrated and tested during development.

At the heart of this flow are what the company refers to as methodology modules, which are standard, documented practices that, for each step in the development cycle, describe the inputs to the step, including the tools used and procedures for implementing the tools, describe the outputs from the process, and note the expected results in terms of metrics.

As part of the verification process, reviews are checked for compliance to design rules and coding standards to ensure that the code and the design meet defined standards. From this, we can eliminate coding problems that might otherwise have only shown up later during testing. For verification and testing, the company has developed several stand-alone verification testbenches with suites of automated, self-checking regression tests. Stand-alone testbenches overcome a lack of portability by writing test vectors in the simulator's internal language. To support manufacturing test for hard macrocell CPU cores, parallel test vectors can be applied externally to the SOC device via a test interface controller (TIC). The TIC effectively becomes an AMBA bus-master during test. This provides a 32-bit parallel access port for externally supplied test vectors, which are then applied to AMBA modules as bus transfers. This test methodology can also be extended for use with any AMBA compatible peripherals. By adding synthesizable test-logic into the HDL code therefore, non-AMBA inputs can be stimulated and the results of non-AMBA outputs can be captured and returned to the bus to be verified. Because they are independent of other modules, vectors for each module are portable.

Using the AMBA bus also reduces our functional verification testbench development effort, through the use of standardized, reusable modules. The design unit under test (in RTL or netlist) connects to the testbench through the AMBA interface on one side and a module-specific, non-synthesizable, non-AMBA, I/O interface on the other (see Figure 2). Test vectors are developed in C-language using macro-defined commands, called bus-talk. The executed macros generate a bus-talk input file that the testbench reads.

The AMBA testbench provides the framework for functional testing and code coverage analysis. Creation of testbenches based on a standard bus-interface allows clean partitioning of work between different design teams and greatly enhances reuse of a whole verification strategy. Reusing not only the majority of the testbench, but also the supporting infrastructure, minimizes the involved effort. Only the design-specific test code and interface need to be written for each module, and the AMBA testbench can be used to verify both RTL and the netlist of the design. In addition, reusing key parts of the testbench increases confidence in the verification, since it has been tested before.

A recent challenge

One of our recent challenges for our design and verification process was the aforementioned LCD controller. The LCD controller design was created using ARM's corporate phased development processes as described above. But, in addition to the other challenges of verifying IP for different markets, developer environments, and HDL languages, there exists the fundamental issue that to validate this IP it's necessary to be able to generate and view images, since seeing is believing. Added to this, the LCD controller has to support a large variety of display technologies and configurationsýfor example thin-film transistor (TFT) and super-twist nematic (STN) displays, at a variety of resolutions and in both color and mono, single and dual panels.

Figure 2 - AMBA-based functional verification testbench architecture

Interestingly, the average estimated design time for new asic designs was closer to the actual design time than the estimated design time for reuse designs.

From the outset, any verification tool designed to test LCD controllers needed to be reusable and extendable. Because of the large number of permutations of display types, sizes, and configurations, the testbench had to be able to accommodate them all yet be simple enough to be maintained efficiently. Thus we decided to adopt a modular approach to the testbench, with discrete components for ease-of-use and maintainability.

The testbench for the LCD controller comprised the controller itself, some memory, and a model of the ARM CPU core on an AMBA bus. To provide stimuli to the controller, we developed a LCD toolkit (see Figure 3) to generate a frame buffer from standard Windows bitmaps. The testbench loads the frame buffer into memory, and the LCD controller processes the data.

Output from the controller is then fed back into the toolkit, compared pixel by pixel with the expected output from the controller, and any differences between the two recreated bitmaps are highlighted and color-coded according to severity. As a static, post-simulation check, the input image, the output image as generated by the LCD controller, and the differences image are all available for visual inspection. The company also developed a ýpeekerý model, which is a passive Verilog model that dynamically monitors the output from the controller and flags any errors as they happen so that the turnaround time for fixing errors can be dramatically reduced from potentially days to minutes.

The Prime Cell LCD controller was prototyped using an ARM integrator interfacing with a PC, which hosted the ARM Developer Suite for software development.

The integrator was fitted with a core module which contained an ARM9 CPU to run the LCD controller test code, and also included Ssram which was used to hold the frame buffer. The Prime Cell LCD controller was programmed in an FPGA on the logic module and connects to the CPU via an AMBA AHB interface.

Validation versus verification

In a related perspective to the LCD design, the company takes several different approaches to the verification process. The distinction between validation and verification is a subtle one, but it's a distinction that's important in our methodology. If validation is the process of checking the design intent of the IP under test, then we see functional verification as the process of showing that two views of the same design. The netlist and RTL model, for example, are functionally equivalent. Put in another way, functional verification is the process whereby the integrity of the output data is proven by showing functional equivalence with the input data.

Figure 3 - LCD-controller testbench

The toolkit is supplied with a windows bitmap, which it then converts to an internal memory format to be processed by the LCD controller. Output from the controller is then dynamically chekced by the peeker and passed back to the toolkit viewer.

We use deterministic testing as the front-line method in our testing methodology. This is a validation process as it involves comparing actual responses in simulation against expected responses computed by the test bench. To do this requires a thorough understanding of the intended design behavior in order to check corner cases in a systematic manner. Independent design and validation teams are used at the company to ensure that invalid design assumptions are not propagated into the validation process. The validation engineer provides a system perspective for validation while having hardware knowledge of the design.

Pseudo-random testing is used to enhance the quality of validation, as it can readily generate large numbers of different scenarios. Known seeds must be used so that the simulations can be recreated if required. Additionally, code coverage is used to measure the effectiveness of the test suite and to provide guidance on where additional verification is needed. Different code coverage metrics can be used at various points in the verification cycle, starting with statement and branch early in the process and proceeding to secondary metrics such as condition, toggle, path, finite-state machine, and triggering coverage, once the test suite is more mature. These metrics help identify when corner-cases might have been missed and provide hints as to the tests needed to cover them. For validation, the target is 100 percent statement-and-branch coverage for sign off from the accumulated validation simulation runs.

Additionally, we recently introduced Verification Navigator, a code coverage tool from TransEDA (Los Gatos, CA) into our IP verification flow. Verification Navigator was chosen because it has an extensive feature set and because it was the only code-coverage tool we had to use for RTL VHDL and Verilog designs in a single environment. Being able to verify models in both languages increases confidence that the IP is well tested regardless of the language. In the future, we intend to continue to use Verification Navigator for verification of designs at different phases in our spiral design flow, as well as for test-suite optimization to improve simulation productivity.

Functional coverage-analysis tools allow us to measure the completeness of the validation process against the specification and validation plan. These tools allow us to generate an additional metric to code coverage so that we can check that we have exercised the IP functionality, in particular targeting corner cases such as, ýDid the unit perform an interrupt at the same time that the first-in first-out (FIFO) memory was full?ý This kind of testing requires much more input from the verification engineer. The difficult question to answer is how does one know when sufficient coverage points have been declared? You can only achieve 100 percent functional coverage for those coverage points that have been defined.

Final steps

Beyond the RTL verification processes, netlists are verified before and after scan insertion with a combination of dynamic simulations using the same testbenches as for RTL verification. In addition, we apply formal/logic equivalence checking. For soft IP verification, where required, we use an FPGA-based ARM integrator ASIC development Platform to prototype the IP components in a representative system design. The integrator provides capability to rapidly create a physical prototype of specific configurations of a soft IP design. If hard IP is a requirement, we verify the place and route. To produce first silicon, we work with customers who are early adopters of new IPs to verify the design in silicon, allowing us to certify the new IP for that particular process.

While IP core design and verification follows a path similar to in-house circuit design, providing commercial IP presents unique challenges to the IP-core vendorýbecause of the many possible applications for which the device might be used, the large number of permutations of device configurability, and differing design environments in which the IP will be incorporated in order to develop an end product.