C++ testbench verifies path to Utopia

Utopia was defined solely to connect asynchronous transfer mode (ATM) layer designs to one or more PHY layer designs (such as OC3 or OC12). Although there are now four levels of Utopia, the first two were created to match the OC1, OC3 and OC12 transfer rates of 51.84, 155.52 and 622 Mbits/seconds respectively.

The complex Utopia interface transfers ATM cells that comprise a 4-byte header, a 1-byte header error correction (HEC) and 48 bytes of payload. The header contains fields that communicate routing, priority and payload content information to ATM systems. HEC is calculated over the 4 bytes of the header as the ATM cell is routed across the LAN or WAN. Recipients of an ATM cell are tasked with checking the HEC and discarding or repairing the cell if an error is detected.

• Create a test plan and write tests that send/receive ATM cells to stimulate the design under verification (DUV).
  
• Simulate and execute the tests to check the response of the DUV to verify correct functional behavior.
  
• After all problems are found and fixed in the DUV, testbench and tests, check the functional coverage of the test suite to decide whether the verification process is completed or whether more tests are needed.
  

Building the models
Creating transaction verification modules (TVMs) is the first step in modularizing a verification environment. TVMs are designed for and connected to primary interfaces of the design and provide the translation between the two primary abstractions in the testbench: transactions and the interface signaling protocol. The Utopia interface comprises a TX and an RX protocol. Because these protocols are different but similar, we have created a C++ TVM per interface using the open-source TestBuilder C++ class library.

The Utopia TX and RX Master TVMs have a test API that allows our tests to define and manipulate ATM cells, send and receive ATM calls, control handshakes, delay transfers, inject HEC errors, check for or ignore HEC errors, inject parity errors and check for or ignore parity errors.

Tests are also written in C++ and can take advantage of OOP techniques to make them reusable and extensible. Tests stimulate the DUV and check the results. They are written at the transaction level, as opposed to the lower signal-abstraction level. They program the DUV's internal registers, manipulate ATM cells, send and receive cells and control error conditions and handshaking. Utopia's goal is to test the breadth of the Utopia protocol. As mentioned above, the open-source TestBuilder C++ class library provides a powerful tool kit for creating tests that do this. In particular, we favor constrained random tests that randomize as many parameters of a scenario as makes sense (for example, it makes sense to randomize the ATM header, but not the bus width-a physical attribute). Constraints are placed on parameters to make the value selected during execution fall within a real-world range or within an illegal range desired by the test writer to test error conditions.

An octet delay is a good example of the sort of random operations that were performed in this test. The code is shown in the accompanying listing. Two objects are used during this operation: delay and octetDelayBag. Their types (tbvSmartIntT and tbvBagT) are supplied by the TestBuilder class library. The smart objects in the library are designed to make random operations easy. Bags are structures that are useful for a number of applications.

In Lines 4 and 5 the bag is used to set up a statistical function that implements the probability that 0 will be chosen 80 percent of the time and 1 will be chosen 20 percent. This is used to decide whether or not the test would create octet delays (when 1) or not (when 0). Line 6 of the code snippet constrains the delay variable to random numbers between 0 and 7. Large delay values are to be avoided or the simulation may never finish.

Line 9 is the first random selection. Here, we reach into the bag (using the peekRandom method) and pull out a number that determines whether or not to delay. The second random selection occurs on Line 17. By executing the delay object's randomizing method, a random number is chosen taking into account any constraints the object has set up (in this case 0 to 7).

These delays are stored in the enableControl array contained in the ATM cell object. Later, the test will call the TVM's sendCell task to transfer this atmCell object to it. The TVM accesses an entry in the enableControl array for every octet it transfers and delays that octet by the value contained in the array before sending the octet to the DUV. Using OOP it is possible to create a straightforward and uncomplicated test that produces powerful and complicated constrained random stimulus while it checks the results of the simulation.

Finding the root problem
To cut through the complexity of this simulation, the Cadence Verification Cockpit's Signalscan Waveform and Transaction Viewer are used to view the signals, the test level and ATM cell-level transactions. Viewing transactions helps to determine where problems originate. Signalscan can display transactions that are recorded by the test and TVMs during simulation.

Eventually, the design and tests will cease producing errors. Here we move to Step 3 in the verification process to evaluate the functional coverage of the simulations. Functional coverage requirements are derived from a test plan, which, in turn, is driven from the functional specification. These requirements are converted into functional coverage queries that are defined and executed in Verification Cockpit's Transaction Explorer.

Queries are algorithmic programs that access the information recorded in the transactions stored in the Signalscan SST2 database. Each query has a goal associated with it; if the goal is achieved, the functional requirement has been satisfied. If not, additional tests are needed.

Transaction queries allow functional coverage to be performed at a higher level of abstraction, which provides the opportunity to look for more complex relationships than would otherwise be possible. If any of the query goals were not met, you should go back to Step 1 and reevaluate your test plan. If, however, your goals were met, you have the information to make the all-important decision of when to tape out.

Karl Whiting is Architect, Methodology Services, in the Verification Platforms Group. Leonard Drucker is Senior Core Competency Technical Lead at Cadence Design Systems Inc. (San Jose, Calif.).