Abstract:
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, which slice is 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 create 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.

Description:
BACKGROUND OF THE INVENTION 
   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. 
   SUMMARY OF THE INVENTION 
   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. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     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. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
   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.