Computer-aided design and analysis of circuits and semiconductor – Nanotechnology related integrated circuit design
Reexamination Certificate
1999-06-18
2001-08-21
Smith, Matthew (Department: 2825)
Computer-aided design and analysis of circuits and semiconductor
Nanotechnology related integrated circuit design
C716S030000, C703S014000, C703S020000, C703S021000, C703S025000
Reexamination Certificate
active
06279146
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is related to an apparatus and method for performing developmental testing on a target system electronic design that includes many multi-transistor components. Such a design could be implemented as a system-on-a-chip or on a PC board.
As IC design complexity increases so does the time required to verify each design. A first step in typical current design verification methodology is to divide a design into various functional blocks, and then to design and verify each block separately. These blocks (also referred to as “components”) may be from 50 gates to 100,000 gates or more in complexity and may require computer simulation runs of between a few hours and a few days to verify the block to a first order of confidence. In the context of this application the term “component” refers to this type of block.
A great challenge is presented, however, by the necessity of verifying the performance of an entire target system that is composed of a group of these already verified blocks. Because a target system design may include several million gates, a week of computer time may be needed to simulate the entire design. Moreover, a new simulation run must be performed each time the design is changed, greatly slowing the design process. In addition, a target system simulation can only be executed when a complete circuit description in electronic file format (a “net list”) is available. In the future, it will be increasingly typical for a foundry to manufacture target systems that include some components that are proprietary to the foundry and other components that are designed by the target system designer. Typically, no net lists will be available for the foundry proprietary components.
Moreover, owners of proprietary circuit designs sometimes offer a file in an encoded, FPGA loadable format, thereby permitting implementation of the circuit design on an FPGA. Because of the encoding, however, the user is unable to derive the net list from this file. The function of such a component could not be simulated because of the unavailability of the net list.
Further complicating the process, most electronic systems today are “embedded systems” in the respect that they include both hardware and embedded software components. In the past, the dividing line was relatively simple. A microprocessor was chosen as the core of the system and this processor was then interfaced to its surrounding environment with application specific integrated circuits (ASICs) and other custom logic. This completed the basic hardware system, and a prototype board was built and used for software development. For tasks that were speed critical, some software routines could be implemented in custom hardware, but with a significant cost both in production and in development. Today, IC designers have the ability to manufacture large ICs that implement many tasks in hardware that formerly were performed by software, thus creating much faster systems. Because much of the hardware in a system-like this is designed to work with specific software, this requires that both the hardware and software be developed together. Unfortunately, software verification requires an order of magnitude more simulation patterns to verify than does hardware verification. There is currently no means of running these verification tests until a hardware prototype of the system exists, typically at the completion of hardware design. If a hardware error is uncovered during the software testing, it forces a difficult decision between a very expensive change to the finalized hardware design or a cumbersome, and perhaps slow, software work-around.
To ease the task of debugging software that resides in an embedded system, various special software tools have been developed. These packages typically include a ROM monitor component that resides in a read only memory assembly that is accessible to the microprocessor. When the microprocessor is booted it begins operation using the instructions in the ROM monitor. Another debug package component resides on a test computer that is connected to some of the pins of the microprocessor. The test computer can instruct the ROM monitor to load the software program that runs on the microcontroller with a breakpoint that causes operation to jump to the ROM monitor. The ROM monitor instructions cause the microcontroller CPU to send specified register contents out through the pins that are connected to the test computer for display to a developer. At present it is generally not possible to use this type of debug package to its fullest effect until all the hardware components are completed and an entire system is ready to be tested. Alternatively, the debug package could be used without the hardware components. This will, of course, not find problems that occur in the interaction of the software and the hardware. The early use of such a debug package would be tremendously beneficial to software developers in their efforts to debug software prior to the time when an entire system has been constructed.
In order to speed up the verification time of a target system design, various methods have been used. These generally fall into three categories: hardware modelers, emulators and simulation accelerators.
Hardware modelers address the above noted problematic situation in which a net list does not exist for one of the target system blocks. In this situation it is generally the case that a physical embodiment of the block exists in the form of an IC or a bonded out IC core (a portion of an IC that has been extracted and equipped with connector pins). A hardware modeler is designed to connect such a physical embodiment to a computer executing a simulation model (a “simulator”). Unfortunately, a single hardware modeler only connects a single physical embodiment to the simulator. Although an additional physical embodiment could be connected to the simulator by an additional hardware modeler, communications between the two physical embodiments would have to be implemented by the simulator, greatly slowing system performance. Because of this, hardware modelers generally do not greatly accelerate the simulation process for complex systems.
At least one current hardware modeler allows a user to place one or more physical components on adapter boards that are then inserted into the modeler. This modeler is also connected to a simulator. The modeler allows the designer to incorporate the components on the adapter boards into an event-driven simulation, thus obtaining an accurate model of the component without the need for a net list. Unfortunately, all connections between the physical embodiments must, nevertheless, go through the simulator. If a microprocessor is placed in the hardware modeler, it could be used to do hardware/software co-verification, except that because all communications must be routed through the simulator it is far too slow to be useful for that purpose.
One recently released product is targeted at taking a microprocessor IC or bonded out core and connecting it to an event-driven simulator, utilizing software debugging tools to allow hardware and software designers to use a real hardware model of the core processor during system design verification. The overall speed of execution of a system being designed with this product, however, will always be limited by the speed of the event-driven simulator, where the major portion of the design exists. This will be too slow for effective hardware/software simulation.
Another available product is intended to be a system level rapid prototyping solution. The product consists of a generic prototyping board that has two prototype areas with prepunched holes and no ICs attached. The prototype areas are where the customer places ICs or field programmable gate arrays (FPGAs) that represent different building blocks in an IC or printed circuit board design. All of the pins in both prototyping areas can then be routed (any pin to any pin) via a set of proprietary custom crossbar switches. These crossbar switches are programmable, so that mi
Evans Ed
Jurasek Dave
Kik Phallaka
Marger & Johnson & McCollom, P.C.
Simutech Corporation
Smith Matthew
LandOfFree
Apparatus and method for verifying a multi-component... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for verifying a multi-component..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for verifying a multi-component... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2456970