Superlog adds a wealth of verification features to Verilog, enabling a single language for both abstract design and testbench creation. Co-Design Automation's new Universal (unified verification simulation algorithm) technology allows the new verification features to be simulated directly in the company's Systemsim simulation kernel, providing an efficient verification environment. That direct integration of verification capability helps eliminate performance and other productivity bottlenecks associated with existing, loosely coupled solutions.

To see how to put some of those ideas into practice, let's look at a typical verification environment for an ATM router, such as the public challenge circuit distributed through the Verification Guild newsletter. Although this is one example, general concepts apply to a wide variety of applications.

A typical verification environment consists of a testbench, which instantiates the design under test (DUT) and includes stimulus-generator and response-checker bus-functional models connected to various interfaces of the DUT. In this example, the ATM router receives packets on each of four RX ports and routes them through to one or more of four TX ports, depending on the routing information contained in the packet. A CPU interface is used for communication setup and status information to and from the router.

Once the infrastructure has been set up for communicating with the DUT, the testbench must provide an effective method of describing the test scenario to be exercised. Ideally, the test should be written at an abstract level, describing operations in terms of the functional transactions to be performed, without getting mired in the implementation details of the device itself. That insulates the test and testbench from functional implementation changes in the DUT and makes its reuse on future designs more straightforward.

In our ATM example, the test needs to perform two basic activities. First, it creates ATM cells and sends them into RX ports of the router, followed by checks to make sure that cells come out the appropriate TX port. That means that we need a way to build an ATM cell. As shown in the accompanying figure, Superlog lets you declare a data type, just as in C, to describe the contents of the cell (a).

Systemsim's CBlend technology actually allows you to import the type declarations directly from C, as we have done here with the cell_header_t type. The syntax for importing from C is a simple declaration, shown in (b).

In addition to importing the typedef-type declaration, we have imported a function, hec(), which calculates the header error correction field of the cell. The hec algorithm is distributed as C code. Until now, the only way to use it in simulation was either to write an HDL version of the algorithm, which is difficult to verify and prone to errors, or to use the C code and pass the data into the simulator via PLI, which requires a PLI wrapper to be created.

Systemsim allows you to call the C function directly, eliminating those costly steps. By directly calling C, you also eliminate the performance bottleneck of using PLI to transfer hec data into the simulator.

With the ATM cell structure defined and an efficient method of calculating the hec, the test needs to tell each of the ATM cell generators (AT0 to AT3) to generate streams of cells to pass into the router. Each generator contains a function that builds a cell with random data in it for both the header and payload. It also includes a queue (or variable-length array) to hold all of the cells as they are generated so that they can be sent in the right order.

As in C, Superlog provides pointers to data objects to minimize data copying and improve the efficiency of the simulation. In fact, as shown in (c), Systemsim uses safe pointers to make the code easier to debug.

The Superlog language includes powerful randomization utilities that allow you to generate random values of specific types, subject to given constraints such as values and ranges. Randomization may be performed either declaratively or procedurally using a weighted case statement, as shown in (d).

There are multiple independent random number generators built into Systemsim, including seed management utilities to ensure stability of the random values across multiple runs. Random number generators also provide a built-in coverage feature that allows you to keep track of generated values and modify constraints on the fly, ensuring that an optimal stream of values is generated. As random packets are generated and put in the transmitter bus-functional model (BFM) queues, expected results packets are directed to similar queues in checker BFMs, to allow the test to be self-checking.

Expected results can be calculated in Superlog, or, if there is a C reference model, it may be run using CBlend to provide the correct calculation directly. Using dynamic processes-another feature of Superlog-the test can be structured to queue up traffic on all interfaces simultaneously.

By creating an associative array of queues in each checker, expected results are queued according to the RX port on which they were received. By building a bit of debug-specific information into each packet-for example, which port it came from-the Checker can compare each outgoing packet against the right queue.

Managing expected-result queues effectively allows the test to be independent of implementation decisions, such as which channel has priority, allowing the designer to experiment with different arbitration schemes, for example, without changing the test. The built-in coverage features of Superlog are used to ensure that specific scenarios are exercised, such as making sure that some number of packets are transmitted from each input port to each output port.

This coverage information can be fed back into the test so that the con-straints may be modified automatically to avoid resending packets through ports that have already been verified. Systemsim, through its Universal technology, provides this communication directly, without having to go through the Verilog programming language interface.

Encapsulation using interfaces
How many times have you been forced to make a last-minute change to the pinout of a design? There are few things more painful and fraught with potential errors. Wouldn't it be easier if the signal interface was an element unto itself, allowing interface changes to be made once and automatically propagated to every device that uses it? That's what Superlog interfaces let you do. In effect, an interface does for wires what structures do for data.

The modport specifier in the interface code shown in list e (page 80) provides some functional abstraction in addition to the structural abstraction of bundling signals in an interface. In the ATM example, RX and TX ports of the router all use the same interface declaration, with the directionality controlled by modports.

Protocol checking is performed in Superlog via procedural assertion statements. These statements preserve the familiar procedural flavor of Verilog but provide additional capability to specify combinatorial or sequential behavior.

This article focuses mainly on the uses of Superlog for verification. It's important to remember that the design engineer may also use Superlog to describe the design. The designer becomes an active participant in the verification process, reducing misunderstandings and saving time.

Peter flake is Chief Technical Officer and Tom Fitzpatrick is a member of the staff at Co-design Automation (Los Altos, Calif.; www.co-design.com).