JP2006338144A - Emulation system of processor base - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a processor-based emulation system for emulating integrated circuit design including an emulation circuit and a capturing circuit. <P>SOLUTION: A capturing circuit is able to capture a processing result from an emulation circuit. The captured processing result is available for deciding any functional error in an integrated circuit design. The processor-based emulation system includes a capturing circuit, and the emulation circuit is not used for capturing the processing result. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

Related applications

  This application claims priority to US Provisional Application No. 60/576123, filed June 1, 2004. The priority to this provisional application is expressly claimed, and the disclosure of the provisional application is hereby incorporated by reference in its entirety.

  The disclosure herein relates to a processor-based emulation system, and more particularly to a processor-based emulation system having dedicated capture circuitry. The present invention also relates to a visualization method for a processor-based emulation system.

Hardware emulation systems are designed to verify electronic circuit designs before assembling them as chips or printed circuit boards. A typical emulation system uses a programmable logic chip or a programmably interconnected processor chip interconnected by a programmable interconnect chip.
In programmable logic chip (eg, field programmable gate array, FPGA) based emulation systems, user design (often “design to be verified” (“DUV”) or “design to be tested” (“DUT”)) The logic contained in the logic chip is programmed in the logic chip so that the logic implemented in the DUV takes the actual form of operation in the programmable logic device.
In a processor-based emulation system, a user design is processed as its functionality is generated in the processor by calculating the output of the design. The logic itself is not implemented in a processor-based emulation system. This means that the DUV does not take the actual form of operation within the processor. However, the processor output is equal to the logic output in the actual device.
Examples of hardware logic emulation systems using programmable logic devices can be found, for example, in US Pat. Nos. 5,093,353, 5,036,473, 5,475,830, and 5,960,191. U.S. Pat. Nos. 5,093,353, 5,036,473, 5,475,830 and 5,960,191 are hereby incorporated by reference.
Examples of hardware logic emulation systems that use processor chips are disclosed, for example, in US Pat. Nos. 5,510,013, 6,035,117 and 6,510,030. U.S. Pat. Nos. 5,510,003, 6,035,117 and 6,510,030 are incorporated herein by reference.
US Pat. No. 5,093,353 US Pat. No. 5,036,473 US Pat. No. 5,475,830 US Pat. No. 5,960,191 US Pat. No. 5,551,003 US Pat. No. 6,035,117 US Pat. No. 6,051,030

Visualization, also called tracing, is an important feature in processor-based emulation systems. Visualization is the ability to let the user capture and observe the state of the elements in the emulated design.
The ability to observe the state (ie processor output) of all nodes in a particular integrated circuit design, which Cadence Design Systems calls “Full-Vision”, is very important for functional verification systems. It is a feature. Full-vision is necessary over a period of time, i.e. many clock cycles. By capturing the internal state of the node during emulation, the user can observe behavior within the emulated design, thereby debugging the design. Without the ability to observe the internal state of the node during emulation, it is very difficult for the user to understand the cause of the bug (defect) in the design.

Typically, full-vision is achieved by capturing strategic parts of the nodes in the system. These outputs are then used to calculate values for other nodes in the system. This allows the user to observe the behavior on all nodes of the design. Some values are physical extracted values (samples), and other values are derived from calculations.
This strategic extraction technique is advantageous because it allows the user to observe behavior on any node in the system, while not requiring a circuit to capture all the nodes in the system. .

A typical processor-based emulation system uses emulation resources to capture the state of elements in the design. An emulation resource is a circuit that is used to emulate an integrated circuit design (eg, an emulation processor) to be tested.
The amount of emulation resources needed to capture the internal state of the design is not a trivial amount. For example, about 20% of emulation resources are used to achieve full-vision. Even when full-vision is not required, a significant amount of emulation resources must be used to capture the internal state of the design.
Similarly, a significant amount of memory resources available for emulation are used to capture the internal state of the design.
Thus, the user must exchange between using processor resources and using memory resources to perform the emulation or capture function.

  State acquisition is another important feature in processor-based emulation systems. State acquisition allows the user to capture data at “interesting” time points while ignoring data from other times based on triggers. A trigger is a preset event that starts capturing data. State acquisition also provides an efficient way to use available capture resources in the system.

  Also, a typical processor-based emulation system uses emulation resources for state acquisition. In particular, the emulation resource is used to store data output from the emulation processor until the trigger state is calculated. Data output from the emulation processor must usually be stored because the data is available before the trigger state is calculated.

  Accordingly, there is a need for an improved method and apparatus for capturing data generated by a processor-based emulation system.

