Abstract:
Code coverage questions are addressed by a code coverage method that instruments an electronic module source design file with coverage probes and gives hierarchical names to the probes, then provides therefrom an instrumented gate level netlist. The instrumented netlist is run on a hardware emulator, executing reset trigger scripts to reset the branch and statement probes, and then a fully initialized design is driven in emulation on a simulated testbench from which the probe values are retrieved. These values can then be evaluated to determine the extent of code coverage. Various forms of coverage are supported including branch, statement, reset trigger and toggle coverage.

Description:
CROSS-REFERENCE TO OTHER APPLICATIONS 
     The present application claims priority to Provisional Application Ser. No. 60/376,604 filed 30 Mar. 2002 which is incorporated herein by reference in its entirety. The present application contains subject matter related to U.S. application Ser. No. 10/324,608 now U.S. Pat. No. 7,117,458 and U.S. application Ser. No. 10/324,451 now U.S. Pat. No. 7,292,970, both of which were filed on 20 Dec. 2002 and are also incorporated herein by reference in their entireties. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates generally to hardware design for high density logic circuits and has particular application to code testing in design development. 
     2. Background 
     Code coverage is a computationally intense activity involved in hardware emulation used in the hardware design process. 
     Code coverage testing is a boon to designers because it clearly identifies portions of the design under test that have not been adequately exercised during testing. However, extraction of signals relevant to code coverage depending on the design itself to give up its hidden circuit pathways has not yielded good results. Accordingly, some way to insert circuits, i.e., instruments, to capture signals at any relevant location within the design needed to be developed. Counter to the need to insert instruments, or to instrument the design is the problems that additional circuits in the design can cause. The running of emulations with the greatly increased design size becomes an insurmountable problem when the design is large to begin with, so even though the signals could be read out from a fully instrumented design, the emulators typically were not large or fast enough to be of use for large circuit designs. 
     Code coverage has been available for simulation, but not emulators in the past. Users need to be able to have better and more reliable code coverage which can only be achieved in emulation where at speed and other potentially difficult conditions can be explored, unlike simulation which does not provide for any real world test conditions. 
     SUMMARY OF THE INVENTION 
     This invention addresses these problems by making available selective instrumentation to the user and by limiting the emulation runs to smaller netlists. Generally the user will select an appropriate sized netlist by picking a module of interest for the design source file that is likely to be within the range of capacity for the emulator he is going to be using. An HDL (VHDL, Verilog, etc.) source is instrumented with coverage probes; a hierarchical name is generated for each instantiated probe; the instrumented HDL source is compiled/synthesized into a gate-level netlist; the list of hierarchical names is used to generate two scripts: a reset trigger script, and a probe value extraction script; the instrumented netlist is loaded onto a hardware emulator. If the emulator capacity is exceeded a smaller module is selected and only that module is run. The emulation run is initialized, then the generated reset trigger script is executed to reset coverage probes. We call the probes we discuss herein branch, toggle, and statement probes. The fully initialized design is then driven by a software testbench; after the testbench has completed, the generated extraction script is run to retrieve the probe values from the emulator; the extracted probe values are saved in a valid input format for use by a code coverage tool; the code coverage tool produces reports detailing how much of the design has been exercised, using the various code coverage techniques. 
     Coverage can be thought of in parts; Branch coverage, which itself can be described in three parts: Standard, For-Loop and For-Generate; and the additional parts are Statement coverage; and Toggle Coverage. A reset trigger is also included in the description. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
       The present invention is described with reference to the accompanying drawings which are at the pages in the specification mentioned in the paragraphs that follow. This specification is called the “Tuscany/CoBALT Design v2.0” document of Apr. 26, 2002. Upon filing of a formal application these drawings will be filed in accord with the requirements for formal drawings. 
         FIG. 1  is a flow diagram; 
         FIG. 2  is a block diagram; 
         FIG. 3  is a block diagram; 
         FIG. 4  is a block diagram; 
         FIG. 5  is a block diagram; 
         FIG. 6  is a block diagram; 
         FIG. 7  is a block diagram; 
         FIGS. 8A and 8B  are block diagrams. 
         FIG. 9  is a flow chart illustrating steps for finding unexercised logic. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     While various embodiments of the present invention are described, it should be understood that they have been presented by way of example only, and not as a limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following Claims and their equivalents. 
     Functional Design 
     System Components 
     The present application contains subject matter common to U.S. application Ser. No. 10/324,608 now U.S. Pat. No. 7,117,458 entitled “Identifying Specific Netlists for use in Code Coverage Testing” and U.S. application Ser. No. 10/324,451 now U.S. Pat. No. 7,292,970 entitled “Finding Unexercised Logic for use in Code Coverage Testing”, both of which were filed on 20 Dec. 2002 and both of which are incorporated herein by reference in their entireties. 
     Refer first to  FIG. 1 , the flow schematic diagram  40 . In this figure, it can be seen that the production of the data file (illustrated here on a disk  58  being held by an appreciative human stick figure) begins with the production of the VHDLIVerilog source files  41 . In order to implement the inventions the source file is instrumented in step  42  to create an annotated source file  43  The instrumentation in the preferred embodiment is done using the VN-Cover tool from TransEDA, but other similar tools could be used. (VN stands for Verification Navigation). The annotated source files  43  are sent to a simulator  46   a  to give us all the names of the registers we will want to look at, based on the annotations that were made The simulator will produce a history template file  47  as a result. Preferably contemporaneously with the simulation, we run a compiler/synthesizer  44  to produce the annotated net list  45  from the VHDL Verilog files  43 , so that the CoBALT engine  49  has something to work with that it understands. The upper flow of processes and software is the Emulation Flow. Trigger Scripts  51  and Extraction scripts  52  interact with the annotated target in CoBALT to improve it to the point where a properly annotated Temp File  53  is created to form the basis for ultimate coverage analysis in block  57 . The extraction scripts  52  are created in a script generator  48  that produces a script based on the files input to it ( 47  and  53 ) The first file is the history template file  47 , created through the simulation  46   a  and  46   b . After this is used to create an extraction script and that is run on the target in CoBALT (i.e., performing the emulation), a temporary file  53  is created that holds the data on which circuits we want to look at. The script generator  48  merges the history template file  47  with coverage values from the temp file  53  to produce a history file  54   b  The annotated netlist  45  is simulated by the simulator  46   b  to produce history file  54   b  which identifies all tied coverage probes, i.e, probes that are tied to either “covered” or “uncovered” states due to constant signals, or tied to registers in the design. (The history file  54   a  produced by simulator  46   b  is actually a temp file in the format of temp file  53  in the current embodiment, but implementation details such as this may be varied by the user). The simulation done in simulator  46   a  should be run through all register values to produce a complete history file as would be expected by one in this art. These two history files are merged during VN-Cover analysis  57  as they are used as the basis for the code coverage analysis. The coverage results  58  have the tied coverage probes optionally either highlighted or filtered out, depending on how the user will want to use the data. 
     Below, we define some of these components individually. 
     VN-Cover Instrumentation ( 42 ) 
     Preferred embodiment instrumentation is performed by TransEDA&#39;s vnvhdl and vnvlog tools which instrument the VHDL and Verilog source, respectively, with the coverage probes. Software form other vendors with similar features could be used. 
     Compiler/Synthesizer ( 44 ) 
     For the preferred embodiment we use a Unisys developed RTL-to-gate translation process, based on either of the commercially available tools, Synopsis Design Compiler or Quickturn HDL-ICE. Annotated code must be synthesizable by some software tool, but the particular process by which the translation from the RTL or similar design files to gate design files is not essential to the invention. 
     Simulator ( 46   a ,  46   b ) 
     A software simulator  46   a , such as Leapfrog or NC-Sim, is used to load the instrumented design. The TransEDA PLI traverses the design, detecting instances of instrumented modules, and writes a history template file ( 47 ) which records the hierarchical name of instrumented instances and the coverage probes they contain. It also provides an estimate of the additional gates and latches added to the design by the instrumentation process. It is preferably used again  46   b  (or an alternative simulator may be used) to find the unexercised logic in the annotated net list as described in detail in related patent, identified above. 
     Script Generator ( 48 ) 
     The script generator is a piece of software that reads the history template file and generates two scripts: a reset script, and an extractor script. The reset script is a Tcl script executed after the emulation run initializes in order to reset all of the coverage registers. (Tcl or Tool Command Language) is a well known open-source script generator programming language. The extractor Tcl script executes after the emulation run finishes to extract the coverage register values. The script generator is also used in a separate phase to convert the temporary file  53  generated by the extractor script  52  into a history file  56  which is readable by VN-Cover  57 . One of ordinary skill in these arts can easily and without undue experimentation build such script generators. 
     VN-Cover Results Analysis ( 57 ) 
     The standard TransEDA VN-Cover analysis tools (and possibly other post-processing tools) analyze the generated history file and output coverage reports. 
     Probe Generation Method 
     The method for generating synthesizable probes is accomplished using a set of custom components that are instantiated where needed. The implementation of this component may be different for different emulators or simulators. Three types of probes are generated: branch probes, statement probes, and toggle probes. 
     Branch probes record the execution of statements in conditional blocks, e.g. in if-else statements, case statements and in VHDL conditional and selected assignment statements. Statement probes record the execution of concurrent statements selected via CoBALT-valid sensitivity lists. Toggle probes record the rising (zero-to-one) and falling (one-to-zero) transitions of signals. All types of probes require a delayed trigger mechanism, which resets the probes&#39; states to the “unencountered” value after the emulation run has been initialized. 
     Appendix A contains the component definitions for the VNemulator library. Appendix B follows an example design through the entire process flow, and documents each of the files generated during the coverage generation and analysis process. 
     The vnemulator Library 
     The vnemulator library is a set of custom VHDL components which are used to support code coverage collection on an emulator. Instances of these components are inserted into the design during instrumentation. 
     VNEMULATOR_TRIGGER Component 
     The VNEMULATOR_TRIGGER component is instantiated once per instrumented module. Having one per instrumented module duplicates some state but simplifies the instrumentation program since it does not need to add any ports or make any hierarchy. This component contains state that is used to provide control signals to the other instrumentation components in the instrumented module, such as a reset signal for slatches or enable_capture/enable_compare signals for the statement probe implementation. The following vhdl and circuit diagram show the implementation of the TRIGGER with just the reset logic, the implementation for signals used by the statement probe will be discussed below. 
     The module has an optimization to allow minimized involvement from the using in issuing the reset. It uses a “cobalt_unit_delay” which delays a given signal by one emulation unit of time in CoBALT, which is the amount of time to propagate a signal through a latch in CoBALT. To issue a reset pulse, the user runs a Tcl script that sets the reset latch in each trigger module in the design. When the design executes the latch will be immediately reset which causes the smallest possible pulse and removes the need for another script to reset the latch. On CoBALT, the latch will initially have a value of ‘0’. This code produces the block diagram circuit illustrated in  FIG. 1 . 
     entity VNEMULATOR_TRIGGER is
         port (
           reset : buffer bit :=‘0’   
           );       

     end; 
     architecture RTL of VNEMULATOR_TRIGGER is
         signal delay_reset :bit;   component COBALT_UNIT_DELAY
           port (   A: in bit;   Z: out bit   
           );   end component;   -- pragma synthesis off   for all : COBALT_UNIT_DELAY use entity work. COBALT_UNIT_DELAY(RTL);   -- pragma synthesis_on       

     begin
         UQ_DELAY : COBALT_UNIT_DELAY port map (A=&gt;reset, Z=&gt;delay_reset);   process (delay_reset)   begin
           if delay_reset′event and delay_reset=‘1’ then
               reset &lt;=‘0’;   
               end if;   
           end process;       

     end; 
     VNEMULATOR_SLATCH Component 
     An instance of this component is used to latch the value of a branch-cover probe. The VHDL for the latch is given below:
         entity VNEMULATOR_SLATCH is
           port (
               reset :in bit;   s :in bit;   q :out bit   
               );   
           end;   architecture RTL of VNEMULATOR_SLATCH is   begin
           state_p : process (reset, s)   begin
               if reset = ‘1’ then
                   q &lt;= ‘0’;   
                   elsif s′event and s = ‘1’ then
                   q &lt;=‘1’;   
                   end if,   
               end process;   
           end;       

     The functionality of the latch is such that a transition to ‘1’ on the IN port, s, causes a ‘1’ to be latched onto the OUT port, q, of the latch. The OUT port will remain at ‘1’ even when transitions back to ‘0’. The latch output can be reset to ‘0’ by setting the value of the IN port, reset, to ‘1’. Note that the latch is edge triggered, not level-triggered. 
     The diagram showing the synthesised component from this code is seen in  FIG. 2 . 
     VNEMULATOR Trigger Latches 
     Instances of the library components VNEMULATOR_RTOGGLE and VNEMULATOR_FTOGGLE are used to latch the value of, respectively, a rising toggle-cover probe and a falling toggle-cover probe for a scalar signal of the IEEE logic type, std_ulogic. 
     A separate pair of components, VNEMULATOR_RTOGGLE_BOOL and VNEMULATOR_FTOGGLE_BOOL are used to latch toggle cover probes for signals of the standard type BOOLEAN. 
     The components VNEMULATOR_RTOGGLE_BIT and VNEMULATOR_FTOGGLE_BIT are used to latch toggle cover probes for signals of the standard type BIT. 
     The source code for the VNEMULATOR_RTOGGLE is shown below:
         library ieee;   use ieee.std_logic — 1164.all,   entity VNEMULATOR_RTOGGLE is
           port (
               reset :in bit;   s :in std_logic;   q :out bit   
               );   
           end;   architecture RTL of VNEMULATOR_RTOGGLE is   begin
           state_p : process (reset, s)   begin
               if reset = ‘1’ then
                   q &lt;= ‘0’;   
                   elsif s′event and s = ‘1’ then
                   q &lt;= ‘1’;   
                   end if;   
               end process;   
           end;       

     The functionality of the latch is such that a transition to ‘1’ on the IN port, s, causes a ‘1’ to be latched onto OUT port, q, of the latch. The OUT port, q will then remain at ‘1’ even when s transitions back to ‘0’. The latch is therefore capable of recording the fact that a rising toggle (ie. rising edge) occurred on a signal attached to its port, s. 
     The latch output can be reset to ‘0’ by setting the value of the IN port, reset, to ‘1’. 
     The component, VNEMULATOR_RTOGGLE, works in a similar way but records a falling edge on its IN port, s. 
     The above two components can be used to provide toggle coverage for signals of subtype STD_LOGIC. 
     The remaining 4 components provide the same functionality for signals of type BOOLEAN and BIT. 
     VNEMULATOR_DECLARATIONS Package 
     The package contains the component declarations for the design units discussed above. In addition, it contains a resolved subtype of the standard type BIT called resolved_or_bit. In VHDL terms, the value of a signal declared with this subtype is evaluated as the OR of the signal&#39;s drivers. Signals of this subtype are used to implement branch coverage for branches enclosed in for-generate loops. 
     Using the Library Components; Branch Probe Implementation (Preferred Embodiment Instrumentation). 
     Many types of conditional control structures in VHDL and Verilog control the execution of sequential statements. Branch probes record which conditionalized statements get executed. Branch probe definition of the SLATCH entity and architecture, and its instantiation are shown below. 
     Standard Branch Probe 
     The following VHDL shows a process containing an if-statement. When the if-expression, en=‘1’, evaluates to true, the if-branch is taken, and the statement ‘q&lt;=d’ is executed. When the expression evaluates to false, a virtual else-branch is taken. In coverage terms, the virtual else-branch is referred to as a ‘missing-else’ branch.
         library ieee;   use ieee.std_logic — 1164.all;   entity BRANCH_EXAMPLE is
           port (
               d :in std_logic;   en :in std_logic;   q :out std_logic   
               );   
           end;   architecture RTL of BRANCH_EXAMPLE is   begin
           PROC — 1: process(en, d)   begin
               q &lt;= ‘0’;   if en = ‘1’ then
                   q &lt;= d;   
                   end if;   
               end process;   
           end;       

     Note that without the “q” do loop in the BRANCH_EXAMPLE, when this VHDL example is instrumented for branch, coverage, the following VHDL is produced.
         library ieee;   use ieee.std_logic — 1164.all;   library vnemulator;   entity BRANCH_EXAMPLE is
           port (
               d :in std_logic;   en :in std_logic;   q :out std_logic   
               ):   
           end;   -- synopsys translate_off   library vnvhdl; use vnvhdl.vnvhdl.all; -- For VN-Cover PLI   -- synopsys translate_on   library vnemulator; use vnemulator.vnemulator_declarations.all;   architecture RTL of BRANCH_EXAMPLE is
           signal t_vncover_b — 1 : bit;   signal vncover_eb — 1 : bit;   signal t_vncover_b — 0 : bit;   signal vncover_eb — 0 : bit;   signal t_vncover_reset : bit;   -- synopsys translate_off   signal vhdlcover_id : integer :=−1; -- For VN-Cover PLI   for all : vnemulator_slatch use entity vnemulator.vnemulator_slatch(rtl);
               for all : vnemulator_trigger use entity   
               
           vnemulator.vnemulator_trigger(rtl);
           for all : vhdlcover_probe0 use entity vnvhdl.vhdlcover_probe0;   -- synopsys translate_on   
           begin
           -- synopsys translate_off
               -- For VN-Cover PLI   
               transeda101: vhdlcover_probe0 generic map(−1,
               “./vnavigator_files/BRANCH_EXAMPLE-RTL.control”,   
               
           3, 1);
           -- synopsys translate_on   PROC — 1 : process(en, d)   begin
               t_vncover_b — 0 &lt;= ‘0’;   t_vncover_b — 1 &lt;= ‘0’;   q &lt;= ‘0’;   if en = ‘0’ then
                   t_vncover_b — 0 &lt;= ‘1’;   q &lt;= d;   
                   else
                   t_vncover_b — 1 &lt;= ‘1’;   
                   end if;   
               end process;   vncover_trigger : vnemulator_trigger port map(t_vncover_reset);   vncover_b — 0 : vnemulator_slatch port map(t_vncover_reset,
               t_vncover_b — 0, vncover_eb — 0);   
               vncover_b — 1 :vnemulator_slatch port map(t_vncover_reset,
               t_vncover_b — 1, vncover_eb — 1);   
               
           end;       

     VHDL that is not in general supported for synthesis is enclosed in pragma comments that cause the synthesis tool to ignore it. 
     Lines marked with the comment ‘-- For VN-Cover PLI’ are required for the generation of the history template file. The vnvhdl library (not defined here) is the standard TransEDA library of components used to support code coverage on a logic simulator. An instance of a vnvhdl component, vhdlcover_probe0, is inserted into the design. This component is declared in the vnvhdl library as a foreign model and is bound to a C function in the VN-Cover PLI attached to the logic simulator. At the start of simulation, this C function is invoked for each instance of the BRANCH_EXAMPLE module in the design. In this way instances of instrumented module register themselves with the VN-Cover PLI. The PLI can then write the template history file containing the cover-probe information for the design. 
     The instrumented code contains two branch probes. The first records whether the if-branch in the process, PROC — 1, was ever taken during a simulation, the second whether the missing else-branch was ever taken. 
     For the if-branch, a BIT signal, t_vncover_b — 0 is declared. It is initialized to ‘0’ at the top level of the process so that the assignment to ‘1’ inside the if-branch does not infer a latch in the synthesis process. This signal is also attached to the IN port, s, of the VNEMULATOR_SLATCH instance, vncover_b — 0. 
     If the if-branch is executed during a simulation, the value of this signal is driven to ‘1’. This rising edge causes the vncover_b — 0 latch instance to latch a ‘1’, ie. it captures the fact that the if-branch was taken. 
     In a similar way, the vncover_b — 1 latch records whether the missing else-branch was ever taken. 
     The OUT port of the VNEMULATOR_TRIGGER instance is attached to the reset port of both latch instances. The user can force both latches to reset by forcing the value of the trigger&#39;s OUT port high. 
     The diagram of  FIG. 3  shows the synthesised logic for the instrumented example above. (Note that GTECH_LD1 is inferred logic). The outputs form the two BNEMULATOR_SLATCHs hold the coverage values for the two inserted branch probes, where a value 0 indicates the “uncovered” state for the branch probe and the value 1 represents the covered state. It is these values that are read by the extraction script. 
     For-Generate Handling 
     For a branch inside a for-generate statement, branch coverage is defined as follows: the branch is said to be covered if the branch was executed in any iteration of the for-generate statement. 
     The following VHDL example shows a branch inside a for-generate statement.
         library ieee;   use ieee.std_logic — 1164.all;   entity FOR_GEN_BRANCH is
           port (
               d :in std_logic_vector(1 downto 0);   en :in std_logic_vector(1 downto 0);   q :out std_logic_vector(1 downto 0)   
               );   
           end;   architecture RTL of FOR_GEN_BRANCH is   begin
           GEN — 1 : for i in 1 downto 0 generate
               PROC — 1 : process(en, d)   begin
                   q(i) &lt;= ‘0’;   if en(i) = ‘1’ then   q(i) &lt;= d(i);   
                   end if;   
               end process;   
           end generate;   end;       

     When instrumented, the following VHDL is produced. It is presented here in slightly simplified form to make the relevant details clearer.
         library ieee;   use ieee.std_logic — 1164.all;   library vnemulator;   entity FOR_GEN_BRANCH is
           port (
               d :in std_logic_vector(1 downto 0);   en :in std_logic_vector(1 downto 0);   q :out std_logic_vector(1 downto 0)   
               );   
           end;   library vnemulator; use vnemulator.vnemulator_declarations.all;   architecture RTL of FOR_GEN_BRANCH is
           signal t_vncover_b — 1 : vnemulator_or_bit;   signal vncover_eb — 1 : bit;   signal t_vncover_b — 0 : vnemulator_or_bit;   signal vncover_eb — 0 : bit;   signal t_vncover_reset : bit;   
           begin
           GEN — 1 : for i in 1 downto 0 generate
               PROC — 1 : process(en, d)   begin
                   t_vncover_b — 0 &lt;= ‘0’;   t_vncover_b — 1 &lt;= ‘0’;   q(i) &lt;= ‘0’;   if en(i) = ‘1’ then    t_vncover_b — 0 &lt;= ‘1’;    q(i) &lt;= d(i);   else    t_vncover_b — 1 &lt;= ‘1’;   end if;   
                   end process;   
               end generate;   vncover_trigger : vnemulator_trigger port map (t_vncover_reset);   vncover_b — 0 : vnemulator_slatch port map (t_vncover_reset,
               t_vncover_b — 0, vncover_eb — 0);   
               vncover_b — 1 : vnemulator_slatch port map (t_vncover_reset,
               t_vncover_b — 1, vncover_eb — 1);   
               
           end;       

     Each iteration of the generate statement produces a copy of the process contained in it. Each copy of the process contains a driver onto the signals t_vncover_b — 0 and t_vncover_b — 1, so in the above example, each signal has two drivers. In contrast to the standard branch example above, these signals are declared to be of the subtype vnemulator_or_bit, declared in the VNEMULATOR_DECLARATIONS package. When any one of the drivers of this signal has the value ‘1’, then the resolved value of the signal is ‘1’. This conforms to the definition of branch coverage inside for-generate loops as defined above. 
     The diagram of  FIG. 5  shows the synthesised logic for the instrumented example above. Again, we have the VNEMULATOR_TRIGGER input and the two VNEMULATOR_SLATCHs for output. 
     Branch in for-Loop Handling 
     For a branch inside a for-loop statement, branch coverage is defined as follows: the branch is said to be covered if the branch was executed in any iteration of the for-loop statement. 
     The following VHDL example shows a branch inside a for-loop statement.
         library ieee;   use ieee.std_logic 1164.all;   entity FOR_LOOP_BRANCH is
           port (
               d :in std_logic_vector(1 downto 0);   en :in std_logic_vector(1 downto 0);   q :out std_logic_vector(1 downto 0)   
               );   
           end;   architecture RTL of FOR_LOOP_BRANCH is   begin   PROC — 1 : process(en, d)   begin
           q &lt;= “00”;   for i in 1 downto 0 loop
               if en(i) = ‘1’ then
                   q(i) &lt;= d(i);   
                   end if;   
               end loop;   
           end process;   end;       

     When instrumented, the following VHDL is produced. It is presented here in slightly simplified form to make the relevant details clearer.
         library ieee;   use ieee.std_logic — 1164.all;   library vnemulator;   entity FOR_LOOP_BRANCH is
           port (
               d :in std_logic_vector(1 downto 0);   en :in std_logic_vector(1 downto 0);   q :out std_logic_vector(1 downto 0)   
               ):   
           end;   library vnemulator; use vnemulator.vnemulator_declarations.all;   architecture RTL of FOR_LOOP_BRANCH is
           signal t_vncover_b — 1 : bit;   signal vncover_eb — 1 : bit;   signal t_vncover_b — 0 : bit;   signal vncover_eb — 0 : bit;   signal t_vncover_reset : bit;   
           begin
           PROC — 1 : process(en, d)   begin
               t_vncover_b — 0 &lt;= ‘0’;   t_vncover_b — 1 &lt;= ‘0’;   q &lt;= “00”,   for i in 1 downto 0 loop
                   if en(i) = ‘1’ then    t_vncover_b — 0 &lt;= ‘1’;    q(i) &lt;= d(i);   else    t_vncover_b — 1 &lt;= ‘1’;   end if;   
                   end loop;   
               end process;   vncover_trigger : vnemulator_trigger port map (t_vncover_reset);   vncover_b — 0 : vnemulator_slatch port map (t_vncover_reset,
               t_vncover_b — 0, vncover_eb — 0),   
               vncover_b — 1 : vnemulator_slatch port map (t_vncover_reset,
               t_vncover_b — 1, vncover_eb — 1);   
               
           end;       

     The signals t_vncover_b — 0 and t_vncover_b — 1 have each only one driver. During the synthesis process, the for-loop is unrolled producing (in this case) two iterations of the logic contained in it, ie for i=0 and for i=1. The logic produced is such that the signal takes the value ‘1’ if it is assigned the value ‘1’ in any of the unrolled loop iterations. This conforms to the definition of branch coverage inside for-loops as defined above. 
     The diagram of  FIG. 6 , which is identical to the diagram of  FIG. 5  because this code generates the same synthesised logic for the instrumented example just above. 
     Statement Probe Feature Implementation 
     One of the instrumentation options is “statement probes”. Each statement in the module being instrumented is associated with a statement probe that is activated when that statement is executed in simulation. “Statement” is a general term that includes VHDL processes. When a process is instrumented a statement probe is inserted at the top of the process. In simulation, this probe is activated when the any of the signals in the sensitivity list of this probe change. (A sensitivity list is a list of gates that are affected by the output of some other circuit. They are “sensitive” to changes in signal from such other circuits. An example might be where a signal p 1  is valued as &lt;p 2  AND p 3 , thus making p 1  sensitive to changes in value of either p 2  or p 3  or both). Synthesis tools do not provide a way to handle sensitivity lists and as a result, statement probes are “optimized” in the prior art by being tied high when the instrumented VHDL is synthesized. The following statement probe implementation overcomes the problem of the VHDL sensitivity list not being synthesizable by storing the initial value of all of the signals in the sensitivity list and by providing a comparison mechanism to cause the stateprobe to activate when the current and initial value of the sensitivity list are not equal. The design also provides a reset mechanism to allow the collected data to be reset after as needed. This feature could be used after an initialization sequence or to collect coverage data on individual tests in a long test suite. 
     The diagram of  FIG. 7  shows the three parts of this implementation: 1) A trigger  72  that provides the control signals for the other parts, 2) the sensitivity list implementation (input  71  with a signal N bits wide containing all bits of the sensitivity list and circuit  73  using an N bit wide XNOR  75  for comparison with last latched in values) and 3) the slatch  74  that is set when the statement probe is activated. There is one trigger per instrumented module. The latch in this module is set initially. The logic automatically resets the latch after the shortest possible delay in CoBALT. 
     The sensitivity list hardware consists of 
     1) An N bit latch (where N is the total number of bits of the signals in the sensitivity list). This latch must be a level sensitive latch for the circuit to work correctly on cobalt. 
     2) A compare circuit that compares the current value of the sensitivity list signals to the captured value. The output of that compare is gated with the enable_compare signal. This signal is necessary so that a compare does not happen before the initial values are captured. 
     Initially, the latch module provides an active enable_capture signal and an inactive enable_compare signal (they are complements of each other). This causes the N bit latch to capture the initial value of the sensitivity list signals. It also causes the slatch coverage register to reset. After the delay, the enable_compare signal will become active which enables compare function. 
     VHDL for TRIGGER module: 
     entity VNEMULATOR_TRIGGER is
         port (
           reset :buffer bit := ‘1’;   enable_compare : out bit   
           );       

     end; 
     architecture RTL of VNEMULATOR_TRIGGER is 
     signal delay_reset :bit; 
     signal reset_bar :bit; 
     component COBALT_UNIT_DELAY
         port (
           A: in bit;   Z: out bit   
           );       

     end component; -- COBALT_UNIT_DELAY 
     begin
         UQ_DELAY : COBALT_UNIT_DELAY port map (A=&gt;reset, Z=&gt;delay_reset);   -- the reset state element below will be given an initial value of ‘1’ on the emulator   process (delay_reset)   begin
           if delay_reset′event and delay_reset=‘1’ then
               reset &lt;= ‘0’;   
               end if;   
           end process;   enable_compare &lt;= not reset;       

     end; 
     VHDL implementation for SENSITIVITY LIST HARDWARE implementation: 
     library ieee; 
     use ieee.std_logic — 1164.all; 
     entity STMT_EXAMPLE is
         port (
           p 1  :out std_logic;   p 2 , p 3  :in std_logic   
           );       

     end; 
     architecture RTL of STMT_EXAMPLE is
         signal vncover_es — 0 : bit;   signal t_vncover_s — 0 : bit;   signal t_vncoverc_p 2  : std_logic;   signal t_vncoverc_p 3  : std_logic;   signal reset, enable_compare : bit;   component vnemulator_trigger
           port (
               reset :buffer bit;   enable_compare : out bit   
               );   
           end component,   component VNEMULATOR_SLATCH   port (
           clear :in bit;   s :in bit,   q :out bit   
           );   end component;       

     begin
         t_vncover_trig : vnemulator_trigger port map (reset, enable_compare);   vncover_s — 0 : vnemulator_slatch port map (reset,
           t_vncover_s — 0, vncover_es — 0);   
           process(p 2 , p 3 )   begin
           p 1  &lt;= p 2  and p 3 ;   
           end process;   process(reset)   begin
           if (reset′event and reset = ‘1’) then
               t_vncoverc_p 2  &lt;= p 2 ;   t_vncoverc_p 3  &lt;= p 3 ;   
               end if;   
           end process;   process(enable_compare, p 2 , p 3 , t_vncoverc_p 2 , t_vncoverc_p 3 )   begin
           assert false report “compare process woken up” severity note;   t_vncover_s — 0 &lt;= ‘0’;   if enable_compare = ‘1’ and
               (p 2 /=t_vncoverc_p 2  or p 3 /= t_vncoverc_p 3 ) then   t_vncover_s — 0 &lt;= ‘1’;   
               end if;   
           end process;       

     end; 
     Reset Trigger Implementation 
     Both branch and statement probes require that the SLATCH be reset to the “unencountered” state after the emulation run has been initialized. This is accomplished by the VNEMULATOR-TRIGGER circuit previously discussed. 
     This trigger circuit is instantiated in each instrumented module. The circuit is simply a latch with no input and one output. The output is tied to the reset signal of each instantiated SLATCH in that module. After the emulation run is initialized, it pauses and an external Tcl script is run which sets the internal latch of each trigger component, thereby resetting every SLATCH in the design. 
     Toggle Coverage Implementation 
     Another coverage option that needs a special implementation for CoBALT is “toggle” coverage. This coverage type checks to see if a given signal has made a high to low transition and a low high transition. The implementation consists of 2 components, where each component has the signal of interest as an input and has an edge triggered latch. The latch in one component is set when it sees a rising edge on the input signal, the other is set when it sees a falling edge. The following VHDL code and diagram show the implementation of the design. There is a version of the modules for signal bit inputs, bus inputs and Boolean signal inputs. We have found that toggle coverage on the output signal of a process provides a greater amount of information than the statement probe insert in the same processes because it shows that process has not only been activated but the signal is visited in both states. Refer to  FIGS. 8A and 8B  for diagrams of the falling edge detect triggered latch and the rising edge detect triggered latch, respectively. 
     Tie-High, Tie-Low, and Switches Coverage 
     This feature is described in detail in a patent filed on even date herewith entitled Identifying Specific Netlists and Finding Unexercised Logic for use in Code Coverage Testing U.S. application Ser. No. 10/324,608, now U.S. Pat. No. 7,117,458, which shares one co-inventor with this patent. Generally, the multi-step method outlined below is a process that allows the probes that will not be exercised during the course of simulation due to gating by signals tied to constant values or signals controlled by “switches” to be identified so that they can be covered. It is:
         1) The values of all registers to be used as switches for the given simulation are obtained.   2) The HDL code is synthesized to a gate level netlist that has simulation models available for the gates used in the netlist.   3) The netlist is brought into an event based simulator using the functional gate models. This necessary because netlists are synthesized without regard to process sensitivity lists. Using the normal HDL code in the simulation could result in erroneous results.   4) All inputs and register output are forced to the X state.   5) The switch registers are forced to their constant values.   6) All signals that are expected to be tied high or low must be in the expected state (Synthesis tools should instantiate logic — 0 or logic — 1 cells to give the proper values but in some cases where this does not happen this will need to done in the simulation).   7) Then the simulation is run and all probe signals are examined; any probe signals that do not have an X value are dependant only on switches or signals that are tied high or low and will not be exercised by any tests run on the simulation. Probe values of 1&#39;s would be marked as covered in the event-based simulator, value=0 are the probes that will never be entered because they are inaccessible due to the constant registers or tie-offs.       

     It can be illustrated more completely with reference to  FIG. 9  in which the general process  60  for finding unexercised logic is described. We start with the source file  61 , and instrument it  62  with probe registers for all the gates. In doing so the reset and extract signals and paths are also constructed, and all this can be done automatically with the software. Once this is completed, we synthesize the target netlist for the design  63 , using our generic technology gates (GTECH), as mentioned earlier. At this point there are two branches, event based simulation and emulation testing of the netlist. From the first branch  64 , we want to determine which gates are unexercised, producing a set of probes that have not changed their values from the initial value (C), and from the second  65 , we want to extract the probe register values themselves ( 66 ). Then we can filter out coverage data that is dependent on constants or configuration registers ( 67 ), as we describe in step  7  of the outlined steps above. The final report or file will preferably have a list of uncovered circuits  68 , from which a designer can assess the validity of the design, and do further testing. Logic unexercised due to constants can be modified to be more testable, or ignored, if it is only used for limited purposes and the purpose can be tested through reconfiguration of date inputs. 
     Naming Conventions 
     To avoid name clashes between identifiers in the original HDL and identifiers added to the HDL during instrumentation, the inserted identifiers will contain the string ‘vncover’. 
     Temporary names, ie. names of objects that don&#39;t need to be accessed on the emulator, will have the prefix ‘t_vncover’, the ‘t_’ standing for ‘temp’. 
     The labels of SLATCH instances (which hold coverage probes) are named as follows:
         For statement probes :vncover_s_&lt;int_id&gt;   For branch probes :vncover_b_&lt;int_id&gt;   For rising toggle probes :vncover_tr_&lt;int_id&gt;   For falling toggle probes: vncover_tf_&lt;int_id&gt;
 
