Introduction

In this paper, the TIMEDIAG/GENRAND tool set, developed to assist in designer-level logic verification, is described. The models on which the tool set is based are discussed, along with the requirements for solving the problems of designer-level verification. The features of TIMEDIAG/GENRAND are detailed, followed by a representative application used during implementation of the S/390* G4 system.

The irritator behavioral/test-case driver model
A classic method of verifying logic is the use of irritator behaviorals. In this model, the logic under test is "surrounded" by dummy logic whose purpose is to drive the inputs and check the outputs of the logic under test. Because this dummy logic, or "behavioral," is used solely for logic verification, the choice of source language is not restricted to the design language. In later stages of verification, behaviorals are replaced with the real design that was being emulated. But by using behaviorals first at a lower level of simulation, a verification expert can exert greater control over the smaller piece of logic, thereby testing more permutations and states in less time. Using irritator behaviorals is a highly effective method for verification [1].

A "behavioral" generally consists of two parts that work hand in hand: the interface protocol handler and the driver. The interface protocol handler is prompted by the driver to provide a specific stimulus to the logic under test. When the logic responds to the stimulus, the interface protocol handler receives the response and packages it back to the driver.

The driver can be thought of as the "brains" of the behavioral. It decides what to send into the logic and verifies the correctness of the output. A typical driver uses a probability table to choose which legal stimulus it will initiate. The checking logic that must be built into the driver can be far trickier to implement. Because the complexity of the logic under test generally increases with its size, a driver's checking logic on a large model is often quite complex. This is less of a problem with smaller, designer-level models, where fewer permutations and less complexity make for simpler prediction of outputs. However, it is a key to designer simulation, because a good methodology will be able to capitalize on the simpler checking requirements.

The interface protocol handler is the interpreter between the driver portion of the behavioral and the logic under test. With regard to the logic under test, the behavioral emulates the interface actions of the real logic that will surround the logic under test. When the driver portion of the behavioral "decides" to send a sequence, it is up to the interface protocol handler to create the correct signals for the logic. The interface protocol handler also monitors the outputs of the logic, packaging output sequences back to the driver so that it can check for correctness.

The challenges of designer-level verification
The challenge of applying the irritator behavioral model to designer-level logic verification is less a technical challenge than a time-to-market concern. A quality irritator behavioral model is quite effective, but takes time to plan and implement. While it is a cost-effective approach to verifying large portions of logic, writing individual irritator behavioral models for testing each designer's logic is not feasible.

Without the power of irritator behaviorals, designers traditionally test their logic with a series of hard-coded test cases. But writing hard-coded test cases to verify one's own logic creates a series of problems:

• Simplistic test cases are created. Hard-coded test cases generally verify basic scenarios, but do not stress the logic hard enough to cover complex interactions. It takes substantial effort to create a large number of test cases that thoroughly test the logic with multiple interactions and permutations.
• A new test-case language must be mastered in order to write effective hard-coded test cases. The user must learn a test-case language that allows manipulation of signals, monitoring events, and clocking.
• Maintenance of test buckets can be time-consuming. Many hard-coded test cases are timing- and signal-name-dependent. If a cycle is added within the logic, or the name of an interface signal changes, many test cases may have to be updated.
• A catch-22 problem occurs with the designer writing the test cases to test his own logic. Consider a case in which a designer believes his logic accounts for all valid permutations that can occur. If he has in fact missed a case, how can he be expected to write a test case that will uncover his own oversight?

• Complex scenarios are created under GENRAND. It drives many different timing diagram permutations at different times throughout a test case. Window conditions, created by changing the timing on the initiation of sequences, are stressed. This helps solve the catch-22 problem as well, because the designer no longer has to dream up different scenarios--GENRAND does it instead.
• No new language has to be learned. The timing diagram format is familiar to designers.
• There is little maintenance with TIMEDIAG and GENRAND. If a signal name changes or a timing sequence is updated, all that is required is the use of TIMEDIAG to update the sequence. There are no buckets of test cases to change.

TIMEDIAG is a timing diagram editor. The file that is created by TIMEDIAG, when read by GENRAND, can be thought of as roughly equivalent to the interface protocol handler of the irritator behavioral model. This TIMEDIAG file contains one or more timing diagrams that describe the interfaces to the logic under test. GENRAND is the driver portion of the verification model. After reading the TIMEDIAG file, GENRAND uses pseudorandom algorithms to decide which interface actions to initiate. When results are returned, GENRAND checks the correctness of the outputs and takes appropriate action by initiating further stimulus, responding to outstanding requests, or flagging errors or miscompares.

