Data processing: structural design – modeling – simulation – and em – Emulation – In-circuit emulator
Reexamination Certificate
1998-02-17
2001-10-02
Teska, Kevin J. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Emulation
In-circuit emulator
C703S019000, C703S020000, C703S021000, C703S022000
Reexamination Certificate
active
06298320
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to testing software and hardware in embedded systems, and, more specifically, to a system and method for testing software and hardware in embedded systems in which the hardware may be wholly or partially simulated.
BACKGROUND OF THE INVENTION
The use of computer simulation has become widespread in many areas, such as circuit design. The cost of manufacturing an integrated circuit is extremely high, and it is desirable that the hardware incorporated into the integrated circuit be tested prior to the actual fabrication of the integrated circuit. To that end, integrated circuit manufacturers often use simulators to test the hardware and the software intended to be executed by the hardware. The desired hardware design is known as the “target hardware,” while the software intended to be executed by a “target processor” in the target hardware is known as the “target program.”
There are several techniques that are used to test the target hardware before the target hardware has been fabricated. One approach is to simulate the hardware using a computer hardware simulator. The hardware simulator is a software program that simulates the responses of the target hardware and is implemented entirely in software. Thus, in the hardware simulator, the target hardware, including the target processor, is simulated entirely by computer software.
Another approach uses a target processor that interfaces with a hardware emulator of the target hardware. The hardware emulator is typically implemented using reconfigurable hardware, such as field-programmable gate arrays, that can be programmed to perform the functions of the target hardware. The target program is typically executed out of a memory device used with the hardware emulator. However, in some cases the target processor may be realized using a microprocessor in a microprocessor emulator, and, in such cases, the target processor may execute the target program from memory in the microprocessor emulator. Thus, in the hardware emulator approach, the target hardware, including the target processor, is implemented entirely in hardware, although the target processor interfaces with emulated target hardware instead of the actual target hardware.
More recently, a system has been developed for testing embedded systems in which a hardware simulator is coupled to a microprocessor emulator. This system is described in U.S. patent application Ser. No. 08/566,401 by Geoffrey J Bunza, which is incorporated herein by reference. A communications interface controls communication between a memory, a microprocessor in the emulator, and the hardware simulator. The microprocessor receives target instructions from the memory and then executes the target instructions. When the microprocessor requires interaction with the target hardware, the emulator communicates with the hardware simulator so that the simulated target hardware interacts with the microprocessor. The advantages of the Bunza approach are that it is not necessary for the hardware simulator to simulate the microprocessor, thereby greatly decreasing the hardware simulation task. Further, the target code is executed at essentially normal speed until an interaction with the target hardware occurs.
Each of the above-described approaches has advantages and disadvantages. The hardware simulator is extremely slow and cumbersome, particularly when used to simulate a complex microprocessor executing a target program. Thus, testing a complete target program is impractical due to the extremely long execution times required by the typical hardware simulator. The use of an actual target processor interfacing with a hardware emulator allows a target program to be executed much faster than the hardware simulator, but it can require extensive programming of the hardware emulator to perform the functions of the target hardware. The Bunza approach solves many of the above-described problems, but it can be used only with simulated target hardware. It cannot be used to test target software and hardware where the hardware is, in whole or in part, physically present in the target system. Thus, the target system can be tested before fabrication of the target hardware has started using the Bunza approach or after fabrication of the target hardware has been completed using a conventional emulator. However, there is no satisfactory technique for allowing target software and hardware to be tested during hardware fabrication while the target hardware is only partially fabricated.
With the advent of 32-bit microprocessors and complex operating software, embedded systems have become very complex. The vast majority of electronic products built today include some form of computer hardware executing a stored software program. An embedded system may typically include a “target processor” executing instructions in a “target program” and interacting with “target hardware” which may be an application specific integrated circuit (ASIC) or a custom integrated circuit (IC).
Given the complexity and density of modem electronics designs, it is desirable that the first system prototype, including the target hardware and the target program, be close in form, fit, and function to the end product. The target hardware prototypes would therefore ideally include the final ASIC and custom IC designs. However, for the reasons explained below, it is usually not practical to prototype embedded systems in this manner.
When software engineers start work, the target hardware which will ultimately execute the target program does not exist in physical form. As explained above, various approaches have been developed to allow testing of target software as it interacts with target hardware before the target hardware has been physically realized. However, as also explained above, none of these approaches are entirely satisfactory. As a result, the physical target hardware and the target software of a target system are typically brought together for the first time when the prototype target hardware has been fabricated. Because of the prior unavailability of the physical target hardware, one often finds that the target program loaded at the time of the integration of the prototype target hardware and software does not work. It is common to find that the integration problems are strictly due to software complications alone. This may cause a significant delay in the software development due to the problems in the target program. Other problems with the integration may be caused by the interaction of the target hardware with the target program. Consequently, considering the large cost of ASIC and custom IC design, and the relatively low cost ease of software modification, it is common that the software will be force-fitted to the target hardware prototype, thereby increasing the overall planned software development time.
There is therefore a need for a system that allows a target program and target hardware for an embedded to be tested throughout the design and fabrication of the target hardware, including at the time that only a portion of the target hardware has been fabricated and is physically present in the embedded system.
SUMMARY OF THE INVENTION
The present invention is embodied in a system and method for testing embedded electronic systems that include a target processor, a memory containing a target program executed by the target processor, and target hardware, part of which may be physically present and coupled to the target processor. The testing system includes a target monitor coupled to the target processor, and a communications interface coupling the target monitor to a hardware simulator that is configured to simulate the portion of the target hardware that is not yet physically present in the embedded system. The target monitor determines when the target processor is attempting to access the simulated portion of the target hardware or the simulated portion of the target hardware is attempting to access the target processor. Upon detecting an access to the simulated target hardware, the target mon
Berger Arnold S.
Buckmaster Michael R.
Applied Microsystems Corporation
Broda Samuel
Seed IP Law Group PLLC
Teska Kevin J.
LandOfFree
System and method for testing an embedded microprocessor... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for testing an embedded microprocessor..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for testing an embedded microprocessor... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2605048