where &lt;int_id&gt; is an integer representing the probe number, the lowest value being 0
       

     Interfaces and File Formats for Preferred Embodiment Implementation in CoBALT 
     State Retrieval 
     After the instrumented design has been executed, the various state variable values must be retrieved to be analyzed. To retrieve a value on CoBALT, one could always use:
         value &lt;slatch_inst&gt;.Q_REG       

     The Unisys Tcl shell translates this name (slatch_inst.Q_REG) to the real CoBALT name. A keepNets file would be required to retain the original port names. Then the same command could work on Leapfrog/NC-Sim and CoBALT:
         value &lt;slatch_inst&gt;.Q       

     To make the extract script as resilient as possible we implement the above value using the Tcl “catch” construct that allows an errors with latch names to be trapped and reported: 
     Here is an example:
         proc safe_value args {
           if {[catch {set result [value -dec $args]}] == 1} {
               puts “ERROR: value -dec $args failed”   return 0   
               }   return $result   
           }   proc vncover_extract_slatch_values { } {
           if [catch {open emulator.values w} file] {
               puts stderr “Cannot open ‘emulator.values’ for writing”   return   
               }   puts stderr “Writing coverage values to ‘emulator.values’”   puts $file “adder1.vncover_b — 0 [safe_value adder1.vncover_b — 0.q_REG]”   puts $file “adder1.vncover_b — 1 [safe_value adder1.vncover_b — 1.q_REG]”   puts $file “adder1.vncover_b — 2 [safe_value adder1.vncover_b — 2.q_REG]”   puts $file “adder1.vncover_b — 3 [safe_value adder1.vncover_b — 3.q_REG]”   
           }       

     History Template File 
     Prior to running an instrumented design in CoBALT, the design is loaded into a software simulator so the hierarchical probe names can be retrieved. This hierarchy and the common prefix associated with each type of probe are stored in the header of the History Template file. History Template files are encapsulated standard History files, preceded by this header.
         A Perl script is used to parse the History Template file and generate a Tcl script which is used to extract the probe values. A second Perl script then converts the output of the Tcl script into a standard History file for use by VN-Cover. The industry has several versions of files like this, but it is useful to understand how the one used here is set up, so this section is provided for that purpose. The History and History Template file formats are shown below.   The file format is line based. Elements on a line are separated by a single space.   Key:
           [ ]=optional elements   { }=zero or more repetitions   . . . =repeated element (or line if at start of line)   &lt;CR&gt; newline character   
           history_template_file ::=
           history_template_header   augmented_format — 3_history_file   
           history_template_header ::=
           history_template_format: 2 &lt;CR&gt;   user_comment: &lt;text&gt; &lt;CR&gt;   probe_prefix_definitions   probe_counts_line   emulator_overhead_line   0 0 0 0 0 0 0 0 0 0 &lt;CR&gt; Note 1   
           probe_prefix_definitions ::= Note 1a
           prefixes: &lt;reset_trigger_label&gt; &lt;branch_prefix&gt; \
               &lt;falling_toggle_prefix&gt; &lt;rising_toggle_prefix&gt; \   &lt;toggle_generate_prefix&gt; &lt;CR&gt;   
               
           probe_counts line ::= Note 1b
           probe_counts: &lt;reset_trigger_count&gt; &lt;branch_count&gt; &lt;toggle_count&gt; &lt;CR&gt;   
           emulator_overhead_line ::= Note 1c
           overhead: &lt;N&gt; gates &lt;N&gt; latches &lt;N&gt;   
           augmented_format — 3_history_file ::= Note 2
           format: 3 &lt;CR&gt;   {run} Note 2a   
           run ::=
           run: &lt;name&gt; &lt;CR&gt; Note 2b   start: &lt;epoch_time&gt; &lt;CR&gt; Note 3   elapsed: &lt;sim_time_in_secs&gt; &lt;CR&gt; Note 3a   &lt;num_instances&gt; &lt;CR&gt;   {instance}   
           instance ::=
           instance_header   instance_body   
           instance_header ::=
           &lt;source_filename&gt; &lt;CR&gt;   &lt;control_filename&gt; &lt;CR&gt;   &lt;module_name&gt; &lt;CR&gt; May be empty line   &lt;instance_name&gt; &lt;CR&gt; May be empty line Note 3b   3 &lt;CR&gt; Note 4   
           instance_body ::=
           stmt_probes   branch_probes   0 &lt;CR&gt; #0 excluded_probes Note 4a   0 &lt;CR&gt; #0 path_probes   0 &lt;CR&gt; #0 condition_items   0 &lt;CR&gt; #0 trigger_probes   0 &lt;CR&gt; #0 trace_probes   toggle_probes   
           stmt_probes ::=
           &lt;num_lines_to_follow&gt; &lt;CR&gt;   {&lt;probe_id&gt; &lt;weight&gt; &lt;hit_count&gt; &lt;CR&gt;} Note 5, 5a, 5b   
           branch_probes ::= Note 5b
           &lt;num_lines_to_follow&gt; &lt;CR&gt;   {&lt;probe_id&gt; &lt;hit_count&gt; &lt;CR&gt;}   
           toggle_data ::=
           &lt;toggle_width&gt; [left_bound right_bound] &lt;CR&gt; Note 6   &lt;probe_id&gt; &lt;CR&gt; Note 6a   &lt;neg_edge_hit_count&gt; &lt;pos_edge_hit_count&gt; &lt;CR&gt; Note 6b   . . . (until toggle_width)   
           Notes   -----   1. 10 flag-fields for unspecified future use.   1a. The probe names define the prefixes of the latch instances that represent probes. For example, if the branch probe prefix name is ‘vncover_b_’, then a latch instance label of ‘vncover_b — 0’ represents branch probe 0. &lt;trigger_label&gt; defines the instance label of the trigger module in an emulator-instrumented module.   1b. The counts give the number of reset-trigger instances, branch probes and toggle probes in the complete design. Note that statement probes are derived from branch probes are therefore NOT counted. The counts can be used to estimate the time required to extract probe values from the emulator at the end of simulation, or the time required to activate reset-trigger instances in order to reset coverage when the circuit has been initialized.   1c. The counts *estimate* the number of gates and latches added to the design by the coverage instrumentation.   2. This is not a pure history file format. It differs in the following:
           The toggle signal width line has array bounds fields for array signals (see below).   
           2a. For the history template file, there will be one and only one ‘run’.   2b. Run names may contains spaces and unusual characters. The name starts after ‘run:’ and extends to the end of the line. The run-name represents the top level module of the design, eg. ‘ent:arch’.   3. epoch time is seconds since 1 Jan. 1970—a Unix timestamp. It represents the simulation start time.   3a. elapsed time is the length of the simulation. For emulators, we can use a token time of ‘1’.   3b. instance_name has the format:
           &lt;top_level_module&gt;.&lt;instance_label1&gt;.&lt;instance_label2&gt;.&lt; . . . &gt;   
           where &lt;top_level_entity_name&gt; is the name of the top level module (verilog) or entity/configuration (vhdl).   4. Emulator instrumentation is always instance based, hence this field always has the value ‘3’.   4a. For the time being, there will always be zero exclude, path, condition, trigger and trace probes in a history template file.   5. For statement and branch the probe_Ids are not necessarily consecutive. Statement and branch probes share the same probe-number namespace, ie stmt may have probe ids, 1 and 2; branch ids, 0, 1 and 2. Note that there is a statement probe with id 1, and a branch probe with   the same id. This is because for emulator coverage, statement probes are always inferred from branch probes.   Consider the following hdl code:   if(a == 1)
           stmt1   
           Here a branch probe within the ‘if’ statement can be used also to detect whether stmt1 was executed. No instrumentation is added for the statement probe. The statement probe does exist in the history file however, and its value is the value of the corresponding branch probe.   A branch probe inserted to represent the missing ‘else’ does not represent a statement probe. Hence here we would have one statement probe with id 0, and 2 branch probes with id&#39;s 0 and 1. Note that probe id 0 is shared—it is both a statement and a branch probe.   5a. For stmt probes, the weight is the number of statements in the source-code block, eg. if the weight is 4, then the statement probe represents 4 statements.   5b. For a template history file, the hit-count is an integer. The value of the integer is ignored. (This way, we can hand generate a history template file from a history file simply by adding an extra header.)   6. The toggle width is the width of the signal, ie. 1 for scalar signals and the value of &lt;signal&gt; ‘length for array signals. The left and right array bounds are specified for array signals only. NB: array bounds are present only in the history template file, not in a standard history file.   6a. Toggle probe ids start at 0. Under certain circumstances, a probe id may be missing, eg. the following sequence of probe is possible: 0, 1, 3, 4   6b. For a toggle_data, the toggle width determines the number of lines that follow the probe id. Each line has 2 hit-counts, (falling and rising edge toggle) that together represent one toggle probe. For array signals, the first line always represents the element of the array with the highest index; the last line represents the element of the array with the lowest index.