Integrated prototyping system for validating an electronic system design

An integrated prototyping system (IPS) is proposed for verifying and validating an electronic system design (ESD) with hierarchical design elements (HDEs). The IPS has: a) A reprogrammable logic device (RPLD) having an emulation timing base and an RPLD-interface for programming and simulating HDEs under validation while transacting exchanging vectors. The RPLD is also switchably coupled to numerous external peripheral electronic devices (PED), b) An EDA simulator for simulating then verifying selected HDEs while transacting exchanging vectors. The EDA simulator also has a simulator interface; and c) An IPS controller bridging the RPLD and the EDA simulator. The IPS controller has an IPS executive for progressively verifying and validating the ESD. The IPS executive further includes a co-emulation software for jointly and simultaneously running the RPLD and the EDA simulator with an event-based synchronization scheme for interchanging exchanging vectors on demand between the RPLD and the EDA simulator.

FIELD OF INVENTION

The present invention relates generally to design/validation apparatus and method for designing complex electronic circuits. In particular, the present invention is directed to a prototyping system for verifying and validating electronic circuit designs that are particularly applicable to an ultra large scale integrated circuit type electronic circuit.

BACKGROUND OF THE INVENTION

As their level of integration continues its advancement, many complex electronic logic systems can now be implemented on a single integrated circuit (IC). Such an IC, often known as “system on a chip (SoC)” or “ultra large scale integrated circuit (ULSI)” in the art, includes a number of complex components (e.g., micro-processor, digital signal processor, peripheral and memory controllers), many of which may be individually obtained as “off-the-shelf” electronic circuit designs from numerous vendors in the market. These electronic circuit designs are known as “IPs1” to those skilled in the art. The term “IP” stands for “intellectual property.” Designers of these electronic circuits provide the designs to their customers in the form of data files which are readable by popular electronic design automation (EDA) tools. The customers of these designers then integrate these “IPs” into their own circuit designs. As an IP vendor does not provide a manufactured article here—the electronic deign is typically provided as design data represented in electronic form (e.g., stored in a storage medium, such as a compact disk, or as a stream of bits downloaded from a server via the Internet)—it has become customary in the art to refer to such electronic circuit design products as “IPs”.

In U.S. Pat. No. 6,701,491 entitled “Input/output probing apparatus and input/output probing method using the same, and mixed emulation/simulation method based on it” by Yang, an interactive environment is disclosed for IC designers to emulate integrated circuits back and forth between a hardware accelerator and a software simulator. Correspondingly, memory states and logic storage node states are swapped between the accelerator and the simulator. A complete context switch is performed to create a time shared environment on the hardware accelerator so that it can be shared among multiple IC designers. In general, multiple accelerators can be interconnected to multiple simulators and multiple workstations to allow multiple designers to allow interactive operations and to shift back and forth between hardware emulation and software simulation.

A mixed emulation/simulation method is also disclosed by Yang. Here, input/output hardware probing is performed by emulation to verify correct operations. At least one semiconductor chip is used which implements an extended design verification target circuit. The extended design verification circuit includes an IOP-probing supplementary circuit in addition to the design verification target circuit. The IOP-probing supplementary circuit includes an input/output probing interface module. An input/output probing system controller generates the IOP-probing supplementary circuit for the design verification target circuit. The extended design verification target circuit is implemented in semiconductor chip(s) mounted on a prototyping board or is implemented with a hardware description language (HDL) code which defines the behavior of the IOP-probing supplementary circuit. Emulation and simulation are then performed in turn more than one time as necessary. For these emulations and simulations, state information is exchanged in an automated manner between a prototyping board and a simulator. Furthermore, the state information is exchanged in an automated manner between the prototyping board and the simulator as a result of the IOP-probing supplementary circuit-based input/output probing. With the IOP-probing supplementary circuit, another mixed emulation/simulation process is also disclosed whose operating mode is conditionally based upon a pre-determined switching condition queue ordered according to time. Simulation and emulation are performed according to the switching condition queue during the process until the queue becomes empty.

