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.

Abstract: A code coverage tool provides that a netlist is instrumented with gates for providing a comparison of an output of the design gates on one cycle with their output on a next cycle to determine if the gate was exercised during an emulation.

Abstract: A code coverage tool can be made more useful if circuits of a specified function can be identified by their truth table. This knowledge can be used during code coverage testing to determine what circuits may not be covered during the appearance of specified input data configurations for such circuits. Forcing all circuits to a specified state and running the truth table data through them, when properly instrumented in emulation allows for determination of such specified functionality.

Abstract: In a data processing system comprising a first level cache, a second level cache, and a processor return path, wherein only one of the first level cache and second level cache can control the processor return path at a given time, an improvement comprises a queue disposed between an output of the first level cache and the processor return path to buffer data output from the first level cache so that the first level cache can continue to process memory requests even though the second level cache has control of the processor return path.