Stimulus extraction and sequence generation for an electric device under test

1. Technical Field

The present invention relates in general to the field of computers, and in particular to the simulation of electronic Devices Under Test (DUT). Still more particularly, the present invention describes a graphical method of generating test sequences based on current simulation results.

2. Description of the Related Art

The product development of a System On a Chip (SOC) encompasses various levels of verification that include functional, behavioral and formally parameterized testing. Several techniques and methods are used to determine the completeness of the verification effort. One common method is to generate a comprehensive list of complex stimulus sequences that represent the various scenarios needed to validate the Design Under Test (DUT), which is a combination of the SOC hardware and a software wrapper associated with the SOC. As the complexity of the DUT grows, so does the complexity of the needed scenarios.

The traditional method of generating these complex scenarios is through manual coding, or parameterized stimulus generators. The required time to produce such design verification code can be very long, the task tedious, and error prone. In addition, there are such scenarios called corner cases, which are defined as very specific although very unusual complex DUT operating scenarios that have the property of being difficult to predict. It is difficult, if not impossible, to code in a directed test case that represents a corner case.

Another method used to hit these corner cases is random test case generation. However, such random test cases can take millions of run cycles to achieve a single corner scenario.

What is needed, then, is a method for creating complex test scenarios that does not require excessive manual coding or the use of excessive random test cases.

The present invention is thus directed to a method and system that utilizes a graphical interface that enables a user to select and capture building blocks of a Device Under Test (DUT) test scenario from a previously run test case or from multiple stimulation results. Each of these extracted building block events or “tags” are created from a slice of a graphical stimulation view, and is then converted into a coded stimulus written in a high-level language code that represents the condition(s) that created the graphical simulation view. These coded stimuli (representing the tags) are stored in a library. To generate a corner case scenario or sequence in the DUT, a user utilizes a graphical interface to select the different extracted tags from the library and combines them together.

The present invention improves upon prior-art method for creating test case stimuli by reducing the man-hours and the machine cycle time needed to create corner case scenarios, and improves verification coverage for the DUT, particularly in the area of multiprocessor (MP) and cache coherency where many corner cases are never simulated under test conditions. Generating scenarios using visual inspection of the stimulation results is less tedious, and can provide a more logically accurate scenario than manually coding it.

The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description.

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further purposes and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, where:

FIG. 1 depicts a test bench environment in which the present invention is utilized;

FIG. 2 depicts an original stimulation results view of signals created in a Device Under Test (DUT);

FIG. 3 illustrates a time-slice of stimulation results shown in FIG. 2 ;

FIG. 4 depicts different events within each time-slice shown in FIG. 3 ;

FIG. 5 is a written description of the events graphically shown in FIG. 4 ;

FIG. 6 shows the written description of FIG. 5 described in a high-level computer language; and

FIG. 7 is a flow-chart of steps taken in a preferred embodiment of the present invention.

With reference now to the figures, and particularly to FIG. 1 , a test bench 100 is presented. Test bench 100 includes a simulation environment 102 , which includes a Device Under Test 104 , which is a combination of hardware (real or simulated) and a test software environment associated with that hardware.

DUT 104 outputs simulation results 106 , which are a “snapshot” of logical signals within DUT 104 (or alternatively, may be an output from DUT 104 ). Simulation results 106 are viewable on a viewer 108 , which displays simulation results 106 along a time line, or events schedule.

The present invention includes selecting one or more time slices 110 representing events during particular time period. For example, time slice 110 a captures events between times t 1 and t 2 , while time slice 110 b captures events between times t 3 and t 4 .

One or more of the time slices 110 are then introduced as stimulus 112 into DUT 104 , in a manner described in further detail below.

With reference now to FIG. 2 , an original simulation results view 200 is shown. Original simulation results view 200 represents signals in DUT 104 . Preferably, the signals represented are internal logical signals within DUT 104 , although they may be input signals to or output signals from DUT 104 . Original simulation results view 200 thus shows results that have been produced in or by DUT 104 , either in real hardware or by a simulation, which results are examined via a waveform viewer such as viewer 108 shown in FIG. 1 . The exemplary signals chosen and shown are SIG_A, CAP_BUS[0:32], and ASSERT_Q. SIG_A may be an input or an internal signal, such as from a signal checker (not shown) or a driven input, into DUT 104 . CAP_BUS[0:32] is a signal on a Command Address Packet (CAP) 32-bit bus, and may represent an input, an output, or an address. ASSERT_Q is typically a logical flag, which is a conditional input identifying a logical condition.

Referring now to FIG. 3 , a tagged view 300 shows multiple time windows 310 a - c , which have respectively been tagged at T 1 , T 2 and T 3 . These tags constitute the windows to be extracted, and encompass particular events such as T 1 .EV 1 -T 1 .EV 3 ; T 2 .EV 1 -T 2 .EV 3 ; and T 3 .EV 1 -T 3 .EV 5 , shown in the extracted view of FIG. 4 . Each of the tagged windows is arranged in a particular sequence (e.g., T 1 followed by T 2 followed by T 3 ). However, in a preferred alternate embodiment described below, these sequences can be re-ordered to create new scenarios.