Overview

The various embodiments disclosed herein provide an improved processor-based emulation system. The emulation system includes an emulation engine having an emulation processor, dedicated capture resources, and memory.
A dedicated capture resource is used to capture the data generated by the emulation processor and supply the captured data to the memory. The user can then examine the captured data in the memory to assist in debugging the integrated circuit design.
By providing a dedicated capture resource, the emulation processor is not used for data capture. This allows larger integrated circuit designs to be emulated within a defined emulation engine.

  The foregoing and other preferred features and advantages of various embodiments disclosed herein, including various inventive details of combinations of devices and elements, will be more fully described with reference to the accompanying drawings. As well as in the claims. It will be understood that the particular methods and circuits are shown by way of example only and not by way of limitation. As will be appreciated by those skilled in the art, the principles and features disclosed herein can be implemented in various and many embodiments without departing from the inventive concept.

Detailed Description of the Invention

  Embodiments of the present invention will be described with reference to the drawings.

An example of a processor-based emulation system 100 is shown in FIG. The processor-based emulation system 100 allows the integrated circuit design to be tested in the intended target system before the integrated circuit design is actually implemented in the integrated circuit.
The processor-based emulation system 100 includes a host computer 102 and an emulation engine 104 that is sequentially connected to a target system 106. Host computer 102 and emulation engine 104 communicate with each other via communication link 108. Emulation engine 104 and target system 106 communicate with each other via communication link 110.
The communication link may be any type of link capable of transferring data, such as an electrical, optical or wireless communication link. The host computer 102 may be any type of computer that can communicate with the emulation engine 104. The emulation engine 104 emulates the functionality of the integrated circuit design, as will be described in detail below, and allows the user to observe how the integrated circuit design operates within the target system 106.

  Target system 106 typically includes a number of devices 112, such as memory, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and the like. Target system 106 also includes an input / output 114. Input / output 114 corresponds to the input and output of the emulated integrated circuit and is in electrical communication with communication link 110.

To emulate an integrated circuit design, a user first generates an integrated circuit design that is typically completed using integrated circuit design software. User design is sometimes referred to as “design for inspection” (“DUT”) or “design for verification” (“DUV”). The integrated circuit design software runs on the host computer 101 or another computer.
When the user completes the integrated circuit design, the design is compiled into a data format that is compatible with the emulation engine 104.
The compiled design is then loaded into the emulation engine 104 via the host computer 102. An emulation engine 104 that emulates the integrated circuit design then operates with the target system 106 to determine whether the integrated circuit design operates properly within the target system 106. When connected to the target system 106, integrated circuit design inputs and outputs pass through the communication link 110 through the inputs / outputs 114 in the target system 106.

  By examining and functionally verifying the integrated circuit design using the processor-based emulation system 100, significant time and expense can be saved when there is a functional error in the integrated circuit design. This is because, generally, functional errors in an integrated circuit design can be verified and determined before the integrated circuit design is implemented in an actual integrated circuit device.

  To verify functional errors in the integrated circuit design, the emulation system captures debug information (ie, information about the internal state of the integrated circuit design) during emulation. Once captured, this information is transferred to the host computer 102 via the communication link 108. Then, using the host computer 102, the user can observe debug information and use this information to confirm and determine functional errors in the design.

FIG. 2 shows a typical processor-based emulation engine 200. A typical processor-based emulation engine can be implemented in a processor-based emulation system, such as the processor-based emulation system 100 shown in FIG.
A typical processor-based emulation engine 200 includes a processor system 202 and a memory 204. The processor system 202 typically includes a number of emulation processors (not shown) and other logic (not shown).
Communication link 210 is used to transfer emulation data and trace data from emulation processor 202 to memory 204. Communication link 212 is used to transfer emulation address signals and trace address signals from emulation processor 202 to memory 204. Similarly, the communication link 214 is used to transfer emulation control signals and trace control signals from the emulation processor 202 to the memory 204.