In U.S. Pat. No. 6,389,379 entitled “Coverification system and method” by Lin, et al, a coverification system and method are disclosed. The coverification system includes a reconfigurable computing system and a reconfigurable computing hardware array. The reconfigurable computing system includes a CPU and a memory for processing modeling data of the entire user design in software. In some embodiments, a target system and external I/O devices are not necessary since they can be modeled in software. In other embodiments, the target system and external I/O devices are coupled to the coverification system for speed and to use actual data, rather than simulated test bench data.

The disclosed coverification method by Lin, et al was directing at verifying the proper operation of a user design. In Lin's apparatus, the user design is connected to an external I/O device. The method involves generating a first model of the user design in software for simulation, generating a second model of at least a portion of the user design in hardware and then controlling the second model in hardware with the first model in the software. More specifically, controlling further involves synchronizing the data evaluation in the first model in software and in the second model in hardware with a software-generated clock. For debugging, the method further involves simulating selected debug test points in software, accelerating selected debug test points in hardware and controlling the delivery of data among the first model in software, the second model in hardware, and the external I/O device so that the first model in software has access to all delivered data.

In the prior art, designing, debugging, verifying and validating a system that includes a user design that is integrated with one or more third party IPs is generally difficult, as the user often starts with a behavior description or a simulation model of the IP, which provides incomplete control over the IP's logical behavior at the interfaces between the user design and the IP. In addition, a user design that includes a behavior simulation model, logic gates and embedded software is extremely difficult to create and for which to isolate system faults. For example, it is difficult to discover errors within an audio or video output data stream unless the user can “hear” or “see” the rendered audible and/or visual results. A conventional method of design verification and validation prototypes the system behavior in an electronic design automation (EDA) simulation environment to verify the numerous interface functions. Then, the user separately embodies the EDA-simulated logic into a custom application reference board-based validation environment to “hear” or “see” the audible and/or visual results. Finally, the user prototypes (implementing) the logic into packaged electronic devices to meet the product level electrical specification. During the conventional process of design verification and validation, for example, incorrectly behaving output signals of an audio or video decoder due to logic, algorithmic or software programming error of the user design may manifest themselves in the form of unpredictable audio or display behavior. For a complicated system, such an unpredictable behavior potentially caused by logic, algorithmic or software programming error is extremely difficult to diagnose and isolate in either the EDA simulation or the application reference board environment separately. Therefore, a design verification and validation system with associated software that allows the user to integrate his EDA simulator directly with his printed circuit board (PCB) prototype to quickly isolate/fix design faults, then quickly verifying and validating his PCB prototype in an integrated environment is highly desirable. In essence, such a design verification and validation system would provide the user with a high throughput, end-to-end solution from design verification to system validation.

SUMMARY OF THE INVENTION

An integrated prototyping system (IPS) allows a user to verify and validate an electronic system design (ESD) with design data represented by hierarchical design elements (HDEs). Each HDE has its corresponding test bench and the HDEs further interact with one another according to a pre-defined functional validation specification. The IPS has:a) A reprogrammable logic device (RPLD) having an emulation timing base as its operating timing base and an RPLD-interface for configuring, programming, controlling and monitoring numerous programmed HDEs under validation on the RPLD while receiving and outputting corresponding streams of exchanging vectors. The RPLD is also switchably coupled to a number of external peripheral electronic devices (PED).b) An EDA simulator for reading the design data, simulating then verifying, while receiving and outputting corresponding streams of exchanging vectors, selected HDEs in conjunction with their test benches. The EDA simulator also has a simulator interface for controlling its execution while receiving and outputting the exchanging vectors.c) An IPS controller bridging the RPLD and the EDA simulator through the RPLD-interface and the simulator interface. The IPS controller has an IPS executive for progressively verifying and validating the design data by:c1) Partitioning the ESD into already validated HDEs and a set of not yet verified HDE candidates.c2) Verifying, programming into the RPLD and validating the HDE candidates, together with their corresponding PEDs, if applicable, with the EDA simulator in conjunction with the RPLD against the functional validation specification.c3) Repeating steps c1) and c2) till all HDEs are verified, programmed and validated in the RPLD.

