|Publication number||US5991529 A|
|Application number||US 08/857,154|
|Publication date||Nov 23, 1999|
|Filing date||May 16, 1997|
|Priority date||May 16, 1997|
|Publication number||08857154, 857154, US 5991529 A, US 5991529A, US-A-5991529, US5991529 A, US5991529A|
|Inventors||Steven R. Cox, Harry M. Chue|
|Original Assignee||Sony Corporation, Sony Electronics Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (15), Non-Patent Citations (2), Referenced by (11), Classifications (6), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to the field of integrated circuit design, simulation and testing. More particularly, the present invention relates to an improved technique for testing a hardware implementation of an integrated circuit design using test algorithms developed for verifying a software simulation of the integrated circuit design.
Designing an integrated circuit typically involves creating a software model for the integrated circuit. The software model is a software algorithm that emulates the behavior of a design for the integrated circuit. To analyze and verify the design, diagnostic tests can be performed on the software model and, based upon the results, the design can be modified. Using a software model allows the design for the integrated circuit to be analyzed and verified before the integrated circuit is actually implemented in hardware. This is especially advantageous when the integrated circuit has a high density of logic elements and a broad range of functions which can make the integrated circuit relatively expensive to implement in hardware.
After the design for the integrated circuit has been verified using the software model, the design is implemented in hardware. Preferably, the hardware implementation is also tested to ensure that it performs as expected. Due to differences between the software model and the hardware implementation, such as in speed of processing capability, and differences in how each interacts with its respective environment, diagnostic tests utilized for testing the software implementation are generally not applicable for testing the hardware implementation, model and for testing the hardware implementation. This approach is disadvantageous due to the time and expense required to formulate these separate tests. In addition, because separate diagnostic tests are utilized, their results can be difficult to correlate, thus, making the debugging process difficult and time consuming.
Court et al., in U.S. Pat. No. 5,483,673, entitled: "Automatic Interface For CPU Real Machine and Logic Simulator Diagnostics" suggest the desirability of re-using diagnostics that exist for testing hardware of a prior generation of a system design for testing a software simulation of a next generation of the design. Court et al. recognize, however, that doing so is not practical because the software simulation runs on the order of a million times slower than the actual hardware. Therefore, Court et al. teach a method to speed up the execution of diagnostics in software simulations. The method involves identifying those functions which should be run on the real-machine and those that need to be run on the software simulator; executing those functions that must be run in the software simulator in the software simulator, while executing at least some of those functions that may be run on the real-machine on the real-machine; and coordinating the functions executed between the real-machine and the simulator to provide a diagnostic check-out of the system.
The approach taken by Court et al. has a drawback in that it assumes, as a starting point, that diagnostics for testing the hardware implementation already exist as having been developed for a previous generation of the system design and also assumes that the prior hardware also exists. Depending upon the differences between the prior design and the new design, however, modifications to the prior diagnostics could be required and, when a completely new system is designed, no such diagnostics will exist. Further, the method requires coordinating results obtained from testing portions of the simulation with results obtained from testing portions of the hardware, which could increase the difficulty of determining the source of faults.
Therefore, what is needed is an improved technique for testing a software model of a design for an integrated circuit and for testing a hardware implementation of the design that does not have the disadvantages associated with the prior art. In particular, what is needed is a technique for testing a software model of a design for an integrated circuit that does not require separate diagnostic tests for the software model and for the hardware implementation and that does not depend upon the existence of a prior generation of the design.
The invention is a technique for testing a hardware implementation of an integrated circuit design using test algorithms developed for testing a software model of the integrated circuit design. A software model is created for a design of the integrated circuit. The software model is a software algorithm that emulates behavior of the integrated circuit under design. In addition, a virtual environment for the software model is also constructed. The virtual environment is a software algorithm that emulates an actual environment anticipated for the integrated circuit. A series of diagnostic tests are performed on the software model while it is operating in the virtual environment. These tests are used to verify and analyze the design for the integrated circuit. Based upon the results of the diagnostic tests, the design can be modified as necessary.
Once the design for the integrated circuit has been verified by testing the software model, an actual hardware circuit is constructed that implements the software model. In addition, an actual hardware environment is constructed that implements the virtual environment. Accordingly, the software model and the virtual environment are transformed into equivalent hardware circuits. Because of the equivalency between the software model and the hardware circuit and between the virtual environment with the hardware environment, the same diagnostic tests that were used to verify and analyze the software model in the virtual environment can be used to verify and analyze the hardware circuit in the hardware environment. This results in good test coverage for the integrated circuit design and reduced expense for developing the diagnostic tests.
FIG. 1 illustrates a block schematic diagram of the present invention.
FIG. 2 contrasts test code utilized for verifying a software model with test code utilized for verifying a hardware circuit.
FIG. 3 illustrates a block schematic diagram of an exemplary hardware environment utilized to verify a design for an integrated circuit processor TR3100.
FIG. 1 illustrates a block schematic diagram of the present invention. A software model 100 is illustrated in a virtual environment 200. The software model 100 is a software program that runs on a host computer system (not shown) and that emulates a design for a hardware circuit 102. For example, the design can be for an integrated circuit, such as a microprocessor, a controller, a logic device or a finite state machine. The virtual environment 200 is a software program that also runs on the host computer system and that emulates a design for a hardware environment 202 for the hardware circuit 102. For example, if the design is for an integrated circuit microprocessor, the virtual environment 200 will generally emulate memory devices, their associated memory maps, input/output devices, input/output port addresses, various registers and their associated register definitions, but could emulate a wide variety of devices and parameters associated with the anticipated environment external to the circuit under design. Together, the software model 100 and the virtual environment 200 form a virtual system 300.
A step in the design of the hardware circuit 102 is to generate the software model 100 for the design and the virtual environment 200 by appropriately programming the host computer system. Test code 400 is developed which provides stimulus for the software model 100 to execute instructions within the virtual environment 200 and to provide an indication of whether the operations were performed as expected. For example, a test can include the software model 100 loading a sequence of bits into a virtual memory device located in the virtual environment 200 according to a particular algorithm, retrieving the bits, and then examining the bits to determine if the values were loaded and retrieved correctly. Thus, the virtual environment 200 is necessary to test functions of the software model 100 that involve interaction of the design for the hardware circuit with its environment.
Preferably, the test code 400 includes a wide variety of diagnostic tests that can be selectively performed so that the design for the hardware circuit can be thoroughly analyzed and verified. The design can be modified by making corresponding changes to the software model 100 if the results are not satisfactory.
Once the software model 100 is completely debugged, the software model 100 is transformed into an equivalent hardware circuit 102 by any known means. The equivalent hardware circuit 102 can be constructed using programmable logic, interconnected logic modules, discrete components or can be a completely integrated hardware implementation of the design. It is important, however, that the hardware circuit 102 is equivalent to the software model 100 in that the hardware circuit 102 provides functionality that is equivalent to the functionality of the software model 100. In addition, the virtual environment 200 is transformed into an equivalent hardware environment 202 for the hardware circuit 102. The hardware environment 202 can include various types of memory devices, registers, input/output ports and devices, co-processors, power supplies, and the like. It is important that the hardware environment provides functionality that is equivalent to the functionality of the virtual environment 200. Together, the hardware circuit 102 and the hardware environment 202 form a hardware system 302.
It is important that a logical distinction can be drawn between the software model 100 and the virtual environment 200 so that when they are transformed into the equivalent hardware circuit 102 and into the equivalent hardware environment 202, respectively, a physical distinction can be drawn between the hardware circuit 102 and its hardware environment 202. Maintaining such logical and physical distinctions will facilitate the process of isolating and correcting any faults located during the process of analyzing and verifying the design. In addition, maintaining such a physical distinction will enable the design for the hardware circuit 102 to be separated from the design for the hardware environment 202 for manufacturing the hardware circuit 102.
FIG. 2 contrasts the test code 400 utilized for verifying the software model 100 with the test code 402 utilized for verifying the hardware circuit 102. Because the hardware circuit 102 and hardware environment 202 are functionally equivalent to the software model 100 and the virtual environment 200, respectively, the test code 400 used to verify and analyze the software model 100 can be utilized to verify the hardware circuit 102 with few changes. As can be seen from FIG. 2, the test code 400 differs from the test code 402 in that the set up program "A" which includes syntax or specific commands required to initialize the host computer system and to instruct the host computer system to execute appropriate test suites will likely differ from the set up program "B" which includes syntax or specific commands required to initialize the hardware circuit 102 and the hardware environment 202 to execute the identical test suites. This is because any software overhead ("glue code") associated with the host computer system will no longer be required, but different overhead ("glue code") associated with the hardware circuit 102 and hardware environment 202 will be needed. Therefore, the test code 400 has a different set up file than the test code 402.
The diagnostic test suites contained within the test code 402 which provide stimulus to the hardware circuit 102 and which examine results obtained, however, can be essentially identical to the diagnostic test suites contained within the test code 400. This is advantageous because the diagnostic test suites provide a consistent and uniform means for verifying both the software model 100 and the hardware circuit 102. In other words, diagnostic test suites provide a uniform "yardstick" by which the performance of the software model 100 and the hardware circuit 102 can both be measured.
Preferably, the diagnostic test suites of the test code 400 and 402 can be run in a batch mode or in an interactive mode. In batch mode, a predefined set of diagnostic tests are performed and the results obtained. In interactive mode, a test can be halted at selected points in its operation and register activity, internal signal activity or external signal activity, can be observed and analyzed. Batch mode is generally used to ensure that the design performs properly after a change is made, while interactive mode is generally used to isolate faults. In addition, a monitor mode is preferably provided which allows specific addresses to be monitored, such as program execution addresses, to determine whether a test was failed, passed, or resulted in a hang state. Once a test has been completed, the results are obtained, compared to expected results and a pass/fail determination is made. The results will then be logged to a display and stored in a designated memory file.
In addition, specific parameters of the virtual environment 200 and of the hardware environment 202 can preferably be selectively configured before running a diagnostic test suite. The virtual environment 200 can be appropriately initialized through its set up file and the hardware environment 202 can also be configured via a similar setup file or by appropriately setting dip switches. Preferably, the virtual environment 200 and the hardware environment 202 are configured in a like manner to maintain their functional equivalence, but could be configured differently for testing purposes. The selective configuration parameters can include: assigning memory segments for particular operations, controlling a number of wait states used for access to each memory segment, controlling a system clock frequency, enabling parity checking functions, enabling direct memory access (DMA) functions, enabling random DMA requests, enabling random external interrupts, controlling cache burst refill sizes, selecting which cache burst word is to be retried, and controlling power supply voltage levels. It will be apparent that other parameters can be controlled or enabled depending upon the functions of a particular hardware circuit under design.
FIG. 3 illustrates a block schematic diagram of an exemplary hardware environment utilized to verify a design for an integrated circuit processor TR3100. The hardware environment illustrated in FIG. 3 provides capability to operate the integrated circuit processor TR3100 over its full range of functionality using the same diagnostic test suites developed for verifying a software model of the design for the integrated circuit processor TR3100.
The present invention has been described in terms of specific embodiments incorporating details to facilitate the understanding of the principles of construction and operation of the invention. Such reference herein to specific embodiments and details thereof is not intended to limit the scope of the claims appended hereto. It will be apparent to those skilled in the art that modifications may be made in the embodiment chosen for illustration without departing from the spirit and scope of the invention. Specifically, it will be apparent to one of ordinary skill in the art that the device of the present invention could be implemented in several different ways and the apparatus disclosed above is only illustrative of the preferred embodiment of the invention and is in no way a limitation.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4638246 *||Sep 21, 1984||Jan 20, 1987||Gte Laboratories Incorporated||Integrated circuit input-output diagnostic system|
|US4744084 *||Jul 8, 1987||May 10, 1988||Mentor Graphics Corporation||Hardware modeling system and method for simulating portions of electrical circuits|
|US4768196 *||Oct 28, 1986||Aug 30, 1988||Silc Technologies, Inc.||Programmable logic array|
|US4811345 *||Dec 16, 1986||Mar 7, 1989||Advanced Micro Devices, Inc.||Methods and apparatus for providing a user oriented microprocessor test interface for a complex, single chip, general purpose central processing unit|
|US4937770 *||Dec 29, 1988||Jun 26, 1990||Teradyne, Inc.||Simulation system|
|US4945503 *||Oct 21, 1987||Jul 31, 1990||Nec Corporation||Hardware simulator capable of reducing an amount of information|
|US5109353 *||Dec 2, 1988||Apr 28, 1992||Quickturn Systems, Incorporated||Apparatus for emulation of electronic hardware system|
|US5134701 *||Feb 10, 1989||Jul 28, 1992||Hewlett-Packard Co.||Test apparatus performing runtime replacement of program instructions with breakpoint instructions for processor having multiple instruction fetch capabilities|
|US5146460 *||Feb 16, 1990||Sep 8, 1992||International Business Machines||Logic simulation using a hardware accelerator together with an automated error event isolation and trace facility|
|US5235530 *||Nov 15, 1990||Aug 10, 1993||Racal-Redac, Inc.||Active cartridge display for hardware modeler|
|US5329470 *||Dec 21, 1993||Jul 12, 1994||Quickturn Systems, Inc.||Reconfigurable hardware emulation system|
|US5371878 *||Sep 9, 1993||Dec 6, 1994||Ball Corporation||System for analysis of embedded computer systems|
|US5438673 *||Aug 27, 1993||Aug 1, 1995||Cray Research, Inc.||Automatic interface for CPU real machine and logic simulator diagnostics|
|US5477475 *||Jul 11, 1994||Dec 19, 1995||Quickturn Design Systems, Inc.||Method for emulating a circuit design using an electrically reconfigurable hardware emulation apparatus|
|US5546562 *||Feb 28, 1995||Aug 13, 1996||Patel; Chandresh||Method and apparatus to emulate VLSI circuits within a logic simulator|
|1||Srivastava & Palavali, "Integration of SPICE with TEK LV511 ASIC Design Verification System," IEEE Proceedings of the 36th Midwest Symposium on Circuits and Systems, pp. 673-676, 1993.|
|2||*||Srivastava & Palavali, Integration of SPICE with TEK LV511 ASIC Design Verification System, IEEE Proceedings of the 36th Midwest Symposium on Circuits and Systems, pp. 673 676, 1993.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US6279146 *||Jun 18, 1999||Aug 21, 2001||Simutech Corporation||Apparatus and method for verifying a multi-component electronic design|
|US6564162 *||Apr 3, 2000||May 13, 2003||Hewlett-Packard Company||Method and apparatus for improving electrical verification throughput via comparison of operating-point differentiated test results|
|US6898734 *||Dec 13, 2001||May 24, 2005||International Business Machines Corporation||I/O stress test|
|US7447621 *||Sep 29, 2003||Nov 4, 2008||Sun Microsystems, Inc.||PLI-less co-simulation of ISS-based verification systems in hardware simulators|
|US7561999 *||May 25, 2004||Jul 14, 2009||Fujitsu Microelectronics Limited||Verification apparatus, verification method, and program|
|US7962620 *||Jun 13, 2008||Jun 14, 2011||Kubisys Inc.||Processing requests in virtual computing environments|
|US8346891||Jun 13, 2008||Jan 1, 2013||Kubisys Inc.||Managing entities in virtual computing environments|
|US8886758||Nov 30, 2012||Nov 11, 2014||Kubisys Inc.||Virtual computing environments|
|US9069588||Nov 30, 2012||Jun 30, 2015||Kubisys Inc.||Virtual computing environments|
|US20050102640 *||May 25, 2004||May 12, 2005||Fujitsu Limited||Verification apparatus, verification method, and program|
|WO2000041101A1 *||Jan 5, 2000||Jul 13, 2000||Evans Edward N||Apparatus and method for verifying a multi-component electronic design|
|U.S. Classification||703/9, 703/14, 703/13|
|May 16, 1997||AS||Assignment|
Owner name: SONY CORPORATION, JAPAN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:COX, STEVEN R.;CHUE, HARRY M.;REEL/FRAME:008602/0424
Effective date: 19970501
Owner name: SONY ELECTRONICS, INC., NEW JERSEY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:COX, STEVEN R.;CHUE, HARRY M.;REEL/FRAME:008602/0424
Effective date: 19970501
|May 22, 2003||FPAY||Fee payment|
Year of fee payment: 4
|May 23, 2007||FPAY||Fee payment|
Year of fee payment: 8
|Jun 27, 2011||REMI||Maintenance fee reminder mailed|
|Nov 23, 2011||LAPS||Lapse for failure to pay maintenance fees|
|Jan 10, 2012||FP||Expired due to failure to pay maintenance fee|
Effective date: 20111123