In a typical processor-based emulation engine, such as emulation engine 200, the emulation processor in processor system 202 is used to emulate an integrated circuit design. However, the emulation processor is also used to capture the internal state of the integrated circuit design during emulation.
As previously mentioned, it is not desirable to use an emulation processor to capture the internal state of the design, as it significantly reduces the amount of emulation resources available for emulation.
This limits the size of integrated circuit designs that can be emulated within a defined size emulation engine. This is very disadvantageous because integrated circuit designs are constantly becoming larger and more complex. Thus, the emulation processor is preferably used to perform Boolean logic in the design rather than to the capture circuit.

FIG. 3 illustrates a processor-based emulation engine 300 corresponding to the various embodiments disclosed herein. The processor-based emulation engine 300 can be implemented in a processor-based emulation system, such as the processor-based emulation system 100 shown in FIG.
The processor-based emulation engine 300 includes a processor system 302, memory 304 and capture resources 306. The processor system 302 includes many emulation processors (not shown). An emulation processor is a special circuit designed to emulate an integrated circuit design.
Capture resource 306 allows processor-based emulation engine 300 to overcome the disadvantages of the general processor-based emulation engine described above.
The processor system 302, capture resources 306, and memory 304 are preferably manufactured on the same integrated circuit or on a common substrate or backplane.

  Capture resource 306 is used to capture data generated by the emulation processor in processor system 302 and transfer the captured data to memory 304. Capture resources 306 are not used to emulate an integrated circuit design. Since capture resources 306 are not used to emulate an integrated circuit design, the emulation processor in processor system 302 can only be used to emulate the functionality of the integrated circuit design. This allows larger and more complex integrated circuit designs to be emulated within a defined size emulation engine.

  Emulation data and trace data are transferred between the processor 302 and the capture resource 306 via the communication link 310, and are transferred between the capture resource 306 and the memory 304 via the communication link 311. The emulation address signal and the trace address signal are transferred between the processor 302 and the capture resource 306 via the communication link 312, and are transferred between the capture resource 306 and the memory 304 via the communication link 313. Emulation control signals and trace control signals are transferred between the processor 302 and the capture resource 306 via the communication link 314, and are transferred between the capture resource 306 and the memory 304 via the communication link 315.

  Capture resource 306 captures the output of the selected emulation processor in processor system 302. The amount of data captured varies according to the user's request. For example, if the user only needs limited visibility into the design, the capture resource 306 can capture a limited amount of data and supply that data to the memory 304. The capture resource 306 can also capture data based on a trigger, that is, capture data when one or more predetermined conditions occur.

FIG. 4A shows an exemplary processor-based emulation engine 400. The processor-based emulation engine 400 can be implemented in a processor-based emulation system, such as the processor-based emulation system 100 shown in FIG.
The emulation engine 400 includes a processing system 402, a trace array 404, a memory 406, trace logic 408, RAM control logic 410, and multiplexers 412 and 414.
The processing system 402 includes a plurality of processor clusters 416. The processor cluster 16 is a special circuit designed to execute a Boolean type and includes many emulation processors (see FIG. 4B). In the illustrated embodiment, each processor cluster 416 includes eight emulation processors. Processor clusters 416 can transfer data to each other via communication link 417.
The memory 406 can be disposed on the same integrated circuit as the other components in the processor-based emulation engine 400, or can have one or more separate integrated circuit devices.

Emulation data, ie, data generated by the emulation processor when performing a user design, is transferred between processing system 402 and multiplexer 412 via communication link 421.
Trace data is transferred between processing system 402 and trace array 404 via communication link 422. Each communication link 422 provides a dedicated connection between a special processor cluster 416 and the trace array 404. Trace data is transferred between trace array 404 and multiplexer 412 via communication link 423.
The emulation data or trace data is transferred between the multiplexer 412 and the memory 406 via the communication line 425 according to the value of the selection signal 424.

