Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Software program
Reexamination Certificate
1998-03-24
2001-04-24
Teska, Kevin J. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Software program
C703S014000, C703S020000, C703S021000, C703S023000
Reexamination Certificate
active
06223144
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to a system for testing and debugging software programs for semiconductor circuits, such as microprocessors and microcontrollers, and more particularly, to a method and apparatus for simulating and emulating microcontroller software programs.
BACKGROUND OF THE INVENTION
The design, testing and fabrication of semiconductor circuits, such as microprocessors and microcontrollers, is often an expensive and time-consuming process. Several types of computer aided design (CAD) tools have been developed or proposed to facilitate the design and fabrication of integrated circuits. Typically, computer aided design techniques initially encode the specifications of a desired integrated circuit using a hardware description language, such as the (VHSIC (Very High Speed Integrated Circuits) Hardware Description Language) (VHDL) from the Institute of Electrical and Electronics Engineers (IEEE) of New York, N.Y. or Verilog, commercially available from Cadence Design Systems, Inc. of Santa Clara, Calif. Generally, such high definition language specifications define an integrated circuit in terms of desired functionality and desired inputs and outputs. The high definition language specifications are utilized and revised throughout the design and debugging process to minimize hardware faults, and are ultimately utilized to fabricate the final silicon product.
Likewise, the software programs associated with semiconductor circuits, such as microprocessors and microcontrollers, must be similarly tested and debugged to ensure that software faults do not interfere with the operation of the semiconductor circuit. In addition, each change to an existing software program must be tested to ensure that the change does not affect the operation of the original code. In view of the high development costs associated with the semiconductor manufacturing process, it is imperative that software faults are detected and corrected early in the development cycle. Due to the high costs of fabricating special versions of a semiconductor circuit that are needed for internal access to the device, software debugging devices are costly and typically lag production of the final silicon product by a number of years. Thus, conventional testing and debugging techniques for such software programs are typically performed on simulated or emulated hardware renderings of the actual silicon device.
FIG. 1A
shows a conventional development environment for testing software programs associated with a semiconductor circuit. The program to be tested is initially loaded onto a computing device
50
, such as a workstation, connected to an emulator
60
and a bondout device
70
. The bondout device
70
is a special version of the actual integrated circuit being designed, where additional connections are made (bonded out) to internal circuits of the device to give access and control of the device from external circuitry (not shown). The computing device
50
controls the predetermined testing of the system. The emulator
60
includes capture and control logic which monitors the contents of the program address register and the internal data bus and various control lines of the bondout device
70
and provides the captured data to the computing device
50
for analysis. The bondout device
70
is typically physically connected to the device with which the microcontroller will ultimately interface. For a more detailed discussion of a conventional development environment for testing software programs associated with a semiconductor circuit, see U.S. Pat. No. 4,674,089, incorporated by reference herein.
A unique bondout device
70
is required for each type of microprocessor that is developed. Furthermore, if the speed of operation of the microprocessor is changed or the size of the memory is modified during the development process, a new bondout device
70
is required. Thus, software for a particular microprocessor cannot be fully tested using conventional techniques until an accurate and up-to-date bondout device
70
representation of the microcontroller is available. The hardware external to the bondout device
70
rapidly becomes very complex as additional debugging features are added. Thus, a significant amount of hardware must be plugged into a target board, with resultant mechanical and electrical unreliability. The bondout device
70
itself introduces problems since it is a low volume device (one per emulator). By definition, the bondout device
70
is a more complex derivative of the volume silicon and its availability significantly lags production of the final silicon product. Any errors or undesired characteristics of this low volume part are expensive to diagnose and eradicate, typically requiring production of a new device.
When software programs are delivered to a customer, the probability that the customer will find a bug in the program is directly related to the percentage of the code that was executed during testing, often referred to as “code coverage.” For example, testing of a scientific calculator program by adding “two” plus “two” (“2 +2”) will not evaluate the accuracy of the floating point or trigonometric capabilities of the scientific calculator program. However, if every possibility was tested exhaustively, the customer will never find a bug. Of course, to perform a test that multiplies every possible number by every other possible number and checks the result is not a practical solution.
Generally, the test suite designed to challenge a given program should exercise as much of the program code as possible. Ideally, every byte of program code should be run, and the result checked. Furthermore, the extent of the code tested, relative to the overall code size, should be determined and reported.
Existing code coverage instrumentation techniques have a number of drawbacks, which if overcome, could extend the utility of software testing tools and the accuracy of the underlying programs tested by such tools. Specifically, existing coverage instrumentation tools typically link the program being tested to a special coverage library, thereby increasing code size, preventing execution in real-time and not testing the actual code shipped. In effect, the test results are obtained from a program that is larger, slower and potentially exhibits different behavior than the program that will be released to customers. In addition, most existing coverage instrumentation tools operate by evaluating the source code, and cannot give test results that include coverage of the library files associated with the source code, such as C Standard Libraries (for which source code is generally not available). Finally, most existing coverage instrumentation tools are poorly integrated with the source code, and issue only partial diagrams illustrating unexecuted paths, rather than directly relating the results to the source code.
In addition to the importance of diligent testing of the software, it is often equally important to record information about the tests performed, as well as the test results, for documentation, verification and authentication purposes. Historically, the disparate and often incompatible software testing and debugging systems often made it difficult to integrate the test information into a standard documentation, verification and authentication environment. In addition, conventional software testing and debugging systems are typically stand-alone units tailored to a particular application. Thus, the lack of a standard interface prevents a user from controlling the testing and debugging processes from another application program.
As apparent from the above-described deficiencies with conventional systems for testing and debugging software for microcontrollers, a need exists for a low cost system for testing and debugging software by a programmer at compile time. A further need exists for a testing and debugging system that accurately reports the amount of time it took to execute the software program, taking into account hardware configurations and peripheral
Barnett Philip
Green Andy
Advanced Technology & Materials Inc.
Broda Samuel
Ryan & Mason & Lewis, LLP
Teska Kevin J.
Zitzmann Oliver A.
LandOfFree
Method and apparatus for evaluating software programs for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for evaluating software programs for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for evaluating software programs for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2450588