In a more specific embodiment, the IPS executive progressively verifies and validates the design data according to the design hierarchy of the HDEs.

In a more detailed embodiment, the above step c2) further includes:c21) Verifying the unverified HDE candidates with the EDA simulator.c22) Programming and testing the just verified HDEs on the RPLD separate from the already validated HDEs on the RPLD.c23) Combining the verified and tested HDEs with the already validated HDEs and then programming and validating the result on the RPLD.

In a more detailed embodiment, the RPLD-interface further includes a Vector Processor Interface (VPI) for communication therewith. Correspondingly, the IPS controller further includes a Vector Processor Module (VPM) having a vector processor and VPI driver software for processing exchanging vectors and communicating with both the VPI and the simulator interface. The VPI further includes RPLD configuration interface, cross trigger interface and configurable clock interface. The simulator interface further includes a computer interface for communicating with the VPM.

In a more detailed embodiment, the RPLD includes numerous interconnected field programmable gate arrays (FPGAs), each having its own FPGA attributes, for emulating numerous verified HDEs programmed in them. In another embodiment, the FPGAs form a user's application reference board (ARB). Furthermore, each FPGA has an emulation clocking module, being part of the emulation timing base, for supplying a real-time scalable frequency clock signal, which times the emulation under either one of the following modes:a) A simulator-dominate mode wherein each FPGA, while being decoupled from its associated PEDs, co-emulates selected members of HDEs in conjunction with the EDA simulator.b) An RPLD-dominate mode wherein each FPGA, while being coupled to its associated PEDs, emulates selected members of HDEs in conjunction with the EDA simulator.

For verifying and validating the HDE candidates, the IPS executive further includes a co-emulation software interacting with the VPM for jointly and simultaneously running the RPLD and the EDA simulator with no time base synchronization in between. However, an event-based synchronization scheme is adopted for interchanging exchanging vectors on demand between the RPLD and the EDA simulator and, accordingly, the vector processor further includes an event detector and a vector generator for detecting relevant events from either HDEs under verification or HDEs under validation, generating and flagging formatted exchanging vectors requested by the co-emulation software. As the emulation timing base corresponds to an emulation throughput much higher than that of the EDA simulator, the event-based synchronization scheme substantially increases the co-emulation throughput from an otherwise time base synchronization scheme.

In a more specific embodiment, the IPS further includes a co-emulation busing mechanism for data busing between HDEs under verification and HDEs under validation. Correspondingly, the co-emulation software further includes:1) Generating simulation scripts and exchanging vector acquisition scripts for the HDE candidates to be verified and validated.2) Configuring the vector processor and the VPI into proper states.3) Initializing the EDA simulator into a proper state and starting simulating the selected HDEs.4) Using the VPM and via the co-emulation busing mechanism, synchronizing exchanging vectors between the EDA simulator and the RPLD.5) Converting the exchanging vectors and storing the result in the EDA simulator for later debugging and regression tests. Converting the exchanging vectors further includes separating the exchanging vectors into emulation/simulation signal vectors, internal states, data of observation points and error alarms.

In a more specific embodiment, the FPGAs are switchably coupled to the PEDs and each FPGA is further configured to have an individual Embedded Vector Processor Interface (EVPI) interfacing with the VPI and the emulation clocking module for:a) Transceiving exchanging vectors through the EVPI itself.b) Embedding desired Verification IPs (VIPs) and observation points (OBPs) into a problematic area of the verified HDEs under validation on the RPLD to catch faults during a following co-emulation process. For this purpose, the vector processor and the EVPI further include an error annunciator.

In a more specific embodiment:a) The RPLD-interface further includes an FPGA-programming interface for receiving information that effectuates configuration and programming of the interconnected FPGAs.b) Correspondingly, the IPS executive includes an FPGA-programming utility that combines HDEs verified by the EDA simulator with HDEs validated by the RPLD into a next set of HDEs to be validated, maps it into configuration and programming information then sends the result through the FPGA-programming interface thus programs the next to be validated HDE set, together with their applicable interconnection to corresponding PEDs, into the numerous FPGAs. The FPGA-programming utility further generates, maps and sends proper configuration information through the FPGA-programming interface, thus programming the EVPI and VPI to effectuate the event-based synchronization for interchanging exchanging vectors. Additionally, while combining the verified HDEs with the validated HDEs, the FPGA-programming utility further embeds the VIPs and OBPs into an area of the HDEs to be validated.