Emulation address signals are transferred between processing system 402 and multiplexer 414 via communication link 426.
The trigger signal is transferred between processing system 402 and trace logic 408 via communication link 427.
The trace address signal is transferred between the RAM control logic 410 and the multiplexer 414 via the communication link 428.
The emulation address signal or the trace address signal is transferred between the multiplexer 414 and the memory 406 via the communication link 429 according to the value of the selection signal 424.

Emulation control signals are transferred between processing system 402 and RAM control logic 410 via communication link 430.
Trace control signals are transferred between trace logic 408 and RAM control logic 410 via communication link 431.
RAM control signals are transferred between RAM control logic 410 and memory 406 via communication link 432.

FIG. 4B illustrates an example processor cluster 416 for use with the embodiments disclosed herein.
The processor cluster 416 includes eight emulation processors 450, a data stack 452, multiplexers 454 and 456, and capture registers 458 and 460.
Emulation processor 450 and data stack 452 act as emulation resources that are used only to emulate an integrated circuit design. That is, they are not used to capture the internal state of the integrated circuit design during emulation.
In contrast, multiplexers 454 and 456 and capture registers 458 and 460 serve as capture resources for capturing the internal state of the integrated circuit design during emulation. That is, they are not used to emulate an integrated circuit design.
The processor cluster 416 can be implemented in a single integrated circuit. For example, a single integrated circuit can include 96 processor clusters with 8 processors per cluster.

Each emulation processor 450 receives four input bits via communication link 470. Each emulation processor outputs 1-bit data, which outputs 1-bit data that is supplied to the data stack 452 via an 8-bit communication link 471. Similarly, the 1-bit output of the emulation processor is supplied to the data stack 452 via the 8-bit communication link 472 from one or more other processor clusters (not shown). The 32-bit output of data stack 452 is forwarded to multiplexers 454 and 456 via 32-bit communication link 473.
Multiplexer 454 selects one of the 32 input bits in response to the value of select signal 476 and provides the selected bit to register 458 via 1-bit communication link 474. Similarly, multiplexer 456 selects one of the 32 input bits in response to the value of select signal 477 and provides the selected bit to register 460 via 1-bit communication link 475. The selection signals 476 and 477 are independent. Thereby, 2 bits out of 32 bits can be supplied to the registers 458 and 460.
As described in detail below, the data captured by registers 458 and 460 is trace data that can be used to determine the internal state of the integrated circuit design. Trace data is transferred between the processor cluster 416 and the trace array 404 (FIG. 4A) via a 2-bit communication link 422.

For further details regarding processor clusters such as processor cluster 416 and emulation within processor clusters such as emulation processor 450, see US Pat. Nos. 6,618,698 and Beausolil et al. Is disclosed. Both of these are incorporated herein by reference.
By placing emulation processors in a cluster, the processors in each cluster distribute common emulation resources (eg, input and data stacks). This improves mutual communication and increases the efficiency and speed of emulation as described in US Pat. No. 6,618,698.

The operation of emulation engine 400 and processor cluster 416 is described with reference to FIGS. 4A and 4B.
After the user completes the integrated circuit design, the user compiles the design using host computer 102 (FIG. 1) or special computer software running on another computer. The compiled integrated circuit design is then loaded into the emulation processor 450 in the emulation engine 400.
Unlike typical emulation engines, it is important to know that the capture logic is not built into the compiled integrated circuit design and is therefore not loaded into the emulation processor 450. Thus, the emulation processor 450 is used only to execute logic within the integrated circuit design, and larger and more complex integrated circuit designs are emulated within the emulation engine 400 of a defined size. It becomes possible.

An integrated circuit design is emulated by sequentially executing a predetermined number of steps (eg, 256), referred to as the main cycle. Each main cycle corresponds to a single clock cycle of the operating environment (eg, a clock cycle in the target system). Each step corresponds to a clock cycle within the emulated integrated circuit design.
Referring to FIG. 4B, 4 bits are provided to the input of each emulation processor 450 during each emulation step. Although the connection is not shown, the 4-bit input to each emulation processor 450 can be selected from some of the 32-bit outputs from the data stack 452. Each emulation processor 450 performs a logic function (eg, AND, OR, XOR, NOT, NOR, NAND, etc.) or memory access function based on the values of the four input bits. Each emulation processor 450 outputs a 1-bit result corresponding to the result of logic or memory operation.
The 1-bit output of the eight emulation processors 450 in the processor cluster 416 is written to the data stack 452 of the processor cluster via the communication link 471.
In addition, the 1-bit output of the emulation processor from one or more other processor clusters (not shown) is written to the data stack 452 via the 8-bit communication link 472.