TIMEDIAG

Each timing diagram, in its simplest form, is a matrix of cycles and signal names. The cycle numbers C0, C1, ···, CN span the top of the matrix. The signal names and bit ranges constitute the rows of the matrix. Each of the values within the matrix is simply the value of that signal on that cycle. Each signal name is identified as an input to the logic or an output from the logic. Input signals have their cycle values entered into the logic by the test driver (GENRAND), while output signals have their cycle values checked for correctness by the test driver.

TIMEDIAG supplies all of the basics needed to edit each timing diagram matrix. A user can add, delete, copy, move, or change signal names. Cycles can also be added, deleted, copied, or moved. Finally, each cycle value in the matrix can be edited or copied from another value. Each diagram represents a generalized interface sequence. A given timing diagram is considered generalized because TIMEDIAG does not require exact cycle timings or constants for cycle values (variables, signals, and functions are allowed). Instead, TIMEDIAG includes features that allow the user to specify a sequence that may cover many permutations of an interface protocol.

TIMEDIAG features
Three basic features allow a user to create general timing diagrams: function values, limitors, and looping/recurring cycles.

Function values
TIMEDIAG allows for many different data types and functions to represent cycle values. While constant values are the simplest form, signal names and arithmetic operators can also be used to represent the value of a signal on a given cycle. Furthermore, a set of built-in functions such as the "random value" function and the "choose from a list of values" function are supplied. If none of these built-in functions adequately describes a cycle value, a user-defined function written in C can be dynamically linked into TIMEDIAG/GENRAND.

Limitors
A cornerstone of the representation of an interface is the statement of the time at which it is legal to initiate the timing diagram sequence. TIMEDIAG defines this as a limitor. Each timing diagram has a limitor that may be independent or may be coupled to other timing diagrams. The limitor concept is especially important when running simulation, because GENRAND uses the limitors to decide which timing diagrams it can legally initiate on any given cycle.

TIMEDIAG uses four select buttons to help the user define a limitor. The first button, none, states that the timing diagram sequence may occur at any time and may be pipelined--there are no restrictions on when a "none" timing diagram may be initiated. The second select button, the condition limitor, uses a Boolean expression to evaluate whether or not the timing diagram may be initiated. If the statement evaluates to "true" on a given cycle, the timing diagram sequence may be initiated. The Boolean expression may be simple (example: AVAILABLE = '1'B) or complex [example: X = '1'B & (Y > 2|Z < 3)]. The third select button, the delay limitor, states that there must be a gap of some number of cycles between the initiation of two instances of timing diagrams that share the same delay limitor variable. This is useful in cases where, for example, a two-cycle gap is required between commands. The last select button, the max limitor, prevents the timing diagram from having more than some number of outstanding instances. For example, if a timing diagram were not allowed to be pipelined, the max limitor would be used with a value of 1. An example limitor update screen appears in Figure 3 (shown later).

It is legitimate for more than one of the last three select buttons (condition, delay, and max) to be used in a single limitor. As an example, consider an interface that can accept a command but may require up to 20 cycles to respond to that command. If the logic has four command buffers to hold outstanding commands but needs two cycles between each command in order to load the buffer, the proper limitor would be a "max of 4" and a "delay of 2." This same logic might have an "unavailable" line as an output, which, when set to '1'B, meant that no commands could be accepted. The condition limitor with "UNAVAILABLE = '0'B" would also be used in that case.

Timing diagram limitors can be used to couple timing diagrams or to prevent other timing diagrams from initiating. Multiple timing diagrams can be "coupled" by

• Using the same signal in both condition limitors.
• Using the same delay variable in both delay limitors.
• Using the same outstanding variable in both max limitors.

Recurring/looping cycles
Recurring or looping cycles help describe an interface where the timing between events is not fixed. In general, a recurring cycle says, "wait in this state until some event occurs" or "wait in this state for some number of cycles." Therefore, a recurring cycle is defined by its end condition.

TIMEDIAG allows for three possible end conditions: 1) wait for a condition to occur; 2) loop for a fixed number of cycles; or 3) loop for a (bounded) random number of cycles.

GENRAND

GENRAND does not determine the sequences before run time. Instead, GENRAND runs along with the simulator, using the timing diagram limitors and a random number generator to decide whether or not a timing diagram will be initiated on a given cycle. Once initiated, GENRAND emulates the timing diagram sequence in the following cycles until the timing diagram is completed. GENRAND continues to drive multiple timing diagrams until it either detects an error or runs to a predetermined quiesce cycle. The effect of this is that multiple window conditions are tested throughout a successful test case.