In a more detailed embodiment, mapping the next set of HDEs to be validated into configuration and programming information by the FPGA-programming utility further includes:a) Generating a top level netlist, having an EDA simulator portion and an RPLD portion, respectively corresponding to HDE interconnections of the EDA simulator and the RPLD.b) Importing the RPLD netlist portion and partitioning it, if needed, into one or more FPGAs according to their FPGA attributes. This further involves:b1) Reading the FPGA attributes and the RPLD netlist portion.b2) Deciding, partitioning and mapping, if needed, the HDEs to be validated into the FPGAs.c) For each FPGA, reading and embedding its user specified or automatically generated VIPs, OBPs and EVPI then specifying its interconnects.d) Generating a new FPGA netlist including the individual FPGA designs.

For detecting bugs in the ESD:a) Upon encountering an exchanging vector indicating an error in the co-emulation process, the error annunciator generates an error alarm.b) The co-emulation software further includes a runtime debugger coupled to the error annunciator. Upon detecting the error alarm, the runtime debugger would intercept the exchanging vector indicating error from the VPM.

For fixing bugs in the ESD, the IPS executive further includes a debugging utility coupled to the co-emulation software and the FPGA-programming utility for:a) Extracting the exchanging vector indicating error from the runtime debugger.b) Analyzing the exchanging vector indicating error, in conjunction with stored exchanging vector data from the EDA simulator, to isolate faults at exchanging vector boundary to accelerate the validation process.c) Asserting, via the EDA simulator or via the FPGA-programming utility into the RPLD as appropriate, the VIPs and/or the OBPs into an area of the ESD to further isolate faults if needed.d) Fixing bugs in the ESD, and then using the stored exchanging vector data from the EDA simulator to qualify the associated bug fixes.

These aspects of the present invention and their numerous embodiments are further made apparent, in the remainder of the present description, to those of ordinary skill in the art.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

The description and the drawings herein focus on one or more currently preferred embodiments of the present invention and also describe some exemplary features and/or alternative embodiments. The description and drawings are presented for the purpose of illustration and, as such, are not limitations of the present invention. Thus, those of ordinary skill in the art would readily recognize variations, modifications, and alternatives within the scope of the present invention.

FIG. 1illustrates an overall top level architecture of IPS10, according to one embodiment of the present invention, for a user to verify and validate an electronic system design (ESD)20with its design data represented by hierarchical design elements (HDEs). Each HDE includes its own corresponding test bench (TBC). InFIG. 1, the HDEs and their respective associated TBCs are labeled (HDE1, TBC1), (HDE2, TBC2), . . . , (HDEj, TBCj). As part of the ESD20, the HDEs further interact with one another according to a pre-defined functional validation specification.

The IPS10includes an RPLD100with an RPLD-interface120and an EDA simulator300with a simulator interface320. The IPS10further includes an IPS controller500bridging the RPLD100and the EDA simulator300respectively through the RPLD-interface120and the simulator interface320. In many applications, the RPLD100can be part of a user's application reference board (ARB). The RPLD100has a number of FPGAs illustrated as FPGA-1101a, FPGA-2101b, . . . , FPGA-M101c. The inter-connection amongst these FPGAs are omitted here to avoid obscuring details. Under control through the RPLD-interface120, the RPLD100is further switchably coupled to numerous external peripheral electronic devices (PEDs): coupling switch-1102ato PED-1103a, coupling switch-2102bto PED-2103b, . . . , coupling switch-N102cto PED-N103c. The PEDs may be off-the-shelf components, such as microprocessor, digital signal processor (DSP), dynamic random access memory (DRAM), and hard disk drive (HDD). Each FPGA has its own attributes such as gate map, logic and memory capacity, pin counts, clock sources, etc. Following proper mapping and programming through the RPLD-interface120, the FPGAs can emulate and then validate any portion or all of the verified but not yet validated ESD20under control of the IPS controller500. Here, an HDE under validation HDE(Vd)k28bthat is part of the RPLD100is illustrated. The HDE(Vd)k28bis indicated by dashed lines to signify that its programmed physical location on the RPLD100is actually merged with the FPGAs, sometimes even distributed among a number of FPGAs. An emulation timing base of the RPLD100, being its operating timing base, will be presently described.

