Tables of integrals

Techniques and systems for analysis, diagnosis and debugging fabricated hardware designs at a Hardware Description Language (HDL) level are described. Although the hardware designs (which were designed in HDL) have been fabricated in integrated circuit products with limited input/output pins, the techniques and systems enable the hardware designs within the integrated circuit products to be comprehensively analyzed, diagnosed, and debugged at the HDL level at speed. The ability to debug hardware designs at the HDL level facilitates correction or adjustment of the HDL description of the hardware designs.

Method and user interface for debugging an electronic system

The Gauss-Codazzi formalism is used to obtain exact solutions to Einstein's equations in the presence of domain walls. Domain walls are shown to have repulsive gravitational fields. The most general solution to Einstein's equations for a planar domain wall is obtained. Also, the motion of a spherical domain wall in an asymptotically flat space-time is derived.

The Gravitationally Repulsive Domain Wall

A method and system for instrumenting testcase execution processing of a hardware description language (HDL) model using a simulation control program. In accordance with the method of the present invention, a set name application program interface (API) entry point is called wherein the set name API entry point includes program instructions for naming a simulation control program in association with testcase execution of the HDL model. A create event API entry point is called, wherein the create event API entry point includes an event identifier input parameter which identifies a testcase execution event with respect to the named simulation control program. In response to executing a testcase simulation cycle, signal values are retrieved from the HDL model into an instrumentation code block, wherein the instrumentation code block includes program instructions for processing the retrieved signals to detect whether the testcase execution event has occurred during the testcase simulation cycle.

C-API instrumentation for HDL models

Disclosed is a device and method for testing of a program or a design of an electronic device comprising digital logic circuitry. The method comprises testing the design of software or an electronic device and injecting, after initiation of the testing step, a predetermined error pattern into a value operated upon by the design of the digital logic circuitry. In a preferred embodiment, the software is a simulation of the design of a processor having a cache with error detection and/or correction circuitry. A triggering condition is preferably a cache hit, in response to which a detectable error is injected into the cache. The simulated operations of the model are observed to determine whether the injected error is detected, as should happen if the processor's error detection circuitry has been designed properly. In another respect, the invention is an apparatus, or computer software embedded on a computer readable medium, for testing a program comprising an error detector. The apparatus or software comprises the program, an error injector module connected to the program; and a checker module connected to the program. The checker module is capable of determining whether the program responds appropriately to an error dynamically produced by the error injector module during execution of the program. By injecting errors dynamically the invention easily facilitates precisely focused testing at any time during simulated operation regardless of initialization conditions.

Method and apparatus for testing error detection

Coverage metrics are expressed with an intuitive graphical interface based upon data flow. Coverage analysis and presentation objects are integrated to produce coverage results which enable device functionality in a device under test to be modeled as objects, subject to event occurrence. Event objects are introspected at run-time, allowing the user to determine the event object's attributes with specification of coverage metrics subject to a selected combination of the event object's attributes. The event objects are serialized into permanent storage, allowing the user to specify and execute new coverage metrics at any time after simulation. Operations used to describe coverage metrics are modeled as analysis objects. Such analysis objects accept event objects as inputs, using a predetermined, well-defined interface. The combination of event objects and analysis objects allows coverage metrics to be specified in a simple data flow manner. With such a coverage metric, the user attaches or wires (metaphorically) the analysis objects together in a visual builder environment. Using the analysis objects, the user specifies desired coverage metrics, such as coverage of sequences of events and/or coverage of events that occur during the same time window of a simulation. The display functionality of the coverage tool is expandable because the presentation objects use the same event object interface as the analysis operator objects. Coverage metrics are subject to specification either before or after event occurrence. The user specifies coverage metrics using an intuitive graphical interface based upon data flow, without any specific programming language skills being necessary. Functional events in the device under test are treated as event objects. Each event object may be passed to selected analysis tools chosen by the user, such as analyzers, logic gates, and coincidence counters.

Functional coverage analysis systems and methods for verification test suites