The data stack 452 is 16 bits wide and 160 steps deep, and therefore can store 2560 bits of data.
The first 8 bits of data stack 452 are used to store the 1-bit output of 8 local emulation processors 450. The second 8 bits are also used to store the 8 1-bit outputs of the emulation processor from one or more other processor clusters (not shown). This stores 16 bits in the data stack 452 for each step in the emulation.

The internal state of the integrated circuit design can be captured at each emulation step (equal to the emulation engine clock cycle) using capture resources within each processor cluster 416. In particular, selection logic (not shown) selects 32 of the 2560 bits in data stack 452 and provides these bits to multiplexers 454 and 456 via communication link 473.
The multiplexer 454 selects one bit out of 32 bits according to the value of the selection signal 476. That bit is stored in register 458. Similarly, the multiplexer 456 selects one bit out of 32 bits according to the value of the selection signal 477. That bit is stored in register 460. The two accumulated bits are then provided to trace array 404 via communication link 422.

It is important to recognize that the emulation engine 400 can capture 25% of the output of the emulation processor 450 (two of the eight outputs) during each emulation step. Analysis has shown that full-vision can be performed by capturing approximately 20% of the output of the emulation processor 450. Thus, the emulation engine 400 provides full-vision capabilities.
Further, the emulation engine 400 provides full-vision capabilities without using emulation resources (eg, the emulation processor 450) because the emulation engine 400 includes dedicated capture resources.

As shown in FIG. 4A, either emulation data or trace data can be supplied to the memory 406. The user can read emulation data or trace data stored in the memory 406 via the host computer 102.
The emulation data is stored in the memory 406 as follows.
Emulation data generated by the emulation processor 450 in the processing system 402 is provided to the multiplexer 412 via the communication link 421. The selection signal 424 selects the emulation data input. Then, the multiplexer 412 supplies the emulation data to the memory 406 via the communication link 425 and stores it.
At the same time, processing system 402 provides an emulation address signal to multiplexer 414 via communication link 426. A selection signal 424 selects an emulation address input. The multiplexer 414 then supplies the emulation address signal to the memory 406 via the communication link 429.
Processing system 402 also provides emulation control signals to RAM control logic 410 via communication link 430. The RAM control logic 410 sequentially provides RAM control signals to the memory 406 via the communication link 432.

The trace data is stored in the memory 406 as follows.
Trace data is provided to trace array 404 via a 2-bit communication link 422. The trace array 404 is a memory device that temporarily stores trace data during the calculation of the trigger state. The trace array 404 is, for example, a FIFO (first in-first out) memory device. Trace array 404 is a dedicated capture resource and is not used for emulating integrated circuit designs.
If trace array 404 is not available, emulation resources such as emulation processor 450 must be used to temporarily store trace data during the calculation of the trigger state.
The trigger state determines whether trace data is stored in the memory 406 or whether the trace data is discarded. Although a trigger state is necessary to determine whether to capture trace data, an evaluation of that state comes after the data stored in memory 406 is available to trace array 404. . This delay in the evaluation of the trigger is due to the fact that the trigger uses signals coming from a remote location, including other chips or boards in the emulation engine.
Trace data is stored in a trace array 404, which is a dedicated capture resource, but the trigger state is calculated using emulation resources.

