cover story

System Verification from the Ground Up Leveraging the drivers developed for ASIC validation and using a high-level simulator speeds verifying complex ASICs and systems and raises confidence before tape-out. by Sherri Al-Ashari

Verification has become a serious bottleneck in the design process, taking as much as 70 percent of the total design cycle time. Devising a well-considered system verification strategy at the beginning of a project is key to completing the project on schedule. An effective way to structure such a strategy is to leverage the drivers developed for the chip-in-isolation stage of the design process and reuse them at the subsystem and system levels.

At Sun Microsystems Computer Corp., we measure the completeness of our verification strategy for chips and systems along two axes. The degree to which tests need to be directed or randomized lies on one axis, with the extreme being full random tests. The other axis indicates the level of integration in simulation, one end being module verification and the other end system simulation. Our strategy touches on many points within this matrix.

Our goal was to develop verification drivers, stimulus generators, and test cases that were portable to a cycle-based simulator, sharable among projects, and extendable. We achieved reusability by writing bus models or transactors that conform to bus specifications. We implemented the lower levels of the transactor using a modular, hierarchical approach, which allowed us to design drivers as the verification dictated: random, directed, or both. Taking advantage of several powerful features of our verification tool, we devised procedures and wrote new code to check the logic, memory, interfaces, and the full system.

Unarrested development

All aspects of our project development are tightly interwoven. After we design and specify the architecture of the microprocessor bus interface, we develop the system architecture for desktop and server machines. Since all our machines use the same bus specification, minimally only one group needs to implement bus transactors and drivers that mimic what a particular microprocessor will do. We develop drivers to verify an ASIC at the chip level and then extend them to the system level.

The complex nature of our systems demands a high-level simulation tool to develop our test cases. The limitations of Verilog would make test bench development and verification very difficult and minimize the effectiveness of our verification code. Our complex designs, for example, need many test cases for complete verification, so we planned for a change in our simulation environment from event-based simulators to cycle-based simulators. This change could allow us to significantly increase the number of simulated clock cycles per second. Cycle-based simulators, however, typically require synchronous designs implemented in synthesizable RTL, so that Verilog behavioral test benches with #delays don't work properly.

Design decisions made with some forethought at the beginning of the project helped to reduce the amount of time and resources spent throughout the project. By leveraging and sharing code, a small group of engineers was able to write code that we used at all phases of verification of the system, beginning at the block level and moving on up through the system level. The cycle-accurate models and test benches that we defined in the

early stages of the design cycle allowed us to develop implementation-independent drivers and test suites. We used these models and test benches throughout the complete design process, from behavioral to gate netlist.

Powerful verification features

We chose the Vera verification system from Systems Science (since acquired by Synopsys), which provides a fully concurrent hardware verification environment based on Vera-HVL, an object-oriented language for validation. The Vera tool offers many constructs that are often unavailable or very difficult to implement in Verilog.

Our verification environment employed several of the most powerful features of Vera:

Reentrancy and mutual exclusion. We needed to execute and control the execution of multiple tasks in a single cycle. Reentrant code allows for the intermingling of code execution in simulation, accurately mimicking real hardware. By producing back-to-back stimuli, this valuable capability can create contention on a chip or in a system. It is also useful for allowing multiple contexts to run within the same task. In such cases, embedded mutual exclusivity constructs such as semaphores avoid collisions on signals.

Figure	Accessing physical connections
Links from generic tasks (a) can access specific physical ports (b) and boundaries, simplifying validation suites.

Concurrence. Because the ASICs must deal with the multiple and concurrent activities that the multiple processors in our system create, code development requires abstract concurrence control and triggering mechanisms. Vera can spawn multiple concurrent processes and let them run in the background using enhanced fork/join constructs. The tool also contains embedded routines for terminating and completing concurrent processes.

Dynamic binding. Vera's generic methods and virtual port concept enabled us to write our code for the drivers just once and activate them multiple times with dynamic binding at run time from anywhere within the simulation. In Verilog, a similar function would have required multiple instantiations and copies of tasks at compilation time, thereby making code unnecessarily large and complicated. The actual binding to the virtual ports in Vera occurs through a bindvar embedded variable type, which is extremely useful when linked up with classes in our test code.

Floating expects. Floating expects allow an easy way to check results on any pin or bus. In Vera, the start of expect and the window size (in cycles) are full variables. As it monitors the signals, the tool indicates an error if it fails to find the value within the specified window. These expects also can be used for synchronization.

Object-oriented features. Vera supports object-oriented programming through the embedded class data type. OOP offers a powerful way to write self-contained models for transactors that each need their own data structures, like a PCI master or slave. Another useful application is to implement a memory or cache, using the tasks to read or write the memory.