Note that in FIG. 4 , the event number does not necessary correspond to a time sequence. For example, in time window 310 a (T 1 ), event T 1 .EV 1 occurs after event T 1 .EV 2 and event T 1 .EV 3 . These events are seemingly randomly named to emphasize an embodiment of the present invention in which individual events can be “cherry picked” out of a particular time window 310 , as opposed to an entire time window 310 representing a grouped set of events.

Once a sequence of tags is extracted, as shown in FIG. 4 , particular events are automatically categorized as shown in FIG. 5 , which represents an event capture view 500 . Each event is a basic building block in a tag (time window). In one preferred embodiment, as indicated above, multiple events are grouped together to generate an elaborate sequence, which is used to generate a particular verification scenario.

Referring again to FIG. 5 , consider the events in T 1 . Event T 1 .EV 1 is an assertion of Q, as graphically depicted in FIG. 4 . Event T 1 .EV 2 is a generation of a Signal A representing that a logical signal has gone from High to Low. Event T 1 .EV 3 indicates that tag T 1 drives the value on the CAP bus to an unknown state.

Likewise, in T 2 , event T 2 .EV 2 shows that ASSERT_Q is asserted while the value on the CAP bus is FFFF_FFF1 (T 2 .EV 2 ) only if Signal A is High (T 2 .EV 3 ). In T 3 , if Signal A is going from Low to High (T 3 .EV 1 ) or Signal A is going from High to Low to High (T 3 .EV 2 ), and if the value of the CAP bus is FFFF — 0000 (T 3 .EV 4 ), then ASSERT_Q is asserted (T 3 .EV 5 ). However, if the value of the CAP bus is A5A5_FF03 (T 3 .EV 3 ) or some other non-FFFF — 0000 value, then the ASSERT_Q is not asserted.

The conditions for asserting ASSERT_Q are shown in a high-level language pseudo code shown in FIG. 6 , which depicts a stimulus generation view 600 . Exemplary high-level languages that may be used include any Hardware Descriptor Language (HDL) such as Register Transfer Language (RTL), or any other high-level language such as C, etc. Preferably, the pseudo code is grouped together as a DUT stimulus 602 , to reflect event conditions shown in respective tags (event windows 310 ). These DUT stimuli 602 can be applied to the DUT as new stimuli in subsequent test iterations.

The present invention is thus summarized in the flowchart shown in FIG. 7 . After initiator block 702 , a new stimulus is applied to the Device Under Test (block 704 ), such as depicted as DUT 104 in FIG. 1 . An original simulation results view, such as shown in FIG. 2 , is then created (block 706 ). Time based windows are then selected and tagged (block 708 ), as described in FIG. 3 . The tagged windows are extracted to identify events within the selected time frames (block 710 ), as shown in FIG. 4 . The identified events are captured as extracted expressions (block 712 ), as shown and described in exemplary form as “Extracted Expressions” above in FIG. 5 . The expressions are then stored into a library.

As stated in block 713 , the extracted expressions may be organized and/or re-arranged in any order that the test engineer desires. For example, a compilation of expressions may include those shown and described above in Tags T 1 , T 2 and T 3 . However, the temporal order of the tags may be re-arranged, such that, for example, the events described in T 3 precede those in T 2 , etc. Therefore, many different combinations are available to create different event scenarios. These many combinations make it easier for the test engineer to create a combination that emulates a corner case as described above. The reordered sequences are stored into the expressions library for future reuse.

As further described in block 713 , these extracted expressions, as well as other events from the library and/or the currently presented tagged window(s) are then organized and stored as new sequences back into the library. That is, previously captured events may be reordered and/or rearranged to describe new sequences, which may then be stored in the library for use as future DUT stimuli.

The extracted expressions and/or re-organized sequences are translated into high-level code (block 714 ), as shown in FIG. 6 .

These translated sequences from the captured sequences, as well as other events from the library and/or the currently presented tagged window(s) are organized and stored as new sequences back into the library. That is, previously captured events may be reordered, rearranged and/or renamed to describe new sequences, which are then stored in the library for use as future DUT stimuli.

A query (query block 716 ) is made as to whether another DUT simulation/stimulation test is to be made. If not, the process ends (terminator block 718 ). If so, however, then the generated DUT stimuli are applied to the DUT (block 720 ), and the process re-iterates. Note that the DUT stimuli are preferably from a library of DUT stimuli code that has been generated in previous iterations.

The present invention thus presents a new and useful method of graphically and selectively time-slicing particular window(s) of simulation results for one or more particular runs. A test engineer is thus able to organize/arrange these windows of captured events, produce specific test sequences, and thus generate traditionally difficult scenarios such as corner cases.

It should be understood that at least some aspects of the present invention may alternatively be implemented in a program product. Programs defining functions on the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., a floppy diskette, hard disk drive, read/write CD ROM, optical media), and communication media, such as computer and telephone networks including Ethernet. It should be understood, therefore in such signal-bearing media when carrying or encoding computer readable instructions that direct method functions in the present invention, represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.