When the trigger state is valid, the trace data stored in the trace array 404 is written into the memory 406. To complete this, select signal 424 selects the trace data input to multiplexer 412 and the trace address signal to multiplexer 414. Appropriate trace address signals and trace control signals are then generated and provided to the memory via communication links 429 and 432, respectively.
When operating in full-vision mode, the trigger state is always valid and all trace data is stored in the memory 406.

  The RAM address and RAM control lines are generated by special logic (not shown) within the processing system 402. The RAM address and RAM control lines are distributed between capture use and emulation use because the memory 406 itself is used to store capture data and emulation data. When operating in capture mode, the address and control signals are generated with dedicated capture resources and therefore no emulation resources are used.

  In some embodiments, the memory 406 is a DRAM. At the beginning of the emulation cycle, the DRAM 406 can be set to burst mode. Although in burst mode, trace data can be written to the DRAM at every step in the emulation cycle. At the end of the emulation cycle, DRAM 406 is released from burst mode and can be refreshed.

Those skilled in the art will recognize that the emulation engine 400 offers many benefits over a typical emulation engine.
First, using a dedicated resource for capturing trace data means that tracing can be performed faster than when using emulation resources. The fact that these capture resources can be selected not only from the output of other processors, but also from the output of the local processor cluster over several steps ago, improves the efficiency. Also, activating trace does not affect the number of processors available for emulation purposes. Although the memory is still distributed, the number of memories can be increased so that the user has memory available even in full-vision mode. By using a trace array for state acquisition, a great deal of emulation resources are saved. The fact that there is no need to accumulate trace data using the emulation processor while waiting for the result of the trigger state calculation means that these processors can be used as emulation resources.

  Second, the emulation engine 400 allows different data to be captured without having to modify the emulated design. The user can capture different data by using different values for the selection signals 476 and 477. In a typical processor-based emulation system, the design needs to be recompiled as the captured data changes. This is because the data that needs to be stored needs to be redirected to the correct emulation processor, and the logical functions that are executed in that emulation processor must be transferred to other emulation processors. is there.

  Finally, the emulation engine 400 can be used to achieve full-vision in very large scale emulation systems that are very difficult to achieve in practice. For example, a large emulation system under development by Cadence Design Systems includes a total of 884736 emulation processors, which is equivalent to approximately 256 million ASIC gates. The emulation processor in this system operates at approximately 200 MHz. By using an embodiment similar to that disclosed herein, the emulation system can capture approximately 25% of all processor outputs, which is 221184 bits per clock at 200 MHz. To capture this data, the emulation system uses many common RAM chips, each running at 400 MHz (ie, twice as fast as a 200 MHz emulation processor clock). Each RAM chip can capture 64 bits per emulation clock cycle. Thus, a total of 3456 RAM chips are used to capture the 221184-bit output from the processor.

The bandwidth (bits per second) of this system is equal to 44 torrons (10 ¹² ) bits / second (ie 211184 bits × 200 MHz). Furthermore, the depth of the memory used in this system is 2M. This means that the emulation system has the ability to capture a total of 450 virion (10 ⁹ ) bits of data. As those skilled in the art will appreciate, the amount of data that can be captured by this emulation system is very large, and the ability to achieve full vision within a large emulation system is an important technical achievement.

Those skilled in the art will recognize that many modifications can be made to the emulation engine 400. As described above, the emulation engine 400 can capture 25% of the emulation processor output. Thus, the emulation engine can perform full-vision since approximately 20% of the output of the emulation processor needs to be captured to achieve full-vision.
However, the emulation engine 400 can be easily modified to capture other data if necessary. For example, the number of captured bits can be increased and / or the depth of the data stack 452 can be increased. If more output bits are captured, less computation is required to achieve full-vision, potentially increasing the speed of the system.
Modifications can also be made so that capture registers 458 and 460 operate at an increased rate that allows more data to be captured without increasing the amount of circuitry used to capture the data. It is.
Trace array 404 can also be used to capture trace data in a more sophisticated manner. For example, the trace array 404 can capture the amount of emulation processor output required for full-vision, but not during every step of emulation.
By using a trigger, only an arbitrary step can be captured. This provides full-vision only on “interesting” cycles.
Emulation engine 400 can also be modified so that emulation stops and capture resources are used to dump all data stacks 452 in emulation engine 400 into memory 406. This provides the user with the output of all single processors in the chip for the last few cycles. This is not only the value needed for things like full-vision, but also all intermediate values that give the user design visibility without having to regenerate any processor output values. Contains.

  Those skilled in the art will also recognize that the embodiments disclosed herein are applicable to emulation engines and simulation accelerators. Since the underlying technology in both is the use of a processor, the embodiments disclosed herein are beneficial for both applications.

  Various inventive concepts have been described with reference to the specific embodiments described above. It will be apparent, however, that various modifications and changes can be made thereto without departing from the broader spirit and scope of the inventive concepts disclosed herein. For example, readers may note that the particular order or combination of processor behaviors disclosed herein is merely an example, and the inventive concept is for different or additional processing behaviors, different combinations or orders of processing behaviors. It should be understood that it is feasible to use. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense, and the inventive concept is not limited or restricted except as it corresponds to the claims and their legal equivalents.

