Abstract:
A method and system for identifying logic function areas, which make up a virtual machine, that are affected by specific testcases. A Hardware Descriptor Language (HDL) is used to create a software model of the virtual machine. A simulator compiles and analyzes the HDL model, and creates a matrix scoreboard identifying logic function areas in the virtual machine. A complete list of testcases is run on the virtual machine while a monitor correlates each testcase with affected logic function areas to fill in the matrix scoreboard. When a subsequent test failure occurs, either because of a modification to a logic function area, or the execution of a new test, all logic function areas that are affected, either directly or indirectly, are identified.

Description:
BACKGROUND OF INVENTION 
   1. Technical Field 
   The present invention relates in general to the field of logic design testing, and in particular to the accurately defined logic areas in the logic design. Still more particularly, the present invention relates to a method and system for associating specific logic areas with specific tests, such that a change in the specific logic area or a change in the test will require re-testing only affected logic areas. 
   2. Description of the Related Art 
   Building computer logic takes many steps before the computer logic is physically manufactured. The logic designer typically uses synthesis tools, known as Hardware Descriptor Languages (HDLs), to describe, design and document electronic circuits, as well as simulating faults, in software simulations of hardware. Examples of HDLs are VERILOG® and VHDL (Very-high-speed-integrated-circuit Hardware Descriptor Language) for Very Large Scale Integrated Circuits (VLSICs); and Register Transfer Language (RTL) to describe registers in computer logic and the way that data is transferred between such registers. By including a description of interfaces for logic and the logic&#39;s behavior, HDLs simulate physical hardware to such an extent that a virtual machine can be constructed in software alone. Such virtual machines are made up of multiple Finite State Machines (FSMs), also referred to as function areas or logic areas. Examples of FSMs are error correction logic, arbitration units, flow-control management units for determining if packets can be sent, etc. 
   After being constructed in software, the virtual machine is tested using an Architecture Verification Program (AVP), which is a test-case format that specifies an initial input and expected output of the virtual machine. The AVP is made up of multiple testcases, each of which affect one or more FSMs. Although an AVP may be useful in determining if an entire virtual machine is working, erroneous outputs from the virtual machine alone do not identify which FSM or FSMs are responsible for the failure. While documentation comments in the AVP may attempt to identify affected FSMs and thus the source of the failure, such predictions are rarely complete due to unexpected consequences of test software on FSM architecture, as well as unexpected anomalies in the FSM architecture itself. Thus, upon a test failure, the tester of the virtual machine must modify the FSMs predicted by the AVP programmer to be affected by the AVP, and then the entire AVP is re-run. Such a process is very time consuming, as a full AVP may take days to run, making such a process inefficient. 
   What is needed, therefore, is a method of accurately identifying which FSMs are affected by a testcase. This would allow an engineer to adjust/correct only FSMs affected by a failed testcase. Such a method also would allow the engineer to make changes to the virtual machine, followed by re-testing of only affected FSMs, thus reducing the time to re-test the newly modified virtual machine. 
   SUMMARY OF INVENTION 
   The present invention is directed to a method and system for identifying logic function areas, which make up a virtual machine, that are affected by specific testcases. A Hardware Descriptor Language (HDL) is used to create a software model of the virtual machine. A simulator compiles and analyzes the HDL model, and creates a matrix scoreboard identifying logic function areas in the virtual machine. A complete list of testcases is run on the virtual machine while a monitor correlates each testcase with affected logic function areas to fill in the matrix scoreboard. When a subsequent test failure occurs, either because of a modification to a logic function area, or the execution of a new test, all logic function areas that are affected, either directly or indirectly, are identified. This accurate identification allows a tester to correct only such affected logic areas, thus resulting in a savings in test time and resources. 
   The above, as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description. 

   
     BRIEF DESCRIPTION OF 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 objects 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 logical device under test (DUT), including multiple logic areas; 
       FIG. 2  is a block diagram of software used by the present invention, including a scoreboard generating monitor; 
       FIGS. 3   a  and  3   b  illustrate the scoreboard, generated by the monitor, describing which logic areas in the DUT are affected by specific testcases; 
       FIG. 4  depicts an addition of a new logic area to the DUT; 
       FIGS. 5   a-b  illustrate which test cases fail after altering a logic area; 
       FIG. 6  is a flow-chart of steps taken in practice of a preferred embodiment of the present invention; and 
       FIG. 7  depicts a preferred data processing system used to control and manage the present invention. 
   

   DETAILED DESCRIPTION 
   With reference now to the figures and in particular to  FIG. 1 , there is depicted a block diagram of a Device Under Test (DUT)  100 . DUT  100  is a software model, built with a Hardware Descriptor Language (HDL) synthesis tool, having multiple logic areas  1 - 8 , also known as “logic states.” As illustrated, logic areas  1  and  2  have an overlap  102 , which is a logical overlap of function or interrelationship, and/or a physical overlap according to the ultimate physical proximity between two logic areas on a physical chip being modeled by a Hardware Descriptor Language (HDL). If overlap  102  is a logical overlap, then a process performed in logic area  1  directly affects logic are  2 , such as providing a branch node, calculation result, decision step, etc. While logic areas  3 - 6  are not directly affected by logic area  1 , logic areas  3 - 6  are indirectly affected by logic area  1  since logic areas  3 - 6  are directly affected by logic area  2 . 
   Logic area  7  is not affected, either directly or indirectly, by logic area  1 , even though logic area  7  does perform some type of logical function that may impact on other logic areas (not shown) in DUT  100 . Logic area  8 , which is part of a pass-through logic  104 , is also not affected by logic area  1 , since pass-through logic  104 , which may be a scan chain or other type of pass-through logic, does not directly interact with any of the other logic areas in DUT  100 . 
   With reference now to  FIG. 2 , there is depicted a block diagram of software used by the present invention. A test list  202  includes an entire regression list of tests for a device under test (DUT)  208 , which comprises multiple logic areas. A simulator  204 , interfaces between DUT  208  and a test bench  206 , which contains a test, from test list  202 , that is currently being executed. Simulator  204  simulates events that incorporate features of the currently executing test. These events are updated during the test execution by simulator  204  with test bench  206 . These simulated events are exchanged back and forth with DUT  208  to further update the simulation. Test bench  206  preferably directly monitors logic areas. That is, in a physical logic area, a physical probe would directly monitor whether the physical logic area was being “hit” by a software operation. In a software model such as DUT  100 , the virtual logic areas are monitored by test bench  206 , which includes software to monitor is a virtual logic area has been “hit.” This monitoring is preferably performed by monitoring flags, condition states, or other registers/memory that indicate that a particular logic area is receiving data input and, usually, outputting data processing results. 
   Simulator  204  also includes a compiler  214 , which is used prior to execution of testing to define logic areas in DUT  208 . These logic areas are used to construct a testcase scoreboard  212 , about which more is described below. 
   A monitor  210  correlates logic state areas in DUT  208  with specific testcases from test list  202 . This correlation is used to both create as well as fill in a testcase scoreboard  212 . That is, on a first pass, monitor  210  begins the creation of an empty matrix scoreboard  212  as shown in  FIG. 3   a , in which logic areas are defined according to an analysis of the compiled HDL defining DUT  208 . On a second pass, monitor  210  completes testcase scoreboard  212 , as shown in greater detail in  FIG. 3   b , by checking off each logic area that is affected by each newly added testcase. As shown in exemplary  FIG. 3   b , Testcase A affects logic areas  1 ,  3  and  5 , while Testcase B affects only logic areas  3  and  4 . The “X” notations in  FIG. 3   b  represent a correlation performed by monitor  210 , which monitors nodes in DUT  208  for activity caused by a specified testcase. 
   After scoreboard  212  has been completed as shown in  FIG. 3   b , it can be used to locate likely problem logic areas in the future. For example, suppose a new logic area  402  is added, as shown in  FIG. 4  within logic area  2 . Since the scoreboard shown in  FIG. 3   b  indicates that only Testcases D and E test logic area  2 , then only these two testcases are run. If Testcases D and E fail, as shown, then there are two most probable reasons. The first is that new logic area  402  has had a direct adverse effect on logic area  2 . The second is that new logic area  402  has had an indirect adverse effect on logic area  1  or logic area  5 , since these two logic areas are also affected by Testcases D and E. Through the use of the scoreboard shown in  FIG. 5   a , a logical decision can be made as to determine how to pinpoint where the logic fault lies. 
   A first method to pinpoint the location of the fault is to count how many logic areas are involved in the failed testcases. For example, the two failed Testcases D and E shown in  FIG. 5   a  used logic area  2  twice, but logic areas  1  and  5  only once. Thus, it can be predicted that logic areas  1  and  5  are less likely to be the problem area than logic area  2 . While such a conclusion is fairly obvious in the example shown, in which logic are  2  is the area that was altered, this “counting” technique becomes much more powerful when there are many more testcases and logic areas. In such cases, the logic area having the highest occurrence in failed testcases is often a logic area that was NOT altered. In the example shown then, even if logic area  2  had not been altered, the appearance of logic area  2  in both failed Testcases D and E indicates that logic area  2  is likely the area posing the problem. 
   Alternatively, testcase scoreboard  212  can be used to select which testcases are run after Testcases D and E fail, in order to more accurately pinpoint where the problem logic area is located. Using the illustration of  FIG. 5   a , when Testcases D and E fail, a search is made for other testcases using logic areas that are tested by Testcases D and E. No other testcases test logic area  2 , but Testcase A also tests logic areas  1  and  5 . Thus, Testcase A is subsequently run, and fails, as shown in  FIG. 5   b . Since Testcase A does not use logic area  2 , then there is a strong presumption that logic area  2  is not the problem after all. However, since Testcase A uses logic areas  1  and  5 , Testcase D uses logic area  1 , and Testcase E uses logic area  5 , then there is a strong likelihood that new logic area  402  has had an adverse indirect impact on logic areas  1  and  5 . 
   With reference now to  FIG. 6 , a preferred embodiment of the present invention is described in a flow-chart. Starting at block  602 , an initial scoreboard is created by identifying logic areas in the DUT. A full regression of all tests is run on the DUT (block  604 ), which results in the completion of the scoreboard (block  606 ) identifying each logic block affected by each testcase. 
   If a new testcase is added (block  610 ), it is run. If it passes (decision block  614 ), then no further action is taken. However, if the new testcase fails, then other testcases that failed are examined and compared (block  622 ), to identify testcases having common logic areas. The presence of such common areas is a good indicator of which logic area(s) have a problem. 
   If a new logic area is added or an existing logic area is altered (block  608 ), then the testcases that use that area of logic are run (block  612 ). If the selected testcases pass (decision block  616 ), then no further steps are taken. However, if there are one or more failures in the chosen testcases, then the common affected logic areas are counted (block  618 ), and a minimum regression is run using testcases that test the affected logic areas, either directly or indirectly (block  620 ), as described above in  FIG. 5   b.    
   With reference now to  FIG. 7 , there is depicted a block diagram of a preferred embodiment of a data processing system  700  used to implement the present invention in the creation and logical use of the scoreboard. Data processing system  700  is preferably used to run all software described in FIG.  2 . 
   Data processing system  700  includes a processor  702 , which is connected to a system bus  708 . In the exemplary embodiment, data processing system  700  includes a graphics adapter  704  also connected to system bus  708 , receiving information for display  706 . 
   Also connected to system bus  708  are system memory  710  and input/output (I/O) bus bridge  712 . I/O bus bridge  712  couples I/O bus  714  to system bus  708 , relaying and/or transforming data transactions from one bus to the other. Peripheral devices such as nonvolatile storage  716 , which may be a hard disk drive, floppy drive, a compact disk read-only memory (CD-ROM), a digital video disk (DVD) drive, or the like, and input device  718 , which may include a conventional mouse, a trackball, or the like, is connected to I/O bus  714 . The software described in  FIG. 2  is preferably stored in both system memory  710  and nonvolatile storage  716 . 
   The exemplary embodiment shown in  FIG. 7  is provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. For instance, data processing system  700  might also include a sound card and audio speakers, and numerous other optional components. All such variations are believed to be within the spirit and scope of the present invention. 
   It should be understood that at least some aspects of the present invention may alternatively be implemented in a program product, preferably performing the functions of the present invention in an automatic manner based on pre-determined criteria as described, including relative logical relationships between and among logic areas. 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.