Abstract:
An improved method of verifying a processor design using a processor simulation model in a simulation environment is disclosed, wherein the processor simulation model includes at least one execution unit for executing at least one instruction of a test file. The method includes tracking each execution of each of the at least one instruction, monitoring relevant signals in each simulation cycle, maintaining information about the execution of the at least one instruction, wherein the maintained information includes a determination of an execution length of a completely executed instruction, matching the maintained information about the completely executed instruction against a set of trap elements provided by the user through a trap file, and collecting the maintained information about the completely executed instruction in a monitor file in response to a match found between the maintained information and at least one of the trap elements.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation application of, and claims priority under 35 U.S.C. §120 to, U.S. patent application Ser. No. 12/182,211, filed Jul. 30, 2008 and issued on Aug. 21, 2012 as U.S. Pat. No. 8,249,848, which claims priority under 35 U.S.C. §119 to European Patent Application No. 07115720.0, filed Sep. 5, 2007, the contents of which are incorporated herein by reference. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates generally to verification tools for processor designs and particularly to a method and a system for verifying a processor design using a processor simulation model in a simulation environment, wherein the processor simulation model comprises at least one execution unit for executing at least one instruction of a test file. More particularly, the present invention relates to a data processing program and a computer program product for verifying a processor design. 
     BACKGROUND 
     During the design stage of processors, verification is necessary to ensure that all possible combinations of instructions and execution lengths are implemented properly and are tested by the simulation environments. The verification of the processor design relies on logic design to provide a list of all existing combinations and adds coverage events for these combinations to simulation environments and also ensures that all events are covered. However, this method requires substantial manual and error-prone work, the provided list may be incomplete or incorrect, and logic changes require the addition and/or removal of coverage events. 
     State-of-the-art hardware implementations of execution units, such as fixed point units (FXUs) and floating point units (FPUs), support a high number of instructions/operations. For example, a modern floating point unit (FPU) implements several hundred instructions. Each instruction can have different execution lengths, measured in cycles. For the most part, the number of cycles necessary to execute an instruction depends upon the specific input operands. Implementations may detect so-called early-out cases that do not require the execution of the complete computational algorithm. For example, multiply-by-zero and divide-by-one operations both result in well-defined values. Furthermore, hardware settings such as the setting of switches that enable or disable certain functionality and the specific circumstances of executing an instruction, such as forwarding results from previous instructions, can influence the execution length of an instruction as well. Furthermore, performance improvements of existing instruction implementations require an efficient method to track changes and their effects. 
     The increasingly high number of instructions supported by current execution unit implementations and their various execution lengths makes it very difficult to ensure that all possible combinations of instructions and execution lengths are implemented properly, function as intended, and are fully covered in the simulation environments. 
     SUMMARY OF THE INVENTION 
     The technical problem underlying the invention involves providing a method and a system for verifying a processor design using a processor simulation model in a simulation environment and to provide a data processing program and a computer program product to perform said method. Moreover, the technical problem involves providing an automated way to monitor execution cycles of instructions that are simulated in a simulation model and to collect information about the existing execution lengths. 
     The invention solves this problem by providing a method of verifying a processor design having the features of claim  1 , a system of verifying a processor design having the features of claim  9 , a non-transitory computer-usable medium having the features of claim  16 . Advantageous embodiments of the invention are mentioned in the corresponding dependent claims. 
     Accordingly, in an exemplary embodiment of the present invention, a method for verifying a processor design using a processor simulation model in a simulation environment tracks each execution of each of at least one instruction of a test file, monitors relevant signals in each execution cycle, and maintains information about the execution of the at least one instruction, wherein the maintained information comprises a determination of an execution length of a completely executed instruction. The processor simulation model comprises at least one execution unit for executing the at least one instruction. The method for verifying matches the maintained information about the completely executed instruction against a set of trap elements provided by the user through a trap file and collects the maintained information about the completely executed instruction in a monitor file in response to a match found between said maintained information and at least one of said trap elements. 
     The trap functionality of the monitor permits a user to obtain a collection of interesting test cases for coverage purposes. For instance, the trap functionality permits a user to easily cover specific cases in a static regression and to use these test cases when verifying existing implementations and when implementing and testing changes, such as performance enhancements. 
     In another exemplary embodiment of the present invention, the method for verifying a processor design collects the maintained information about the completely executed instruction in a statistic file. That is to say, information of each complete execution of an instruction is added to this statistic file. 
     The monitor file and statistics file enable the user to maintain a table of the collected execution cases of instructions, which can be used by driver and checker code in the simulation environments to ensure that all known cases are actually being covered by the simulation environments, i.e., are generated by the test generators and supported by the drivers; to compare and verify design data and statistics, and to investigate discrepancies; to investigate and track the effects of performance enhancements of instructions; to implement and track further performance enhancements; and to better predict the performance of the execution unit and the overall processor design. 
     In another exemplary embodiment of the present invention, tracking each execution of each of the at least one instruction comprises creating a monitor queue with a queue element for each instruction currently being executed, wherein each queue element contains an instruction identifier, which identifies the type of the corresponding instruction, and also contains an execution cycle counter, which holds a counter value indicating the number of execution cycles that the corresponding instruction has executed up to the current point in time. In each simulation cycle, the queue elements and the monitor queue are modified in response to the states of the relevant signals that are monitored and that comprise at least one of an instruction issue valid signal, an instruction stall signal, an instruction kill/flush signal, and an end of instruction signal. 
     In another exemplary embodiment of the present invention, the counter values of the execution cycle counters of the queue elements are increased in response to each execution cycle during the execution of the corresponding instructions. 
     In another exemplary embodiment of the present invention, the method for verifying a processor design further comprises creating a new queue element in response to the instruction issue valid signal being active and representing information about a starting point of the execution of the at least one instruction; holding current counter values of the execution cycle counters of the queue elements in response to the instruction stall signal being active; removing corresponding queue elements from the monitor queue in response to the instruction kill/flush signal being active; and removing the oldest queue element from the monitor queue, whereas this queue element comprises an instruction identifier and a number of execution cycles representing the execution length of the corresponding completed instruction, and matches the maintained information of the oldest queue element against the set of trap elements in response to the end of instruction signal being active and representing information about an ending point of the execution of the at least one instruction. 
     In another exemplary embodiment of the present invention, the step of collecting the information about a completely executed instruction in the monitor file comprises creating a monitor case that includes the oldest queue element and the current test case of the test file (the current test case consisting of the instruction identifier of the completely executed instruction and corresponding input data), and sending the monitor case to the monitor file. 
     In another exemplary embodiment of the present invention, the step of collecting the information about a completely executed instruction in the statistic file comprises creating a statistic case that includes the oldest queue element and sending the statistic case to the statistic file, wherein the occurrence of the received statistic case type is counted and the number of occurrences is added to the statistic case. 
     In another exemplary embodiment of the present invention, each trap element comprises at least one of an instruction identifier and a placeholder, and also a regular expression which is either empty or comprises at least one of a relational operator, a number of execution cycles, and a logical operator. 
     In another exemplary embodiment of the present invention, a system for verifying a processor design using a processor simulation model in a simulation environment comprises a monitor unit including a control unit and using an interface to communicate with the processor simulation model. The processor simulation model comprises at least one execution unit for executing at least one instruction of a test file. The monitor unit is configured to track each execution of each of the at least one instruction; to monitor relevant signals in each simulation cycle; to maintain information about the execution of the at least one instruction, wherein said maintained information comprises a determination of an execution length of a completely executed instruction; to match the maintained information about the completely executed instruction against a set of trap elements provided by the user through a trap file; and to collect the maintained information about the completely executed instruction in a monitor file in response to a match found between the maintained information and at least one of the trap elements. 
     In another exemplary embodiment of the present invention, the monitor unit is further configured to collect the maintained information about a completely executed instruction in a statistic file. Additionally, the monitor unit is further configured to create a monitor queue with a queue element for each instruction currently being executed by the at least one execution unit. 
     In another exemplary embodiment of the present invention, each queue element of the monitor queue is configured to comprise an instruction identifier, which identifies the type of instruction, and an execution cycle counter, which holds a counter value indicating the number of execution cycles that the corresponding instruction has executed up to the current point in time. The monitor unit is further configured to modify the queue elements and the monitor queue in each simulation cycle in response to the relevant signals that comprise at least one of an instruction issue valid signal, an instruction stall signal, an instruction kill/flush signal, and an end of instruction signal. 
     In another exemplary embodiment of the present invention, the execution cycle counters are configured to increase their counter values in response to each execution cycle during the execution of the corresponding instructions. 
     In another exemplary embodiment of the present invention, the monitor unit is further configured to create a new queue element in response to the instruction issue valid signal being active; to hold current counter values of said execution cycle counters in response to said instruction stall signal being active; to remove corresponding queue elements from the monitor queue in response to the instruction kill/flush signal being active; to remove the oldest queue element from the monitor queue, whereas the queue element comprises an instruction identifier and a number of execution cycles representing the execution length of the corresponding instruction; and to match the information of the oldest queue element against the set of trap elements using a comparator in response to the end of instruction signal being active. 
     In another exemplary embodiment of the present invention, the monitor unit is further configured to create a monitor case comprising the oldest queue element and the current test case of the test file and to send the monitor case to the monitor file. Additionally, the monitor unit is further configured to create a statistic case comprising the oldest queue element and to send the statistic case to a statistic file. 
     In another exemplary embodiment of the present invention, a data processing program for execution in a data processing system comprises software code portions for performing the method for verifying a processor design when said program is run on said data processing system. 
     In another exemplary embodiment of the present invention, a computer program product stored on a computer-usable medium causes a computer to perform the method for verifying a processor design when said program is run on said computer. 
     The disclosed embodiments of the invention provide an automated way to monitor execution cycles of instructions that are executed in a processor simulation model, to collect test cases that contain certain instructions with certain execution lengths, and to collect statistical data about all existing execution lengths of instructions executed during the simulation. 
     In sum, embodiments of the invention disclosed herein provide a manageable, automated way to efficiently handle the complexity caused by the increasingly large number of instructions implemented in execution units and their various execution lengths. 
     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 
       An exemplary embodiment of the invention, as described in detail below, is shown in the drawings. 
         FIG. 1  is a schematic block diagram of a simulation environment with a processor simulation model and a monitor unit, in accordance with an exemplary embodiment of the present invention. 
         FIG. 2  is a block diagram of a simulation environment and a monitor unit, in accordance with an exemplary embodiment of the present invention. 
         FIG. 3  is a block diagram of a test file, in accordance with an exemplary embodiment of the present invention. 
         FIG. 4  is a block diagram of a monitor queue, in accordance with an exemplary embodiment of the present invention. 
         FIG. 5  is a block diagram of a trap file, in accordance with an exemplary embodiment of the present invention. 
         FIG. 6  is a block diagram of a regular expression, in accordance with an exemplary embodiment of the present invention. 
         FIG. 7  is a block diagram of a monitor file, in accordance with an exemplary embodiment of the present invention. 
         FIG. 8  is a block diagram of a statistic file, in accordance with an exemplary embodiment of the present invention. 
         FIGS. 9 to 11  each contain a portion of a flow chart of a method for verifying a processor design, in accordance with an exemplary embodiment of the present invention. 
         FIG. 12  is a timing diagram of signals produced during a simulation run of a simulation environment, in accordance with an exemplary embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows a schematic block diagram of a simulation environment  60  with a processor simulation model  10  and a monitor unit  20 , in accordance with an exemplary embodiment of the present invention. 
     Referring to  FIG. 1 , the shown embodiment of the invention employs a monitor to track instructions executed in a simulation model of a processor or in a simulation model of a part of a processor containing at least one execution unit.  FIG. 1  illustrates a scenario where a monitor unit  20  tracks instructions which are given from a test file  50 , interpreted by an instruction unit  12  using a load store unit  14 , and executed in a fixed point unit  16  or in a floating point unit  18  contained in the larger processor simulation model  10 . To track instructions, the monitor unit comprises a control unit  25  and uses an interface  62  provided by the simulation environment  60  as shown in  FIG. 2  to monitor relevant signals of the processor simulation model  10 . 
       FIG. 2  is a block diagram of the simulation environment  60  and a more detailed block diagram of the monitor unit  20 , in accordance with an exemplary embodiment of the present invention. 
     The monitor unit  20  is designed and implemented according to the interface specifications of the relevant execution units  16 ,  18 . It hooks into the simulation environment  60 , attaches itself to specific signals in the processor simulation model  10 , and monitors these signals in order to track instructions in the relevant execution units  16 ,  18 . The signals that are monitored are chosen in a way that each possible execution of an instruction can be tracked. The relevant signals comprise at least one of an instruction issue valid signal, an instruction stall signal, an instruction kill/flush signal, and an end of instruction signal. The instruction issue valid signal signals the corresponding execution unit  16 ,  18  to start executing the given instruction and comes either from another unit in the processor simulation model  10  or from a driver in the simulation environment  60 . The instruction issue valid signal usually contains information about the instruction, such as a unique operation code (“op code”). The instruction stall signal usually signals the corresponding execution unit  16 ,  18  that data from memory referenced by the instruction is not readily available and stalls the execution for a certain number of cycles. The instruction kill/flush signal signals the corresponding execution unit  16 ,  18  that the instruction or a group of instructions must not complete and aborts the execution of the instruction(s). The end of instruction signal signals that the corresponding execution unit  16 ,  18  has finished executing the instruction. 
     In a pipelined execution unit, multiple instructions may be executed at the same point in time. The monitor unit  20  has to correlate the interface signals with the proper instruction in order to interpret them correctly. 
     During a simulation run, the monitor unit  20  tracks each instruction execution and maintains information about the execution length of each instruction, measured in execution cycles. Each completely executed instruction is matched against a set of filters, “trap elements,” provided by the user through a “trap file”  40 . The trap elements represent certain user-defined test cases. If the information of a completely executed instruction matches at least one of these trap elements, the current test case is collected, i.e., “trapped”. For example, the monitor unit  20  can cause the simulation environment  60  to read out information about the currently executing test case of the test file  50 . The test file  50  is shown in detail in  FIG. 3  and contains at least one test case  52 ,  52 ′. Each test case  52 ,  52 ′ comprises an instruction identifier  54 ,  54 ′, which identifies the type of instruction, and input data  56 ,  56 ′. The test file  50  can use either the operation code of the corresponding instruction or the mnemonic, which can be converted from the operation code using a lookup table. 
     The monitor unit  20  collects the corresponding test case information together with the information about the completely executed instruction into a monitor file  30  and/or sends this information to a monitor database  92 , thus allowing further processing and exploitation of the collected information. 
     Furthermore, the monitor unit  20  stores statistical data about the completely executed instructions, i.e., how often which instruction took a certain number of cycles to execute, into a statistic file  80  and/or sends this information to a statistic database  90 . This allows the user to further process this data and to select cases for trapping. The collected monitor cases and statistics enable the user to maintain a table of the collected execution cases of instructions, which can be used by driver and checker code in the simulation environments  60  to ensure that all known test cases are actually being covered by the simulation environments  60  (i.e., to ensure that all known test cases are generated by the test generators and supported by the drivers); to compare and verify design data and statistics, to investigate discrepancies, and to investigate and track the effects of performance enhancements of instructions; to implement and track further performance enhancements; and to better predict performance of the execution units  16 ,  18  and the overall processor design. 
     The monitor unit  20  is further configured to create a monitor queue  70  with a queue element  72 ,  72 ′ for each instruction currently being executed by the corresponding execution unit  16 ,  18 . The monitor queue  70  is shown in detail in  FIG. 4  and contains at least one queue element  72 ,  72 ′. Each queue element  72 ,  72 ′ comprises an instruction identifier  54 ,  54 ′, which identifies the type of instruction, and an execution cycle counter  74 ,  74 ′, which holds a counter value indicating the number of execution cycles that the corresponding instruction has executed up to the current point in time. The execution cycle counters  74 ,  74 ′ are configured to increase their counter values in response to each execution cycle during the execution of the corresponding instructions. The monitor queue  70  can use either the operation code of the corresponding instruction or the mnemonic, which can be converted from the operation code using a lookup table. 
     The monitor unit  20  is further configured to modify the queue elements  72 ,  72 ′ and said monitor queue  70  in each simulation cycle in response to the relevant signals, which comprise at least one of the instruction issue valid signal, the instruction stall signal, the instruction kill/flush signal, and the end of instruction signal. The monitor unit  20  is configured to create a new queue element in response to the instruction issue valid signal being active; to hold current counter values of the execution cycle counters  74 ,  74 ′ in response to the instruction stall signal being active; to remove corresponding queue elements  72 ,  72 ′ from the monitor queue  70  in response to the instruction kill/flush signal being active; and to remove the oldest queue element  72  (which comprises an instruction identifier  54  and a number of execution cycles representing the execution length of the corresponding instruction) from the monitor queue  70  and to match the information of the oldest queue element  72  against the set of trap elements  41 ,  41 ′ using a comparator  26  in response to the end of instruction signal being active. 
     The trap file  40  is shown in detail in  FIGS. 5 and 6 . It contains at least one trap element  41 ,  41 ′, whereas each trap element  41 ,  41 ′ comprises either an instruction identifier  42  or a placeholder  42 ′, and also a regular expression  43 ,  43 ′. 
     The cases in which the monitor unit should trap the current test case  52 ,  52 ′ are specified as a list of trap elements  41 ,  41 ′. When an instruction is completely executed in the processor simulation model  10 , the monitor unit  20  compares its information about the instruction and the determined execution length of the instruction with all trap elements  41 ,  41 ′ using the comparator  26 . If at least one trap element  41 ,  41 ′ matches, the current test case  52 ,  52 ′ is trapped. As referred to above, each trap element  41 ,  41 ′ consists either of an information about the instruction identifier  42  (which is a numerical operation code or an alphanumeric mnemonic) or a placeholder  42 ′, and also a regular expression  43 ,  43 ′. The regular expression  43 ,  43 ′ is either empty (don&#39;t care) or contains at least one relational operator  44 ,  44 ′ (e.g., equal, not equal, less than, greater than, equal or less than, equal or greater than, etc.) and a corresponding number of execution cycles  47 ,  47 ′. Logical operators  45 ,  45 ′ combine the relational operators  44 ,  44 ′ and the corresponding numbers of execution cycles  47 ,  47 ′. That is to say, the first logical operator  45  combines the first relational operator  44  and the first number of execution cycles  47  with the second relational operator  44 ′ and the second number of execution cycles  47 ′, and so forth. 
     The trap file  40  is not necessarily an actual file in a file system; it can also be represented in other kinds of data structures (e.g., a database). There can be multiple trap elements  41 ,  41 ′ for any instruction identifier  42  and for any placeholder  42 ′. 
     Table 1 shows some exemplary trap elements  41 ,  41 ′. The first trap element matches for every execution of an instruction ADD with an execution length of 10 cycles. Likewise, the second trap element matches for every execution of an instruction SUB with less than 20 cycles. The third trap element matches for every execution of the instruction DIV. The fourth trap element matches for any instruction with an execution length of at least 35 cycles. The fifth trap element matches for an instruction MADD with an execution length between 45 and 55 cycles. The sixth trap element matches for an instruction SQRT with more than 60 or less than 10 cycles. 
     
       
         
               
               
               
             
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Instruction 
                 Regular 
               
               
                   
                 identifier 
                 expression 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 ADD 
                 =10 
               
               
                   
                 SUB 
                 &lt;20 
               
               
                   
                 DIV 
               
               
                   
                 * 
                 &gt;=35 
               
               
                   
                 MADD 
                 &gt;=45 AND &lt;=55 
               
               
                   
                 SQRT 
                 &gt;60 OR &lt;10 
               
               
                   
                   
               
             
          
         
       
     
     Below is a set of rules that defines the structure of the regular expressions used in the examples above. The left side of the set contains placeholders which are used for the items on the right side of the set. The symbol | designates alternatives. Space+ signifies one or more occurrences of symbol Space. Number+ signifies one or more occurrences of symbol Number. 
     RegularExpression:=FilterCondition 
     FilterCondition:=RelationalOperator NumberCycles | FilterCondition Space+ LogicalOperator Space+ FilterCondition 
     RelationalOperator:==|&lt; &gt;|&lt;|&gt;|&lt;=|&gt;= 
     NumberCycles:=Number+ 
     Number:=0 |1 |2 |3 |4 |5 |6 |7 |8 |9 
     LogicalOperator:=AND|OR 
     Space:=′ ′ 
     The monitor file  30  is shown in detail in  FIG. 7  and contains monitor cases  32 ,  32 ′ created by the monitor unit  20 . Each monitor case  32 ,  32 ′ consists of the oldest queue element  76 ,  76 ′ that was removed from the monitor queue  70  in response to the end of instruction signal and the corresponding current test case  52 ,  52 ′ of the test file  50 . Each oldest queue element  76 ,  76 ′ comprises an instruction identifier  54 ,  54 ′ and a corresponding number of execution cycles  78 ,  78 ′. 
     The statistic file  80  is shown in detail in  FIG. 8  and contains statistic cases  82 ,  82 ′ created by the monitor unit  20 . Each statistic case  82 ,  82 ′ consists of the oldest queue element  76 ,  76 ′ that was removed from the monitor queue  70  in response to the end of instruction signal and a number of occurrences  84 ,  84 ′ of the corresponding oldest queue element  76 ,  76 ′. Each oldest queue element  76 ,  76 ′ comprises an instruction identifier  54 ,  54 ′ and a corresponding number of execution cycles  78 ,  78 ′. The statistic cases  82 ,  82 ′ contained in the statistic file  80  can be sent to the statistic database  90 . 
     With reference to  FIGS. 9 to 11 , which show a high-level flowchart, and to  FIG. 12 , which shows a timing diagram of signals produced during a simulation run of a simulation environment  60 , an exemplary method for verifying a processor design according to embodiments of the present invention is explained. 
     For the following example, it is assumed that the monitor unit  20  monitors the instruction issue valid signal, which signals the corresponding execution unit  18  that it must begin executing the instruction identified by an operation code (op-code); the instruction stall signal, which signals the corresponding execution unit  18  to stop executing the instruction that is in a certain pipeline stage of the execution unit  18 ; the instruction kill/flush signal, which signals the corresponding execution unit  18  to kill all instructions that are currently being executed; and the end of instruction signal, which signals the instruction unit  12  that the corresponding execution unit  18  has finished executing an instruction. 
     It is further assumed that the monitor unit  20  is given the trap file  40  shown in Table 2. 
     
       
         
               
               
               
             
               
               
               
             
           
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 Instruction 
                 Regular 
               
               
                   
                 mnemonic 
                 expression 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 ADD 
                 =4 
               
               
                   
                 SUB 
                 &lt;3 
               
               
                   
                 * 
                 &gt;=10 
               
               
                   
                   
               
             
          
         
       
     
     The first trap element matches for an instruction ADD with four execution cycles. The second trap element matches for an instruction SUB with less than three execution cycles. The third trap element matches for any instruction with at least ten execution cycles. Specifically, the first trap element represents a certain test case with an instruction ADD with four execution cycles that the monitor unit  20  must collect in the monitor file  30 . The second trap element represents a first test case with an instruction SUB with one execution cycle and a second test case with an instruction SUB with two execution cycles that the monitor unit  20  must collect in the monitor file  30 . The third trap element represents an infinite number of test cases that consist of instructions with at least ten execution cycles. 
     As indicated in  FIG. 12 , in a first simulation cycle  1 , the monitor unit  20  initializes and reads the trap file  40 . There are no instructions in the corresponding execution unit  18  and no queue elements in the monitor queue  70 . Specifically, as illustrated in  FIG. 9 , the next cycle, which in this case is the first simulation cycle  1 , is identified in step S 100 . In the context of the method steps illustrated in  FIGS. 9 to 11 , there is no relevant interface activity in the first simulation cycle  1 , since all relevant signals are on a low logic level. Thus, in the first simulation cycle  1 , the condition of step S 110  is true, and the conditions of steps S 120 , S 130 , S 140 , and S 200  are all false. 
     In a second simulation cycle  2 , a first instruction ADD with a first operation code 0xA is issued to the execution unit  18 . The monitor unit  20  adds a first queue element to the monitor queue  70  during steps S 120  to S 126 , since the condition of step S 120  is true because the instruction issue valid signal is on a high logic level. More specifically, the monitor unit  20  gets an op-code  123  in step S 122  and creates the first queue element comprising the op-code and a first execution cycle counter with an initial counter value of zero in step S 124 . After the second simulation cycle  2 , the first instruction ADD is in the execution unit  18  and the first queue element with the first op-code 0xA and a first counter value of 0 is held in the monitor queue  70 . 
     In a third simulation cycle  3 , there is no relevant interface activity since all relevant signals are on a low logic level. The monitor unit  20  increments the first execution cycle counter of the first queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. More specifically, since the condition of step S 110  is not true, the monitor unit  20  gets the first queue element in step S 112  and increments the execution cycle counter of the first queue element in step S 116 . After the third simulation cycle, the first instruction ADD is still in the execution unit  18  and the first queue element in the monitor queue  70  is modified, and thus the first queue element comprises the first op-code 0xA and a new first counter value of 1. 
     In a fourth simulation cycle  4 , all instructions in the execution unit  18  are flushed and the monitor unit  20  removes all queue elements according to the steps S 140  to S 146 , since the condition of step S 140  is true because the instruction kill/flush signal is on a high logic level. Specifically, the monitor unit  20  identifies the queue elements of the monitor queue  70  in step S 142  and removes these queue elements from the monitor queue  70  in step S 146 . Thus, in the fourth simulation cycle  4 , the first instruction ADD in the execution unit  18  is flushed, the monitor queue  70  is modified, and the first queue element is removed from the monitor queue  70 . 
     In a fifth simulation cycle  5 , a new first instruction ADD with a first op-code 0xA is issued to the execution unit  18 . The monitor unit  20  adds a new first queue element to the monitor queue  70  during steps S 120  to S 126 , since the condition of step S 120  is true because the instruction issue valid signal is on a high logic level. After the fifth simulation cycle  5 , the new first instruction ADD is in the execution unit  18 , and a new first queue element with a new first op-code 0xA and a new first counter value of 0 is in the monitor queue  70 . 
     In a sixth simulation cycle  6 , there is no relevant interface activity since all relevant signals are on a low logic level. The monitor unit  20  increments the first execution cycle counter of the first queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. After the sixth simulation cycle  6 , the first instruction ADD is still in the execution unit  18  and the first queue element in the monitor queue  70  is modified, and thus the first queue element comprises the first op-code 0xA and the new first counter value of 1. 
     In a seventh simulation cycle  7 , the first instruction ADD in the execution unit  18  is stalled, since the condition of step S 130  is true because the instruction stall signal is on a high logic level. The monitor unit  20  increments the first execution cycle counter of the first queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. Subsequently, the monitor unit  20  decrements the first execution cycle counter of the first queue element according to the steps S 130  to S 136 , so that the first queue element in the monitor queue  70  is not modified. Specifically, upon determining an instruction stall in step S 130 , the monitor unit  20  identifies the first queue element having the first op-code 0xA in step S 132 . Subsequently, the monitor unit  20  decrements by one the first execution cycle counter of the first queue element in step S 136 . The first queue element still comprises the first op-code 0xA and the former first counter value of 1. 
     In an eighth simulation cycle  8 , the instruction ADD in the execution unit  18  is stalled for one more execution cycle, since the condition of step S 130  is true because the instruction stall signal is still on a high logic level. Thus, the monitor unit  20  increments the first execution cycle counter of the first queue element according to the steps S 110  to S 118  and decrements the first execution cycle counter of the first queue element according to the steps S 130  to S 136 , so that the first queue element in the monitor queue  70  is still not modified. The first queue element still comprises the first op-code 0xA and the former first counter value of 1. 
     In a ninth simulation cycle  9 , there is no relevant interface activity since all relevant signals are on a low logic level. The monitor unit  20  increments the execution cycle counter of the first queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. After the ninth simulation cycle  9 , the first instruction ADD is still in the execution unit  18  and the first queue element in the monitor queue  70  is modified, and thus the first queue element comprises the first op-code 0xA and the new first counter value of 2. 
     In a tenth simulation cycle  10 , a second instruction SUB with a second op-code 0xF is issued to the execution unit  18 . The monitor unit  20  increments the first execution cycle counter of the first queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. Moreover, the monitor unit  20  adds a second queue element to the monitor queue  70  during step S 120  to S 126 , since the condition of step S 120  is true because the instruction issue valid signal is on a high logic level. After the tenth simulation cycle  10 , the first instruction ADD and the second instruction SUB are in the execution unit  18 . The first queue element in the monitor queue  70  is modified so that the first queue element comprises the first op-code 0xA and the new first counter value of 3. In addition, the second queue element with the second op-code 0xF and a second counter value of 0 is added to the monitor queue  70 . 
     In an eleventh simulation cycle  11 , the execution unit  18  completes the first instruction ADD. The monitor unit  20  increments the execution cycle counters of the first queue element and the second queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. Thus, the first execution cycle counter holds the new first counter value of 4 and the second execution cycle counter holds the new second counter value of 1. Since the condition of step S 200  is true because the end of instruction signal is on a high logic level, the monitor unit  20  removes the oldest queue element, i.e., the first queue element, from the monitor queue  70  in step S 210  and compares the first queue element with the trap elements of the trap file  50  in step S 212 . In step S 220 , the monitor unit  20  determines whether the first queue element matches with any trap element based on the comparison in step S 212 . Since the first queue element matches with the first trap element of Table 2, in step S 220  the monitor unit  20  determines that the matching result of step S 212  is true. As a result, the monitor unit  20  gets the current test case from the test file  50  in step S 222 , creates a first monitor case in step S 224 , and sends the first monitor case to the monitor file  30  in step S 226 . In step S 230 , the monitor unit  20  creates a first statistic case and sends the first statistic case to the statistic file  80  in step S 232 . Thus, after the eleventh simulation cycle  11 , the first instruction ADD is removed from the execution unit  18  and the second instruction SUB is still in the execution unit  18 . The second queue element in the monitor queue  70  is modified so that the second queue element comprises the second op-code 0xF and the new second counter value of 1. In sum, in the eleventh simulation cycle  11 , the first queue element with the first op-code 0xA and the new first counter value of 4 is removed from the monitor queue  70  and combined with the current test case from the test file  50  to create the first monitor case. 
     In a twelfth simulation cycle  12 , there is no relevant interface activity since all relevant signals are on a low logic level. The monitor unit  20  increments the second execution cycle counter of the second queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. After the twelfth simulation cycle  12 , the second instruction SUB is still in the execution unit  18 . The second queue element in the monitor queue  70  is modified so that the second queue element comprises the second op-code 0xF and the new second counter value of 2. 
     In a thirteenth simulation cycle  13 , the execution unit  18  completes the second instruction SUB. The monitor unit  20  increments the execution cycle counter of the second queue element according to the steps S 110  to S 118 , since the condition of step S 110  is not true. Accordingly, the second execution cycle counter holds the new second counter value of 3. Since the condition of step S 200  is true because the end of instruction signal is on a high logic level, the monitor unit  20  removes the oldest queue element, i.e., the second queue element, from the monitor queue  70  in step S 210  and compares the second queue element with the trap elements of the trap file  50  in step S 212 . Since the second queue element does not match with the trap elements of Table 2, the matching result of step S 212  is not true. As a result, the monitor unit  20  creates only a second statistic case in step S 230  and no second monitor case and sends the second statistic case to the statistic file  80  in step S 232 . After the thirteenth cycle  13 , the second instruction SUB also is removed from the execution unit  18 . In sum, in the thirteenth simulation cycle  13 , the second queue element with the second op-code 0xF and the new second counter value 3 is removed from the monitor queue  70 . 
     In a fourteenth simulation cycle  14 , there is no relevant interface activity, and the test file  50  is stopped. The monitor unit sends the monitor file  80 , which contains the first monitor case, to the monitor database  92  and also sends the statistic file  80 , which contains the first and second statistic cases, to the statistic database. 
     In sum, the first monitor case was collected due to the first trap element matching for the execution of the first instruction ADD. Moreover, the simulation run produced the statistic cases shown in Table 3, which were sent to the statistic database  90  at the end of the simulation run. 
     
       
         
               
               
               
               
             
           
               
                   
                 TABLE 3 
               
               
                   
                   
               
               
                   
                 Instruction 
                 Number of 
                 Number of 
               
               
                   
                 identifier 
                 execution cycles 
                 occurrences 
               
               
                   
                   
               
             
             
               
                   
                 ADD 
                 4 
                 1 
               
               
                   
                 SUB 
                 3 
                 1 
               
               
                   
                   
               
             
          
         
       
     
     In the described exemplary embodiment of the invention, the monitor unit is active during every cycle of the simulation run. In the shown implementation, each encountered case is collected in the monitor file and/or in the statistic file and sent to a monitor database and/or a statistic database at the end of the simulation run. Other implementations not shown can send the encountered monitor cases and statistic cases directly to the corresponding database for updating and storage. 
     The invention can take the form of an embodiment with only hardware elements, an embodiment with only software elements, or an embodiment containing both hardware and software elements. In an exemplary embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
     Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any other instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
     The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Current examples of computer-readable media include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disc-read only memory (CD-ROM), compact disc-read/write (CD-R/W), and DVD. 
     A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. 
     Input/output (I/O) devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. 
     Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are examples of the currently available types of network adapters.