Timing diagram instances
GENRAND uses the TIMEDIAG file to learn the interface protocols. The program then initiates interface sequences as specified in the timing diagrams (each interface sequence is an "instance" of that timing diagram), at random intervals as allowed by interface protocol. In fact, the same timing diagram will probably be initiated multiple times in a given simulation run. The simulation cycle in which an instance is initiated is not decided by the cycle labels (C0, C1, etc.) in the timing diagram. It is randomly chosen using the limitor conditions and the slide bar probability. However, the cycle labels in the timing diagrams can be mapped to the starting simulation cycle of a given instance. An instance of a timing diagram becomes "outstanding" or "bookmarked" when GENRAND randomly decides to initiate that timing diagram and the protocol allows for it. This instance is then bookmarked at timing diagram cycle C0. The bookmark remains open (and the instance thus remains outstanding) through the following simulation cycles until the last cycle of the timing diagram is executed.

Under GENRAND simulation, pipelining of a given timing diagram can occur if the protocol allows it. Therefore, multiple instances of the same timing diagram can be bookmarked at once, with each possibly in a different portion (Cx cycle) of the timing diagram. The random occurrence of instances creates the desired complex environment. In order to track the instances, GENRAND creates a file that includes statistics about the occurrences of each timing diagram during the course of a run. A trace of the timing diagram instances can optionally be created as well. These tools are very helpful for problem debugging, which can be performed by recreating the same test case (by reusing the initial 32-bit seed).

TIMEDIAG/GENRAND usage for S/390 CMOS processor development

An example of the designer-level verification using TIMEDIAG and GENRAND is described next.

Operand fetch control verification with TIMEDIAG/GENRAND
Traditionally, among the most difficult portions of logic to verify have been the instruction unit's operand fetch controls (OFC). The OFC interfaces mainly with the instruction unit's address adder and operand buffer controls, and with the buffer control element (BCE). Instructions are decoded and sent to the address adder, where operand addresses and request commands are sent to the OFC. The OFC allocates operand buffers, requests the data from the BCE, then monitors the BCE response and the return of data to the operand buffers. Figure 1 shows the flow of control through the OFC.

Figure 1

For the S/390 G4 CMOS processor, the OFC logic was tested using TIMEDIAG/GENRAND. The effort took one person about two months to complete. Three weeks of initial setup were followed by five weeks of testing and timing diagram enhancements. The strategy used to create timing diagrams for OFC verification was to write separate timing diagrams for each type of request. There were three main categories of timing diagrams, with an overall total of fourteen timing diagrams. The first category was for initial operand buffer requests from the address adder. Five separate timing diagrams were used for these initial operand requests: fetch, store, store-fetch, storage-to-storage request part one, and storage-to-storage request part two. The second main category of timing diagrams were the BCE interface diagrams, of which there were also five. Each of these diagrams represented one of the possible manners in which the BCE could respond to the OFC request: immediate, immediate lost, delayed by two cycles, delayed by two cycles and lost, and delayed long. The final category of timing diagrams represented checking and miscellaneous functions. The four timing diagrams in this category were "always," continuation fetch checking, incremental fetch request checking, and operand buffer release checking. Figure 2 shows the TIMEDIAG main window, which contained the fourteen timing diagrams.

Figure 2

Address adder initial request timing diagrams
The five initial request timing diagrams emulated the request protocol from the address adder to the OFC (transfer 1 in Figure 1). After an instruction was decoded, the address adder generated the appropriate request type (fetch, store, store-fetch, storage-to-storage request part one, and storage-to-storage request part two). The operand fetch controls are not privy to the actual instruction that was decoded; the OFC has to know only the type of instruction. Furthermore, the implementation of the OFC allows for any sequence of requests, with the sole exception that a storage-to-storage request part one must be followed by part two of the storage-to-storage request. Therefore, the timing diagrams were set up to allow for fetch, store, store-fetch, and storage-to-storage part one to be chosen at random. When a storage-to-storage part one occurred, these four commands were locked out until the storage-to-storage part two timing diagram was initiated. The only other restrictions on the initiation of the address adder request timing diagrams were that only one request could be initiated per cycle, and that the following three OFC signal settings must be true:

aa_ofc_available=1

aa_ofc_block_req=0

aa_ofc_hold=0