Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Target device
Reexamination Certificate
1998-04-10
2004-07-20
Jones, Hugh (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Target device
C703S013000
Reexamination Certificate
active
06766284
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of digital system design verification and production. More specifically, the present invention relates to design verification and production of digital systems whose development efforts are neither hardware nor software dominant.
2. Background Information
The majority of digital systems being designed today are task specific embedded systems that consist of standard and/or custom hardware as well as standard and/or custom software. Standard hardware typically includes off-the-shelf microprocessor/micro-controller, and memory etc., whereas custom hardware is implemented with programmable logic devices (PLDs), or Application Specific Integrated Circuits (ASICs). Hardware architecture binds and constrains these resources and provides a framework on which software processes execute. Standard software typically includes a real time operating system (RTOS), and configurable device drivers, whereas customer software is the embedded application. Software architecture defines how these processes communicate.
The complexity of these systems varies widely from low to high end depending on the market segment and product goals. They can be found in almost everything that we encounter in our daily lives, such as communication systems ranging from the phone on our desk, to the large switching centers, automobiles, consumer electronics, etc.
Some embedded systems are software dominant in their development effort, in that most of the design efforts are focused on implementing the functionality in software. Typically, standard or previously designed hardware are employed. Thus, even though the software dominant characteristic typically makes these systems a lot more cost sensitive, these systems can be readily validated by compiling and debugging the software under development on existing hardware, using a compiler, a debugger and other related software tools.
Other embedded systems are hardware dominant, in that most of the design efforts are focused on implementing the functionality in PLDs or ASICs. The original software content of these systems tends to be small. Typically, these embedded systems are found in applications where performance is critical. For these systems, hardware emulation and/or simulation techniques known in the art appear to adequately serve the design verification needs. In the case of emulation, the hardware is “realized” by configuring the reconfigurable logic and interconnect elements of the emulator. The configuration information are generated by “compiling” certain formal behavioral specification/description of the hardware. In the case of simulation, a simulation model would be developed. For the more “complex” hardware, since it is very difficult, if not outright impossible, to model all the behaviors of the hardware, certain accuracy are often sacrificed. For example, in the case of a microprocessor, it is often modeled by a “bus interface model”, i.e. only the different bus cycles that the processor can execute are modeled. The modeled bus cycles are driven in timed sequences, representative of typical bus transactions or bus activities for invoking specific conditions.
Embedded systems that are most difficult to validate are those that are neither software or hardware dominant, in that both parts play an equally important role in the success of the system. Due to increased time to market pressures, hardware and software are usually developed in parallel. Typically, the hardware designers would validate the hardware design using an hardware simulator or emulator. Concurrently, the software designer would validate the software using an instruction set simulator on a general purpose computer. The instruction set simulator simulates execution of compiled assembly/machine code for determining software correctness and performance at a gross level. These instruction set simulators often include facilitates for handling I/O data streams to simulate to a very limited degree the external hardware of the target design. Typically, instruction set simulators run at speeds of ten thousand to several hundred thousand instructions per second, based on their level of detail and the performance of the host computer that they are being run on.
Traditionally, the hardware and software would not be validated together until at least a prototype of the hardware, having sufficient amount of functionality implemented and stabilized, becomes available. The software is executed with a hardware simulator, and very often in cooperation with a hardware modeler (a semiconductor tester), against which the hardware prototype is coupled. The hardware simulator provides the hardware modeler with the values on the input pins of the prototype hardware, which in turn drives these values onto the actual input pins of the prototype hardware. The hardware modeler samples the output pins of the prototype hardware and returns these values to the hardware simulator. Typically, only one to ten instructions per second can be achieved, which is substantially slower than instruction set simulation.
Recently, increasing amounts of research effort in the industry has gone into improving hardware and software co-simulation. New communication approaches such as “message channels” implemented e.g. using UNIX® “pipes” have been employed to facilitate communication between the hardware and software models (UNIX is a registered trademark of Santa Cruz Software, Inc.). Other efforts have allowed the models to be “interconnected” through “registers”, “queues”, etc. However, even with the improved communication techniques, and employment of less complete models, such as “bus interface models” for a microprocessor, hardware and software co-simulation known in the art remain running substantially slower than instruction set simulation.
In U.S. patent application, Ser. No. 08/645,620, now U.S. Pat. No. 5,768,567 assigned to the same assignee of the present invention, an improved hardware-software co-simulator is disclosed. Under the disclosed co-simulator, co-simulation of a hardware-software system is performed with a single coherent view of the memory of the hardware-software system. This single coherent view is transparently maintained for both the hardware and software simulations, and includes at least one segment of the memory being viewed as configured for having selected portions of the segment to be statically or dynamically configured/reconfigured for either unoptimized or optimized accesses, wherein unoptimized accesses are performed through hardware simulation, and optimized accesses are performed “directly”, by-passing hardware simulation. The co-simulation may be performed with or without simulation time optimization, statically or dynamically configured/reconfigured, and optionally in accordance with a desired clock cycle ratio between hardware and software simulations, also statically or dynamically configured/reconfigured.
Additionally, the software simulation may be performed using either instruction set simulators or Host Code Execution (HCE) applications. An HCE application is a user-written program that emulates the working of embedded software. Instead of running on the embedded processor or even on an instruction set simulator, an HCE application is compiled and executed on a general purpose computer. The HCE application calls pre-supplied HCE functions to generate the hardware bus cycles for the hardware simulator.
In an ideal situation, once the HCE application has been used to verify the workings of the embedded system, the same source code can be carried to subsequent levels of verification and ultimately into the actual production of the embedded software. However, because of the use of HCE functions, it has been necessary to recode the HCE application to produce the production version. For example, consider the operation of writing a byte to a memory mapped output port at address 0x4000, the statements (in C) in the HCE version are coded as
unsigned long port=0x4000;
hce_WriteByte(‘\1
Jones Hugh
Klarquist & Sparkman, LLP
LandOfFree
Method and apparatus for generating co-simulation and... 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 generating co-simulation and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for generating co-simulation and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3241928