1 illustrates an example of a processor-based emulation system. An example of a general processor-based emulation engine is shown. 2 illustrates an example of a processor-based emulation engine corresponding to the embodiments disclosed herein. 2 illustrates an example of a processor-based emulation engine corresponding to the embodiments disclosed herein. 2 shows an example of a processor cluster corresponding to the embodiment disclosed in the present specification.

Explanation of symbols

102 Host computer 104, 200, 300, 400 Emulation engine 106 Target system 202, 302 Processor system 204, 304, 406 Memory 306 Capture resource 402 Processing system 404 Trace array 408 Trace logic 410 RAM control logic 412, 414, 454, 456 Multiplexer 416 processor cluster 450 emulation processor 452 data stack 458, 460 registers

Claims (18)

A system for emulating an integrated circuit design,
Multiple processor clusters to emulate an integrated circuit design;
A capture circuit for capturing data during emulation of an integrated circuit design;
A memory for storing captured data;
Each processor cluster is in electrical communication with the capture circuit, and the capture circuit is in electrical communication with the memory.   The system of claim 1, wherein the memory is a random access memory.   2. The system of claim 1, wherein each processor cluster includes a plurality of processors designed to emulate an integrated circuit design. The system of claim 1, wherein each processor cluster is
Multiple processors,
A data stack that is in electrical communication with a plurality of processors is included. The system of claim 1, wherein each processor cluster is
Multiple processors,
A data stack capable of electrical communication with multiple processors;
A plurality of multiplexers that are in electrical communication with the data stack are included. The system of claim 1, wherein each processor cluster is
Multiple processors,
A data stack capable of electrical communication with multiple processors;
A plurality of multiplexers in electrical communication with the data stack;
A plurality of registers that are in electrical communication with the plurality of multiplexers are included.   The system of claim 1, wherein the processor clusters are capable of transferring data to each other via a communication link.   2. The system of claim 1, wherein the capture circuit includes a FIFO (first in-first out) memory.   The system of claim 1, wherein the processor cluster and capture circuit are implemented in a single integrated circuit. A processor-based emulation system,
A plurality of processor clusters having a plurality of emulation processors executing logic from an integrated circuit design;
A capture circuit operable to capture data generated by the processor cluster during emulation of the integrated circuit design;
Each processor cluster has a dedicated connection to the capture circuit.   11. The processor-based emulation system of claim 10, further comprising a memory that is in electrical communication with the capture circuit.   12. The processor-based emulation system of claim 10, wherein each processor cluster includes a plurality of processors designed to emulate an integrated circuit design. 11. The processor-based emulation system of claim 10, wherein each processor cluster is
Multiple processors,
A data stack that is in electrical communication with a plurality of processors is included. 11. The processor-based emulation system of claim 10, wherein each processor cluster is
Multiple processors,
A data stack capable of electrical communication with multiple processors;
A plurality of multiplexers that are in electrical communication with the data stack are included. 11. The processor-based emulation system of claim 10, wherein each processor cluster is
Multiple processors,
A data stack capable of electrical communication with multiple processors;
A plurality of multiplexers in electrical communication with the data stack;
A plurality of registers that are in electrical communication with the plurality of multiplexers are included.   12. The processor-based emulation system of claim 10, wherein processor clusters can transfer data to each other over a communication link.   11. The processor-based emulation system of claim 10, wherein the capture circuit includes a FIFO (first in-first out) memory.   11. The processor-based emulation system of claim 10, wherein the processor cluster and capture circuit are implemented on a single integrated circuit.

Images