The EDA simulator300reads the design data of the ESD20, simulates and then verifies HDEs under verification, such as an illustrated by HDE(Vf)j26athat is part of the EDA simulator300. In general, as many pairs of HDEs under verification on the simulation side (such as the HDE(Vf)j26a) and HDEs under validation on the simulation side (such as the HDE(Vd)k28b) must dynamically interact with each other according to the ESD20, a corresponding set of interacting signals between each pair, called exchanging vectors122, must be dynamically exchanged in parallel to effect a co-emulation process with high throughput. Example signals of such exchanging vectors122include clock signals, emulation signal vector, simulation signal vector, internal states, data in the data path, data of observation points and error alarms. Hence, on the simulation side, the EDA simulator300simulates numerous HDEs under verification (like HDE(Vf)j26a) in conjunction with their test benches while simultaneously outputting and receiving exchanging vectors122to/from numerous HDEs under validation (like HDE(Vd)k28b) by the RPLD100on the emulation side. In essence, through the RPLD-interface120and the simulator interface320, the IPS controller500configures, programs, controls and monitors numerous HDEs under verification and programmed HDEs under validation while communicating streams of exchanging vectors122between them. As a side note, each test bench TBCjgenerates test vectors to test its corresponding HDE under verification or its HDE under validation, as the case may be. Thus, the simulator interface320also provides a common interface to the HDE(Vf)j26aas well as the test benches (TBC1, TBC2, . . . , TBCj).

The IPS controller500has an IPS executive502for progressively verifying and validating design data of the ESD20. As illustrated inFIG. 2, the IPS executive502follows the following steps:In step510, the IPS executive502partitions the ESD20into a set of validated HDEs and another set of HDE candidates each has not yet been verified.In step530, the IPS executive502verifies, programs into the RPLD100and validating the HDE candidates, together with their corresponding PEDs if applicable, with the EDA simulator300in conjunction with the RPLD100against the functional validation specification.Step550first checks to see if all HDEs of the ESD20have already been validated. If not the IPS executive502resumes iteration from step510. Otherwise the IPS executive502ends at END570with all HDEs verified, programmed and validated in the RPLD100.

Therefore, the IPS executive502verifies then validates the user's ESD20with a progressive, joint software/hardware co-emulation process wherein the number of HDEs to be verified progresses from a full set to zero while the number of verified and validated HDEs progresses from zero to a full set. In a preferred embodiment, the IPS executive502progressively verifies and validates the ESD20according to the design hierarchy of its HDEs.FIG. 3depicts the next level detailed process flow of step530inFIG. 2:In step534, the IPS executive502verifies the unverified HDE candidates with the EDA simulator300.In step538, the IPS executive502programs and tests the just verified HDEs on the RPLD100separate from those already validated HDEs on the RPLD100.Step542combines the just verified and tested HDEs with the already validated HDEs.Step546then programs and validates the combined result on the RPLD100.

FIG. 4illustrates the next level details of the RPLD100, the EDA simulator300and the IPS controller500including, inter alia, numerous emulation clocking modules of the RPLD100and a simulation clock310of the EDA simulator300. The emulation clocking modules include an emulation clock-1200aprogrammed into FPGA-1101a, emulation clock-2200bprogrammed into FPGA-2101b, . . . , emulation clock-M200cprogrammed into FPGA-M101c. The emulation clocking modules thus form the operating timing base for emulating various programmed HDEs under validation in the RPLD100. Notice the simulation clock310of the EDA simulator300is bordered in dashed lines. This is because a simulation clock is not always necessary for operation of the EDA simulator300. As for example, in simulating an ESD20described with a C-model the EDA simulator300does not generate a simulation clock310per se. A C-model is typically a behavior model written in the “C” programming language. However, regardless of this exception, the equivalent simulation throughput of the software based EDA simulator300is typically four-to-six orders of magnitude slower than that of a hardware based emulator such as the RPLD100. For example, under a 100 MHz emulation clock it takes a 10 ns period to process a vector but it may take 1 ms to process a vector by a simulator. In other words, the emulation clock is 100,000 times faster than the simulation clock.

