Interface independent test system

Details Interface independent test system Interface independent test system

1999-03-04

2002-07-16

Frejd, Russell (Department: 2123)

Data processing: structural design, modeling, simulation, and em

Simulating electronic device or electrical system

Circuit simulation

C703S020000, C714S026000, C714S033000, C714S038110

Reexamination Certificate

active

06421634

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer systems and more particularly to methods and apparatus for facilitating the testing and verification of integrated circuit designs using simulation tools.
2. Description of the Relevant Art
Because of the complexity of the circuitry in modern integrated circuits (ICs), the design of the circuitry is thoroughly tested before the actual circuit is manufactured. The testing is intended to identify errors in the design of the circuitry so that the errors can be corrected with minimal effort and expense. Typically, this testing is accomplished by simulating the functioning of the circuitry on a computer system using a hardware description language. (References herein to “HDL” will indicate a hardware reference language which may be Verilog or any other hardware description language.) The design engineers use an HDL to generate a detailed functional description of the circuitry including, for example, the input signals to be provided to the circuitry and the output signals which are produced in response thereto. The description of the circuitry may comprise descriptions of sub-components or “cells” and the interrelationships between these components. The resulting model can be used to simulate the behavior of the circuitry.
The HDL model of the circuitry is implemented in a simulation system to verify the proper functioning of the circuitry. The simulation system may comprise any one of a number of such systems, one example being the Verilog system, which is well known to those in the art. “Verilog” also refers to a particular HDL. The simulation system accepts data which defines the behavior of the circuitry as well as the signals to be input to the circuitry and, in response, generates data corresponding to simulated output signals.
Traditionally, the entire simulation system, including the functional description of the newly designed circuitry, has been written in HDL. Because HDL is used to form a detailed functional description of circuitry such as ASICs (Application-Specific Integrated Circuits), it is by nature a specialized and complex language. With the increasing complexity of these circuits, verification of functionality at the gate level is often insufficient because of the difficulty of observing the internal state of the circuitry at its I/O interface. Further, generating a set of tests for this circuitry can be a daunting task since HDL does not have many of the features which are found in higher-level languages and which make it easier for programmers to handle large software projects. It is therefore desirable to have an interface mechanism which allows tests written in higher-level languages to control a simulation written in HDL.
In addition to the testing difficulties resulting from the increased complexity of current ASICs, difficulties may arise from circuit designers' attempts to leverage intellectual property rights by integrating proprietary cores into their ASICs. These proprietary cores may themselves be very complex. Consequently, their operation generally needs to be verified in a stand-alone environment. Tests for these ASICs are therefore normally written specifically for the proprietary core in a stand-alone configuration. Usually, the tests are dependent upon the specific interface through which the core is driven during test. As a result, the tests cannot be reused once the proprietary core has been integrated into a larger ASIC. New tests must therefore be written to verify the operation of the integrated proprietary core, reducing the amount of time saved by using the already designed core.
Typically, the requirement of testing a proprietary core using several different interfaces is addressed by writing a different test procedure for each of the different interfaces. Each of these test procedures is given the same name, but is compiled separately and is saved in a separate library module. When a test application is linked, it is linked with the library module corresponding to the desired interface. This is, however, an awkward and error-prone process. The test writer must be able to identify and select the appropriate library from the multiple copies which must be maintained for the different interfaces. Even if the number of libraries is small, a mistake in choosing the correct library will introduce errors which may be difficult to identify and time-consuming to correct. This approach is also somewhat inconvenient because it is difficult to dynamically change the interface or to allow the use of several interfaces within the same test.
It would be helpful to be able to resolve this problem at compile time. One approach would be to use preprocessor directives to select the appropriate interface when the test application is compiled. Another approach would be to use function pointers to select the tests appropriate to a particular interface. Both of these approaches, however, are prone to error and result in code which is difficult to maintain.
It would be useful to be able to write tests in a manner which is independent of the interface to the circuit and which do not rely on the approaches suggested above. Interface independent tests could be written once to verify a particular sub-chip level functionality and then reused to test this functionality in the integrated ASIC. Although some tests (e.g. tests of the interface itself) cannot be written in an interface independent manner, many tests can be written this way. A generalized technique for writing interface independent tests would therefore be very beneficial and could provide considerable savings in the time required to test an ASIC. It would be useful to develop a class structure which would allow test writers to develop test code which is portable between several different ASIC interfaces without having to make substantial changes to the code.
Some of the problems facing test writers have been alleviated by the development of interface systems which allow tests to be written in high-level languages such as C and C++ instead of writing the entire simulation/test system in HDL. One such interface system is called CVI. The basis for CVI is described in U.S. Pat. No. 5,732,247 to Dearth, et al. CVI serves as an interface between a Verilog HDL simulation system and test system which is written in C++. CVI translates the C++ test statements into simulated bus activity in the simulation system. CVI is particularly useful in the development of simulation systems because the verification engineers who write the test procedures normally are not the same engineers who write the functional description of the new circuitry.
One important aspect of the CVI mechanism is that it allows the design of device objects which present a low-level register interface to the test writer. This is useful because it presents the test writer with a consistent interface style shared by all transactors and provides a consistent documentation format. (“Transactor” as used herein refers to a mechanism for executing a transaction, such as an implementation of a class or object as described in more detail below.) The low-level register interface is also intuitively appealing because the register model mimics modem computer system operation and is well understood by programmers. The CVI mechanism introduces a device driver abstraction which shields users from the low-level details of complex circuitry. This level of abstraction again provides test writers with a consistent view of many similar devices. The device drivers in the simulation system maintain state information regarding the devices in order to simplify control and scheduling of the operations of the device.
SUMMARY OF THE INVENTION
The issues surrounding the abstractions outlined above may be solved by various embodiments of the system and method of the present invention. One embodiment of the invention comprises a simulation system configured to model a circuit design and a test system configured to operate in cooperation

Affiliated with

Also associated with

Rating

Interface independent test system does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Interface independent test system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interface independent test system will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2908897