Solitary refinement

Our basic verification flow starts with testing the individual modules as separate components. In the ASIC design and verification process, chip-in-isolation verification is one of the best ways to find functional bugs. The simulation runs at optimal speed, and tests and drivers can be designed in a stand-alone environment, easing the creation of contention tests and corner case tests. Designing, writing, and debugging the code, as well as ensuring the quality of the stimuli, takes a long time, however. Assigning verification engineers to the project, making them part of the chip development team, eases the task of integrating the verification environment into the rest of the design flow. The verification engineers can start to put together a test plan based on the design specification and can develop the validation environment before the design architecture is fixed, as well as provide critical early feedback to the design team.

We developed procedures and code to facilitate checking of each of the four main aspects of verification: logic, memory, interfaces, and the full system. We follow that order here, though the project specifics can dictate a different order.

Once armed with the chip specification, verification engineers can start to develop the code. The functionality of the chip defines the environment. For example, if the chip interface follows a particular protocol, its environment may differ from that of a datapath chip, like a crossbar. The idea here is to group signals together if possible. A VME-to-Futurebus repeater chip, for instance, processes two groups of signals, one for the VME side and another for the Futurebus side.

A crossbar chip can use a group for data and control. Given a four-port crossbar switch, the physical ports
and boundaries can be defined as P0_port, P1_port, P2_port, and P3_port (see the figure). The verification engineer can write a definition of virtual ports that uses the generic methods. The Vera environment can represent the interface that connects the verification environment to the design environment by:

interface XBAR {


inout [31:0] Data PSAMPLE PDRIVE #skew;


inout DataIn PSAMPLE PDRIVE #skew depth 2;


output [1:0] DataOut PDRIVE #skew;


output Clk CLOCK PDRIVE #skew;


output Reset PDRIVE #skew;


}

At run time we use the specific bindings from the physical DUT pins to these ports to dynamically call the tasks that will stimulate the design. This approach offers two advantages: It relieves the need for multiple copies of tasks and functions in our run time simulation environment, and allows us flexibility in debugging and writing tasks only once. Typical bind mapping for a given port (here, port0) appears below; similar code can cover ports 1, 2, and 3.

#ifdef XBAR_0


#define XBAR P0 //this will define the
		signals


#define XBAR_PORT P0_port // P0_data, and 	allow the bindvar of 


#include "../include/XBAR_if.vrh"// 			P0_port and allow tasks to drive $data,


#endif //which will map to P0_data


and 


XBAR_if.vrh contains the interface code 		for XBAR above and:


bind XBAR_signals XBAR_PORT{


data XBAR.Data;


datain XBAR.DataIn;


dataout XBAR.DataOut;


clk XBAR.Clk;


reset XBAR.Reset;


}

To exploit the port/bind construct, we can write the generic task of driving the data into the chip as:

task XB_drive_port with XBAR_signals(bit 		[31:0] data) { 


$datain = 1'b1;


@1 $datain = 1'bz;


$data = data;


@1 $data = 32'bz;


}

And to read data out of the chip:

task XB_read_port with XBAR_signals(bit 		[31:0] data, bit [1:0] dir) {


@1 $dataout = dir;


@1 $dataout = 1'bz;


@0,window $data == data;


}

The last statement in the preceding task indicates that Vera needs to see the data value on the signal within the window cycles indicated. Then, to transfer data from port 2 to port 0, these tasks are called by:

XB_drive_port with P2_port(31'hdeadbeed);


XB_read_port with 					P0_port(31'hdeadbeed,2'h2);

Concurrent test cases create multiple threads that run in parallel and try to stimulate the design under test simultaneously. The concurrent nature of accesses made to the DUT creates corner cases that uncover most hidden design bugs.

For example, the following pseudocode shows the sending of data from and to each device port:

for each_source_port {


for each_destination {


fork {


	create random_data;


	XB_transfer_data(source_port, 


		destination_port, data);


} join none

This code tries to create back-to-back transfers. Since the second drive should be blocked until the first one has had a chance to complete its tasks, we add the block-and-release mechanism to the drive task described above.

task XB_drive_port with XBAR_signals(bit 		[31:0] data) {


block (source);


$datain = 1'b1;


@1 $datain = 1'bz;


release (source);


block (drive_data_sem+source);


$data = data;


@1 $data = 32'bz;


release(drive_data_sem+source,1);


}

To model memory functions, we took advantage of Vera's object-oriented capabilities, which take code reuse a step further by including classes, such as the transactor and its subsets. The transactor class contains a memory class and a cache class, as well as local multiplexers that know the number of each type of legal transaction, and controls when to drive out another transaction of that type. Similarly, the tool's memory-locking mechanism and mutual exclusivity for data make it easy to lock an address for use by a specific process. For example, the cache class allows for cache fills, cache line lookups, and writebacks for victimized lines that are dirty.

class cache_type {


integer tb_status;


bit [3:0] size, associativity;


bit [2:0] state, status;


task cache_fill(..);


task cache_miss_cnt(..);

Do-it-yourself interfaces

The nature of our project demanded that we pay a good deal of attention to its interfaces. With the advent of functional blocks as cores, designers can choose to buy a standard interface, including the drivers and models, or develop the function from scratch. People tend to purchase these functional blocks because vendors guarantee that the design fits the standard. Purchased models, however, typically pose one major problem: Often, they provide only an encrypted core. The resulting lack of access to code can cause lots of debugging frustration. In addition, the encryption frustrates efforts to control and direct the device to create the type of traffic that can find corner case bugs.

The alternative is for the engineers to continue to develop the functions and write the drivers in-house so they can verify the standard interface I/O controllers in the system. Sharing these drivers among projects and groups can help to offset the cost of in-house development.

Our I/O controller employs a driver that obeys the bus protocol but uses a test-case call interface to simplify directed testing. One interface domain obeys a microprocessor protocol and the other an I/O bus protocol, such as PCI. Each interface can have a separate driver that interfaces directly to that set of pins. Each interface can have its own clock domain, uniquely identifying each domain.

The I/O controller is actually a two-chip set. One chip is the crossbar that routes the data and is controlled by the other chip, the I/O controller itself. In our chip-in-isolation environment, a behavioral crossbar written in Vera or in Verilog models the crossbar. The behavioral crossbar can monitor the boundaries and guarantee that the behavior and timing of signals are legal and acceptable.

An example test-case call interface for the PCI driver includes pci_master_read, pci_master_write, pci_slave_read, and pci_slave_write task calls. The tasks on the processor side may include proc_master_read, proc_master_write, proc_slave_read, and proc_slave_write task calls. The next layer of calls for a processor-to-PCI read and write would look like this:

task proc2pci_read(....){


fork {


proc_master_read(....);


pci_slave_read(...);


} join }


task proc2pci_write(....){


fork {


proc_master_write(....);


pci_slave_write(...);


} join }

As long as the lower-level tasks in the layers of tests are written correctly to prevent overwriting, a test case that performs reads and writes in a sliding window style may resemble:

integer delay_wr, delay_rd;


	set delay_wr, delay_rd directed or 			random;


for 0 to delay_wr{


for 0 to delay_rd{


fork{ 


wait delay_wr;


proc2pci_write(...);


} {


	wait delay_rd;


	proc2pci_read(...);


} join 


wait for_completion;


}}

These same test cases and drivers work when verification shifts its focus from chip-in-isolation to subsystem simulation. We removed the Vera-modeled crossbar used in the chip-in-isolation stage of the verification and replaced it with the real chip. The only other change is to remove the interface signals from the vshell. This aspect of our verification process offers tremendous value. We can verify that the crossbar chip continues to work in a much different environment, one that is protocol-oriented and connected to the actual chip, the I/O controller.

System verification

Once they've verified the individual pieces, the verification team can move on to ensure that the pieces work together. As the chip verification progresses, the drivers that control the chip interface also become more stable and robust. Engineers can use pieces of these drivers to construct functional drivers, such as the microprocessor transactor. Such modularity enables one person to read the specification for the interface, model the drivers, and then share the models with others trying to write similar drivers for these chips.

For the system-level verification, the test benches, models, and even the simulation environment may change to accommodate the differences. To make the process more compact and automatic, a Vera makefile reads a configuration file that defines the system simulation environment. The file delineates such variables as the number and types of boards and how they are populated. Therefore if the configuration file indicates that the system contains four CPUs, the simulator creates four CPU objects.

The effort it takes to verify complex chips generally outstrips the length of time or effort it takes to design them. Verification engineers need better (and their own) tools to keep up with the design schedule. In the past, verification was done in an ad hoc way, leaving much to be desired in the results. Tools that are designed with verification in mind can assist the verification engineers in defining a methodology that helps to find highly complex bugs. They can also help reduce the length of time it takes to accomplish the verification effort through the extendibility of driver design across projects and across the integration of ASICs or modules.

Sherri Al-Ashari is a lead verification engineer at Sun Microsystems Computer Corp. in Palo Alto, Calif. She worked on the first two UltraSPARCs for two and a half years and is currently working on Sun's next-generation enterprise servers.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  January 1999