The RPLD-interface120further includes a Vector Processor Interface (VPI)112coupled to the FPGAs for external communication. Correspondingly, the IPS controller500has a Vector Processor Module (VPM)504having a vector processor506and a VPI driver508software for processing the exchanging vectors122and communicating with both the VPI112and the simulator interface320. While not specifically shown here, the VPI112also includes a set of RPLD configuration interface, cross trigger interface and configurable clock interface. Thus, as programmed, the frequency of each of the emulation clocks200athrough200cis real-time scalable via the configurable clock interface of the VPI112. As the EDA simulator300operates in computer software domain while the VPM504is embodied in hardware, the simulator interface320further includes a computer-VPM interface322, for example PCI bridge, for communication with the VPM504.

For verifying and validating the HDE candidates, the IPS executive502further includes a co-emulation software503interacting with the VPM504for jointly and simultaneously running the RPLD100and the EDA simulator300with no time base synchronization between them. Instead, the co-emulation software503effects an event-based synchronization scheme for interchanging the exchanging vectors122on demand between the RPLD100and the EDA simulator300. Correspondingly, the vector processor506has a vector generator506a, a configuration interface506dand an event detector506bfor detecting relevant events from either HDEs under verification (such as HDE(Vf)j26a) or HDEs under validation (such as HDE(Vd)k28b), generating and flagging properly formatted exchanging vectors122requested by the co-emulation software503. As the throughput of the EDA simulator300is slower than that of the RPLD100, the RPLD100performs its hardware emulation at its rated emulation clocking frequency but only momentarily slows down to match the simulation throughput, and to accomplish the necessary transaction of exchanging vectors122with the EDA simulator300. In this way, the IPS10can achieve a co-emulation throughput substantially higher than an otherwise time-base synchronization scheme that is limited by the simulation clock310.

FIG. 5illustrates the next level details of the event-based synchronization scheme for transacting the exchanging vectors122on demand between the RPLD100and the EDA simulator300, including a co-emulation busing mechanism. As implied before, the FPGAs are part of the RPLD100thus are therefore switchably coupled to the PEDs. To insure that the RPLD-interface120extends into the individual FPGAs, each FPGA is further configured to have an individual Embedded Vector Processor Interface (EVPI) interfacing with the VPI112and the emulation clocking modules. Thus, FPGA-1101ahas an embedded EVPI-1106aand FPGA-M101chas an embedded EVPI-M106c, etc. The EVPIs perform the following functions:a) Transceiving exchanging vectors122.b) Embedding desired Verification IPs (VIPs) and observation points (OBPs) into selected areas of the verified HDEs under validation (such as HDE(Vd)k28b) in the individual FPGA to catch faults during a co-emulation process.