A transaction checking system and method to verify bus bridge designs in multi-master bus systems. A state machine model is created for each bus in the system. An initiator cycle list and a target cycle list store corresponding bus cycle state machine objects and transition their states according to bus signals. The bus cycle state machines provide a means of persistent storage for other verification tasks. A bus bridge model may store a copy of each configuration register for the bus bridge, thereby monitoring current state of the bus bridge. False failures due to data merging, data collapsing and address remapping are avoided. A cache model and a cycle-based messaging system provide verification of proper cache master operation. Cache coherency errors may also be detected. A statistics keeping object may be created to monitor and store all pertinent performance information for the bus bridge. The transaction checking system may monitor the state of the bus bridge in a device independent manner and with tighter verification. The cycle-based approach to verification of internal states of a bus bridge results in a sound resolution of bus cycles with a better predictability of possible failures. Bus monitors may be employed along with the bus bridge model object to determine the values of the bus bridge configuration registers. This allows timing and other protocol related functionality of a system bus attached to the bus bridge to be verified without restricting the bus monitor to a specific bus bridge design (e.g., without requiring the bus monitors to maintain the net list names for the various configuration registers identified by the hardware description language representation of the bus bridge). Additionally, future bus bridge designs can also be tested in a device independent manner.

Bus bridge verification system including device independent bus monitors

A test methodology for a cache memory subsystem includes setting a test unit to initiate a snoop cycle on a local bus upon lapse of a predetermined delay. The predetermined delay is initially set to a very short delay or a zero delay. The snoop cycle to be executed may take the form of an inquire cycle to a predetermined memory address. The test unit is further set or programmed to begin monitoring the local bus for certain activity including activity which is indicative of whether the snoop cycle occurred. After programming the test unit, the processor core executes a memory operation associated with the address of the snoop cycle. This memory operation causes a cache line transition. At some point, either before, during or after effectuation of the memory operation, the snoop cycle is executed by the test unit in accordance with the predetermined delay. Upon completing the memory operation, a status register is read from the test unit to determine whether the snoop cycle has yet occurred. If the snoop cycle occurred prior to completing the memory operation, the predetermined delay is increased and the test is repeated for the increased delay. Prior to repeating the test, the cache line's coherency with external memory is checked for conformance with the cache protocol. Additionally, the test unit may further be programmed to detect an occurrence of certain external local bus signals generated by the cache memory subsystem, such as a signal indicating a hit to a cache line occurred, and a signal indicating that a hit to a modified line in the cache occurred. The test is repeated until it is determined that the snoop cycle has not occurred upon completion of the line fill instruction.

Cache coherency test system and methodology for testing cache operation in the presence of an external snoop

A system and a method to monitor performance and resource utilization for a bus bridge in a computer system are described. All pertinent performance information for the bus bridge is stored in a statistics keeping or monitor object. A bus object is created for each bus in the system. Each bus cycle object receives the current cycle count and sends elapsed time information to the monitor object. A plurality of cycle list objects can also be used to track resource usage by sending messages to the monitor object indicating the type of cycles that enter the bus bridge. The monitor object then tracks the number of pending cycles that accumulate within the bus bridge. Thus, the statistics keeping object can indicate the current usage of each tracked resource.

State machine based bus bridge performance and resource usage monitoring in a bus bridge verification system

A verification system and method for verifying operation of an HDL (Hardware Description Language) design of a computer system component are disclosed. The computer system is configured to interface between a first bus and second bus. During verification, a simulated model of the HDL design is coupled to a simulated first bus and a simulated second bus. A designated stimulus is applied to the simulated model through the simulated first bus. A stimulus file stored in the computer system memory is configured to specify the designated stimulus to be applied. In response to the designated stimulus, the simulated model initiates bus cycles on the simulated second bus. A transaction checker is provided in the computer system memory to receive information relating to these bus cycles from said simulated second bus. By employing two different busses--one to apply a stimulus and the other to resolve the bus cycle through transaction checking--an effective decoupling of test stimulus from the checking environment is achieved. Due to decoupling, the test environment can be made more robust, and can be used to generate random responses, remap memory, inject errors into data streams etc.

Hamilton B. Carter

Papers

Functional coverage analysis systems and methods for verification test suites

Bus bridge verification system including device independent bus monitors

Cache coherency test system and methodology for testing cache operation in the presence of an external snoop

State machine based bus bridge performance and resource usage monitoring in a bus bridge verification system

Verification strategy using external behavior modeling