To further simplify and accelerate transaction of exchanging vectors122between the RPLD100and the EDA simulator300, the IPS10further implements a co-emulation busing mechanism for data busing between HDEs under verification (such as HDE(Vf)j26a) and HDEs under validation (such as HDE(Vd)j26band HDE(Vd)k28b). As illustrated, in one embodiment a bus bridge104acoupling the HDE(Vd)j26bis inserted in EVPI-1106aand an emulation bus104bis inserted in the RPLD-interface120directly coupling exchanging vectors122between the bus bridge104aand the event detector506b. On the simulator side, a virtual simulation bus104cis inserted coupling the HDE(Vf)j26ato the simulator interface320. The co-emulation busing mechanism allows a more direct and faster data busing between HDE(Vf)j26aand HDE(Vd)j26b. In an even more direct alternative embodiment, the exchanging vectors122can be bridged between bus bridge104aand computer-VPM interface322. Also, referring toFIG. 4andFIG. 5, the bus bridge104ais driven by emulation clock-1200a, so is the HDE(Vd)j26b. With the co-emulation busing mechanism as described,FIG. 5further illustrates an example of the event-based synchronization scheme for interchanging the exchanging vectors122. In this example, HDE(Vd)j26bconsists of a major portion of the ESD20and its coupled PED-1103aconsists of a microprocessor and memory. HDE(Vf)j26ais a decoder and is a part of the ESD20that is under verification. Thus, HDE(Vf)j26ais connected to HDE(Vd)j26bvia the co-emulation busing mechanism. HDE(Vd)j26bon the RPLD100is running at emulation clock frequency while HDE(Vf)j26aon the EDA simulator300is only running at simulation clock frequency. The inserted bus bridge104ain the EVPI-1106aacts to isolate the emulation environment and the simulation environment from each other. When the microprocessor communicates with the decoder HDE(Vf)j26a, a bus request and address command appear on the bus bridge104a. The bus bridge104athen sends a flag to the event detector506bresiding in the vector processor506and pass the flag on to HDE(Vf)j26aof the EDA simulator300. Upon the HDE(Vf)j26aresponding to the request, a bus cycle is completed. On the other hand, when the decoder HDE(Vf)j26aaccesses the co-emulation busing mechanism, the event detector506baccordingly signals the bus bridge104ato buffer the transaction and to return a requested value. Notice that when the co-emulation busing mechanism has no activities, the microprocessor and memory can be running at 100 MHz while the decoder can be only running at 10 KHz, for example. In a conventional co-emulation system where the entire design including the emulation hardware is driven by the simulation clock, the emulation hardware could only run at lower than 10 KHz in this case. Thus the overall co-emulation throughput is substantially improved by the present invention.

FIG. 6depicts the next level detailed process flow steps of the co-emulation software503.Step504agenerates simulation scripts and exchanging vector acquisition scripts for the HDE candidates to be verified and validated.Step504bconfigures the vector processor506and the VPI112into proper states.Step504cinitializes the EDA simulator300into a proper state and starts simulating the selected HDEs (such as HDE(Vf)j26a).Step504dsynchronizes, using the VPM504and via the co-emulation busing mechanism, exchanging vectors122between the EDA simulator300and the RPLD100.Step504econverts the exchanging vectors122and stores the result in the EDA simulator300for later debugging and regression tests. The conversion further includes separating the exchanging vectors122into emulation/simulation signal vectors, internal states, data of observation points and error alarms.

FIG. 7illustrates a next level detail of numerous emulation clocking modules and an FPGA-programming utility that is part of the IPS executive.

The emulation clock-1200aof FPGA-1101ais switchably coupled to the EVPI-1106avia a clock switch-1202a. Emulation clock-1200aplus clock switch-1202aform a first emulation clocking module. The clock switch-1202ais controlled by EVPI-1106a. The emulation clock-2200bof FPGA-2101bis switchably coupled to the EVPI-2106bvia a clock switch-2202b. Emulation clock-2200bplus clock switch-2202bform a second emulation clocking module. The clock switch-2202bis controlled by EVPI-2106b. Likewise, the emulation clock-M200cof FPGA-M101cis switchably coupled to the EVPI-M106cvia a clock switch-M202cthat in turn is controlled by EVPI-M106c. Emulation clock-M200cand clock switch-M202cform a third emulation clocking module. In this way, the switchable emulation clocks200a,200b,200cenable either of the following modes of co-emulation by the IPS10:a) A simulator-dominate mode wherein each FPGA, while being decoupled from its associated PEDs, co-emulates selected members of HDEs in conjunction with the EDA simulator300.b) An RPLD-dominate mode wherein each FPGA, while being coupled to its associated PEDs, emulates selected members of HDEs in conjunction with the EDA simulator300.

Regarding the above modes, it is further pointed out that in mode a) HDE(Vd)k28bis driven, through EVPI-1106aand the co-emulation busing mechanism, by a virtual simulation clock with clock cycle equivalent to the simulation clock310. However, in mode b) HDE(Vd)k28band EVPI-1106aare both driven by emulation clock-1200a. The RPLD-interface120further includes an FPGA-programming interface121for receiving information effecting a proper configuration and programming of the FPGAs101a,101b,101c. Correspondingly, the IPS executive502further includes an FPGA-programming utility502athat combines a set of HDEs verified by the EDA simulator300with a set of HDEs validated by the RPLD100into a next set of HDEs to be validated. The FPGA-programming utility502athen maps the next set into configuration and programming information and sends the result through the FPGA-programming interface121to program the next to be validated HDE set, together with their applicable interconnection to corresponding PEDs, into the FPGAs. The FPGA-programming utility502afurther generates, maps and sends proper configuration information through the FPGA-programming interface121, thus programming the EVPIs and VPI112to effect the event-based synchronization for interchanging exchanging vectors122. While combining the verified HDEs with the validated HDEs, the FPGA-programming utility502afurther embeds the VIPs and OBPs into an area of the HDEs to be validated.

FIG. 8depicts process details while the FPGA-programming utility502amaps the next set of HDEs to be validated into configuration and programming information:a) Step509agenerates a top level netlist. The top level netlist has an EDA simulator portion and an RPLD portion, respectively corresponding to HDE interconnections of the EDA simulator300and the RPLD100.b) Step509bimports the RPLD netlist portion and partitions it, if needed, into one or more FPGAs according to their FPGA attributes.c) For each FPGA, step509creads and embeds its user specified or automatically generated VIPs, OBPs and EVPI and then specifies their interconnects.d) Step509dgenerates a new FPGA netlist including all individual FPGA designs.

In the above step509b, partitioning the RPLD netlist portion into one or more FPGAs further includes:b1) Reading the FPGA attributes and the RPLD netlist portion.b2) Deciding, partitioning and mapping, if needed, the HDEs to be validated into one or more FPGAs.

FIG. 9illustrates the inclusion of a debugging utility502b, a runtime debugger503abeing part of the co-emulation software503, an error annunciator506cfor detecting and fixing bugs in the ESD20during the co-emulation process. The debugging utility502bis coupled to the co-emulation software503and the FPGA-programming utility502a. Upon encountering an exchanging vector122indicating an error in the co-emulation process, the error annunciator506cwould generate an error alarm. Upon detecting an error alarm, the runtime debugger503a, being coupled to the error annunciator506c, intercepts the exchanging vectors122indicating error from the VPM504side. Data relating to simulation vector, internal states, data path and error alarms, as isolated from the intercepted exchanging vectors122together with the VIPs and OBPs, allow the runtime debugger503ato analyze and to isolate faults of the ESD20.

FIG. 10depicts process flow steps for the debugging utility502b:a) Step505aextracts the exchanging vectors122indicating error from the runtime debugger503a.b) Step505banalyzes the exchanging vectors122indicating error, in conjunction with stored exchanging vector data from the EDA simulator300, to isolate faults at exchanging vector boundary to accelerate the validation process.c) Step505casserts, via the EDA simulator300or via the FPGA-programming utility502ainto the RPLD100as appropriate, the VIPs and/or the OBPs into a problematic area of the ESD20to further isolate faults if needed.d) Step505dfixes bugs in the ESD20and then, using the stored exchanging vector data from the EDA simulator300, qualifies the associated bug fixes.

While the description above contains many specificities, these specificities should not be constructed as accordingly limiting the scope of the present invention but as merely providing illustrations of numerous presently preferred embodiments of this invention. Throughout the description and drawings, numerous exemplary embodiments were given with reference to specific configurations. It will be appreciated by those of ordinary skill in the art that the present invention can be embodied in numerous other specific forms and those of ordinary skill in the art would be able to practice such other embodiments without undue experimentation. The scope of the present invention, for the purpose of the present patent document, is hence not limited merely to the specific exemplary embodiments of the foregoing description, but rather is indicated by the following claims. Any and all modifications that come within the meaning and range of equivalents within the claims are intended to be considered as being embraced within the spirit and scope of the present invention.