KR20040028598A - Vcd-on-demand system and method - Google Patents

Abstract

The present invention relates to a so-called custom VCD. In a typical system, an EDA tool that incorporates custom VCD technology has the following high-level attributes: (1) RCC-based parallel simulation history compression and recording, (2) RCC-based parallel simulation history compression and VCD file generation, And (3) On-demand software regeneration and design review without simulation rerun for the selected simulation target range. Each of these attributes will be described in detail. When the user selects a simulation session range, the RCC system records a highly compressed version of the key inputs from the test bench process. The user then selects a narrower area, called the simulation target range, within the simulation session range for more focused analysis. The RCC system dumps hardware state information (ie, major inputs) of the hardware model into the VCD file. The RCC system allows the user to proceed directly to viewing the VCD file from the start of the simulation target range without having to rerun the complete simulation from the start of the simulation session range.

Description

Custom DCC system and method {VCD-ON-DEMAND SYSTEM AND METHOD}

In general, electronic design automation (EDA) is a computer-based tool at various workstations to provide designers with automatic or semi-automated tools for designing and verifying custom circuit designs. EDA is commonly used to create, analyze and edit any electronic design for simulation, emulation, swatching, execution or computation. EDA technology is also used to develop systems (target systems) that will use user-designed subsystems or components. The end purpose of an EDA is a modified and reinforced design, typically in the form of an abstract integrated circuit or printed circuit board, ie an improvement over the prototype design while maintaining the spirit of the prototype design.

The value of software simulation in circuit design prior to hardware emulation has been recognized in many industries using EDA technology and taking advantage of EDA technology. Nevertheless, current software simulation and hardware emulation / acceleration are cumbersome for the user because of the separate and independent nature of these processes. For example, a user may debug or simulate a circuit design using software simulation for a fraction of the time in every one debug / test session, use the results to accelerate the simulation process using a hardware model for another time, and later Returns to the software simulation. In addition, as the simulation time progresses, internal registers and combinational logic values change, so the user must be able to monitor these changes even if they occur in the hardware model during the hardware acceleration / emulation process.

Co-simulation arose from the need to correct some of the troublesome nature of using two separate and independent pure software simulation processes and a pure emulation / acceleration process, making the overall system more user friendly. However, cosimulation still has some drawbacks: (1) the cosimulation system requires manual partitioning, (2) the cosimulation uses two small-combination engines, and (3) the cosimulation speed Is as slow as the software simulation, and (4) the cosimulation system collides with the race condition.

First of all, the division between software and hardware is done manually instead of automatically, which is burdensome for the user. In essence, co-simulation requires the user to split the design (starting at run level, then RTL, and gate level) and test the model on their own with very large functional blocks of software and hardware. This limitation requires some complexity for the user.

Secondly, the cosimulation system utilizes two small coupling and standalone engines, which raise internal engine synchronization, coordination, and flexibility issues. Cosimulation requires the synchronization of two different verification engines-software simulation and hardware emulation. Even if the software simulation side is connected to the hardware acceleration side, only external pin-out data is available for inspection and loading. The values and combinational logic levels inside the model circuit in the registers are not useful for easy inspection and downloading from one side to the other, limiting the use of these cosimulation systems. Typically, you may need to re-simulate the entire design if you switch back from software simulation to hardware acceleration. Thus, if a user wants to switch between software simulation and hardware emulation during a single debug session, while checking registers and combinatorial logic, the cosimulation system does not provide this capability.

Third, the cosimulation speed is as slow as the simulation speed. Cosimulation requires the synchronization of two different verification engines-software simulation and hardware emulation. Each engine has its own control mechanism for running the simulation or emulation. This means that the synchronization between software and hardware drives the overall performance at as low speed as software simulation. An additional burden of coordinating the operation of these two engines is added to the low speed of the cosimulation system.

Fourth, cosimulation systems face setup, hold time and clock glitches problems due to race conditions between clock signals. Cosimulation uses a hardware driven clock, which can be found at the input for different logic elements at different times due to different wiring lengths. If these logic elements need to evaluate the data together, this leads to uncertainty in the evaluation result because any logic element evaluates the data at any time period and another logic element evaluates the data at another time period.

Another problem faced by conventional designers is the relatively slow process of isolating and recognizing design problems during debug. The designer's own limited problem solving ability may contribute to some of these scattered paces, but the main source of these problems is the simulator itself. Because of the software-based engine, debugging in the simulator, as well as slow simulators, requires the entire simulation to be run again. These problems will be further explained.

A typical ASIC chip designer uses a simulator to debug, that is, the designer uses a test bench process to simulate or test the design to observe their response to various stimuli, among others. Based on the examination of several key nodes of the design, the designer can generally determine the presence or absence of a defect in their design. Of course, if the design is in its infancy, it always has some problems.

However, locating bugs is not easy. In a fairly large and complex design (such as millions of gates or more), the simulator must go through a number of simulation time steps before one of the bugs becomes apparent. Clearly, in this design, the designer cannot expect to review each simulation time step. Frankly, this would not be possible in a given short time span in the product design development cycle.

Once the simulator generally detects the presence of a bug, an actual bug must be specially placed to eliminate the bug's defective design. When did the problem occur (ie simulation time step)? Did it occur early in the simulation (eg t10), mid-term (eg t1000) or boil (eg t1000000)? Also, where is the problem located (ie the physical location of the circuit design) so that repairs can be provided? Initially, the designer does not know exactly where the bug occurred (simulation time step), but he can make a reasonable estimate. The designer may have several ways to proceed with the exact simulation time he thinks the problem is located. The simulator can assist the designer in this task by providing a Value Change Dump (VCD) file through one of two conventional methods—a complete VCD and an optional VCD.

In the full VCD method, the simulator stores the entire simulation as a VCD file from simulation time t0 to the simulation end. Then, the VCD file is analyzed by the designer to isolate the bug. The designer can make a reasonable estimate of the general position and find it by some elaborate stepping: if the designer suspects that the bug has occurred somewhere between simulation times t350 and t400, he has a simulation time of t345. We will proceed to the simulation time located just before the suspected simulation time. The designer will then proceed to examine this suspect area very carefully (ie t345 to t400).

However, to reach this simulation time, the designer has to restart the entire simulation from the beginning (ie t0) with the VCD file, regardless of where the bug originated. If the initial estimate of the location of his bug is wrong, he must make another estimate and restart the simulation from the beginning. For designs with more than one million gates and more than one million simulation time steps, the debugging process that restarts the simulation from this initiation is a very large time wasted by bad estimation.

However, designs with more than one million gates and more than one million simulation time steps require a lot of disk space. Typically, a complete VCD file of approximately 100 GB is unusual. This process of access storage requires several hours, and as a result, the simulation must be paused for a while until the storage operation ends at a given simulation time. Today, the complete VCD method is no longer practical.

In the optional VCD method, the entire simulation is not saved; Rather, the simulator stores a simulation of the part selected by the designer. However, the optional VCD does not reduce the need for the designer to restart the entire simulation from the start. From the outset, designers must run simulations and observe problems in their design. Then, estimate where the problem is located. If the designer assumes that the problem will occur somewhere between simulation times t350 and t400, the designer restarts the simulation and instructs the simulator to save this simulation time range as a VCD file. The designer can then examine the VCD file corresponding to his estimate. If his estimate is wrong in locating the problem, he must make another estimate, instruct the simulator to save the new simulation range as a VCD file, and then restart the simulation. The designer then analyzes the VCD file again.

Unlike the full VCD method, the optional VCD does not require many disks because the entire simulation is not saved. However, the optional VCD still requires restarting the entire simulation. If the designer makes a mistake in locating the bug, he has to restart the simulation again to save the new simulation range in the VCD file. In either case, the selective VCD method is still aggravated by wasted time.

Accordingly, there is a need in the industry for systems and methods for correcting problems caused by currently known simulation systems, hardware emulation systems, hardware acceleration, cosimulation, and co-coverage systems.

The present invention is an application related to a partial serial application (CIP) of US patent application Ser. No. 09 / 144,222, filed with USPTO on August 31, 1998.

The present invention generally relates to a value change dump (VCD) improvement to speed up a design debug session.

1 shows a top schematic diagram of one embodiment of the present invention, including a workstation, a reconfigurable hardware emulation model, an emulation interface, and a target system coupled to a PCI bus,

2 illustrates one specific use flow diagram of the invention,

3 illustrates a top view of software compilation and hardware configuration during compilation time and runtime in accordance with an embodiment of the present invention.

4 shows a flow diagram of a compilation process including a software / hardware model and software kernel code generation,

5 shows a software kernel that controls the entire SEmulation system.

6 shows a method of mapping a hardware model to a reconfigurable board through mapping, placement, and routing,

FIG. 7 shows the connectivity matrix for the FPGA array shown in FIG. 8,

8 shows an embodiment of a 4x4 FPGA array and their internal connections,

9 (A), (B) and (C) illustrate an embodiment of a time division multiplexing circuit in which a group of wires are joined together in a time multiplexing manner so that one pin can be used for a group of wires in a chip instead of multiple pins. Indicates. Fig. 9A shows an outline of the pinout problem, Fig. 9B provides a TDM circuit at the originating side, and Fig. 9C provides a TDM circuit at the receiving side.

10 illustrates a structure of a SEmulation system according to an embodiment of the present invention,

11 shows an embodiment of the address pointer of the present invention,

12 illustrates a state transition of address pointer initialization for the address pointer of FIG.

FIG. 13 illustrates an embodiment of a MOVE signal generator that derivatively generates various MOVE signals for an address pointer,

14 shows a chain of address pointers multiplexed on each FPGA chip,

15 illustrates one embodiment of a cross chip address pointer chain multiplexed according to an embodiment of the present invention,

16 shows a flow chart of a clock / data network analysis that is critical for software clock execution and evaluation of logic components of a hardware model.

17 illustrates a basic building block of a hardware model according to an embodiment of the present invention,

18 (A) and (B) show register model execution for latches and flip-flops,

19 illustrates an embodiment of clock edge detection logic in accordance with an embodiment of the present invention.

20 illustrates a four state confined state machine for controlling the clock edge detection logic of FIG. 19 in accordance with an embodiment of the present invention.

Figure 21 shows the internal connections, JTAG, FPGA, bus and overall signal pin assignments for each FPGA chip in accordance with one embodiment of the present invention,

22 illustrates one embodiment of an FPGA controller between a PCI bus and an FPGA array,

FIG. 23 shows a more detailed description of the CTRL_FPGA unit and data buffer discussed with respect to FIG. 22;

24 illustrates a 4x4 FPGA array, its relationship to the FPGA, and its expansion capabilities,

25 illustrates one embodiment of a hardware initiation method,

26 illustrates an HDL code for an example of a user circuit design to be modeled and simulated,

27 is a circuit diagram showing a circuit design of the HDL code of FIG.

FIG. 28 shows component shape analysis for the HDL code of FIG. 26;

29 illustrates a signal network analysis of a structured RTL HDL code based on the user order circuit design shown in FIG. 26,

30 shows the result of software / hardware partitioning of the same virtual example,

31 shows a hardware model for the same virtual example,

32 shows one specific hardware model versus chip splitting result for the same hypothetical example of a user-customized circuit design,

33 illustrates another specific hardware model versus chip splitting result of the same hypothetical example of a user-customized circuit design,

34 illustrates a logic patching operation for the same hypothetical example of a user order circuit design,

35 (A) to 35 (D) illustrate the "hops" and internal connection principle in two examples,

36 shows an outline of an FPGA chip used in the present invention,

37 shows an FPGA internal connection bus on an FPGA chip,

38 (A)-(B) show a side view of an FPGA board connection according to one embodiment of the invention,

39 illustrates a direct-neighbor and one-hop six-board interconnect layout of an FPGA array in accordance with an embodiment of the present invention.

40 (A) and 40 (B) show an FPGA internal board interconnection configuration.

41A to 41F show a top view of the board internal connection connector,

42 illustrates on-board connectors and some components of a typical FPGA board,

Fig. 43 shows the use of the connectors of Figs. 41A to 41F and Fig. 42;

44 illustrates a direct-naver and one-hop dual board interconnect layout of an FPGA array according to another embodiment of the present invention.

45 illustrates a workstation with a multiprocessor according to another embodiment of the present invention,

46 illustrates an environment according to another embodiment of the present invention in which multiple users share a single simulation / emulation system on a time sharing basis,

47 illustrates a higher structure of a simulation server according to an embodiment of the present invention.

48 illustrates a structure of a simulation server according to an embodiment of the present invention.

49 shows a flowchart of a simulation server,

50 shows a flowchart of a job swapping process,

51 shows a signal between a device driver and a reconfigurable hardware unit,

FIG. 52 illustrates a time sharing feature of a simulation server for coordinating multiple jobs with various levels of priority,

53 illustrates a communication handshake signal between a device driver and a reconfigurable hardware unit,

54 shows a state diagram of the communication handshake protocol,

55 shows a schematic diagram of a client-server model of a simulation server according to an embodiment of the present invention,

56 shows a high block diagram of a simulation system for performing memory mapping in accordance with an embodiment of the present invention,

FIG. 57 shows a more detailed block diagram of a memory mapping aspect of a simulation system with support components for an evaluation limited state machine (EVALFSM _x ) and a memory limited state machine (MEMFSM) for each FPGA logic unit, and FIG.

58 is a state diagram of a state machine of the MEMFSM in the CTRL_FPGA unit according to one embodiment of the present invention;

59 is a state diagram of a limited state machine in each FPGA chip according to one embodiment of the present invention;

60 shows a memory read data double buffer,

61 illustrates a simulation write / read cycle in accordance with an embodiment of the present invention.

Fig. 62 shows a timing diagram of a simulation data transfer operation when a DMA read operation occurs after the CLK_EN signal,

Fig. 63 shows a timing chart of the simulation data transfer operation when the DMA read operation occurs near the end of the EVAL period,

64 shows a typical user design implemented as a PCI add-in card,

65 illustrates a hardware / software co-verification system using an ASIC as the device under test,

66 shows a typical joint verification system using an emulator when the device under test is programmed into the emulator,

67 illustrates a simulation system in accordance with an embodiment of the present invention.

68 illustrates a joint verification system without external I / O devices in accordance with an embodiment of the present invention, wherein the RCC computing system includes software models and target systems of various I / O devices.

69 illustrates a joint verification system with actual external I / O devices and target systems in accordance with another embodiment of the present invention,

70 is a more detailed logic diagram of control logic internal data according to an embodiment of the present invention,

71 is a more detailed logic diagram of control logic external data according to an embodiment of the present invention.

72 is a timing diagram of control logic internal data,

73 is a timing diagram of control logic external data,

74 illustrates a board layout of an RCC hardware array in one embodiment of the present invention.

75 (A) shows an example of a shift register circuit to be used for explaining the holding time and clock glitches problems,

FIG. 75B is a timing diagram of the shift register circuit shown in FIG. 76A for explaining the holding time.

FIG. 76 (A) shows the same shift register circuit shown in FIG. 75 (A) disposed across multiple FPGA chips,

FIG. 76B shows a timing chart of the shift register circuit shown in FIG. 76A for explaining the infringement of the holding time.

77A shows an example of a logic circuit to be used to explain the clock glitches problem,

FIG. 77B shows a timing diagram of the logic circuit of FIG. 77A for explaining the clock glitches problem.

78 shows a timing adjustment technique of the related art for solving the maintenance time infringement problem,

79 illustrates a timing re-integration technique of the prior art for solving the maintenance time violation problem,

80 (A) shows the original latch, and FIG. 80 (B) shows the latch without glitches, without being affected by timing, according to one embodiment of the invention,

81 (A) shows the original design flip-flop, FIG. 81 (B) shows the design-free flip-flop without being affected by timing in accordance with one embodiment of the present invention,

FIG. 82 illustrates a timing diagram of a trigger mechanism of a latch and flip-flop without glitches without being affected by timing according to an embodiment of the present invention.

These features will be discussed below in connection with various various aspects and embodiments of the invention.

83 illustrates a top view of components of an RCC system incorporating an embodiment of the present invention.

84 illustrates several simulation time periods illustrating VCD operation on demand in accordance with an embodiment of the present invention.

One embodiment of the present invention is to provide a custom VCD file without simulation restart. On-demand VCD features are incorporated into an RCC system, which includes an RCC computing system and an RCC hardware accelerator. An RCC computing system includes computational resources that a user needs to simulate the user's entire software model design with software and control hardware acceleration of the hardware model portion of the design. The RCC hardware accelerator includes a reconfigurable array of logic elements (FPGAs) that can model at least a portion of the user's hardware design to allow the user to speed up the debugging process. The RCC computing system is tightly coupled to the RCC hardware accelerator through a software clock.

On-demand VCD allows the user to select a portion of the simulation history for detailed debugging analysis without restarting the simulation. The RCC system allows the user to choose between two simulation time ranges, a wider "simulation session range" and a narrower subset called the "simulation target range." After the selection of "simulation session range", the RCC system quickly provides a primary input from the test bench process to the hardware model in the RCC hardware accelerator for evaluation to quickly simulate the design for the entire duration of the simulation session range. In addition, these same primary inputs are compressed and recorded in the simulation history file. With this simulation history file, the RCC system can play any simulation part at any time within the scope of the simulation session.

At the start of the simulation session scope, the RCC system stores the hardware state information of the design at this point for the user to perform the necessary offline simulation. At the end of the simulation session scope, the RCC system stores the hardware state information of the design at this point so that the user can quickly return to this point of continuous simulation past this simulation session scope at any time without re-detecting the simulation.

When the user selects the "simulation target range", the RCC system decompresses the compressed primary inputs of the simulation history file and provides these decompressed primary inputs to the evaluation RCC hardware accelerator to quickly simulate the beginning of the simulation target range. do. In the simulation target range, the RCC system dumps the primary output or evaluated results from the hardware model into a VCD file for storage in the system disk. At the end of the simulation target range, the RCC system stops the dump process.

Once the VCD file is created, the user can view the VCD file with the waveform viewer to debug the design in more detail. If the bug is not located within its simulation target range, the user can select another simulation target range within the same simulation session range. Once a new simulation target range is selected, the RCC system creates a new VCD file in the manner described above. Then, the user can analyze this new VCD file to isolate the bug.

Once the bug has been isolated and cleaned up, the user can move past the current simulation session scope to simulate the next simulation scope. The hardware state information stored from the end of the current simulation session scope is loaded into the RCC system. The user can then start simulating. Custom VCD features are available both online and offline.

These and other embodiments are fully discussed and described by the following detailed description.

The above object and detailed description of the present invention will be more clearly understood from the following text and the accompanying drawings.

This specification will describe various embodiments of the invention through the background of the system, referred to as a "SEmulator" or "SEmulation" system, and within the background of the system. Throughout the specification, the terms "SEmulator system", "SEmulator" or simply system may be used. These terms include (1) software simulation, (2) simulation through hardware acceleration, (3) in-circuit emulation (ICE), and (4) post-simulation analysis including their respective setup or pre-processing steps; Reference is made to various apparatus and method embodiments in accordance with the present invention for any combination of four modes of operation. At other times, the term "SEmulation" may be used. This term refers to the new process described herein.

Similarly, terms such as reconfigurable computing (RCC) array systems, or RCC computing systems, refer to parts of the simulation / co-verification system that include the main processor, a user-designed software kernel, and a software model. Terms such as “reconfigurable hardware array” or “RCC hardware array” refer to that portion of a simulation / co-verification system that, in one embodiment, includes a hardware model of a user design and includes an array of reconfigurable logic elements.

In addition, the present specification refers to "user" and "circuit design" or "electronic design" of the user. A "user" is a person who uses the SEmulation system through its interface and can be a designer or a test / debugger of the circuit with little or no participation in the design process. A "circuit design" or "electronic design" is a custom design system or component that can be modeled by a SEmulation system for a test / debug process, whether in software or hardware. In many cases, the "user" has also designed a circuit or electronic design.

In addition, the specification uses the terms "wire", "wire line", "wire / bus line" and "bus". These terms refer to various electrically conductive lines. Each line may be a single wire between two points or several wires between points. These terms are interchangeable in that the wire may include one or more conductive lines, and the bus may also include one or more conductive lines.

This specification is shown in schematic form. First of all, the present specification presents a general outline of a SEmulator system that includes an outline of four modes of operation and a hardware execution configuration. Second, the present specification provides a detailed discussion of the SEmulator system. In some cases, one figure may provide a variation of the embodiment shown in the previous figure. In these cases, similar reference numerals may be used for similar components / units / processes. The outline of this specification is as follows:

I. Overview

A. Simulation / Hardware Acceleration Mode

B. Emulation by Target System Mode

C. Post-Simulation Analysis Mode

D. Hardware Execution Structure

E. Simulation Server

F. Memory Simulation

G. Joint Verification System

II. System description

III. Simulation / Hardware Acceleration Mode

IV. Emulation by Target System Mode

V. Post-Simulation Analysis Mode

VI. Hardware execution structure

A. Overview

B. Address Pointer

C. Gate Data / Clock Network Analysis

D. FPGA Array and Control

E. Other Embodiments Using High Density FPGA Chips

F. TIGF Logic Unit

VII. Simulation server

VIII. Memory simulation

IX. Joint verification system

X. Example

I. Overview

Various embodiments of the present invention have four general modes of operation: (1) software simulation, (2) simulation with hardware acceleration, (3) in-circuit emulation, and (4) post-simulation analysis. Various embodiments include systems and methods in these modes having at least some of the following features.

(1) a single tightly coupled simulation engine that controls software and hardware models per cycle, software and hardware models with software kernels, and (2) automatic components during the compilation process for generating and partitioning software and hardware models. Ability to switch (per cycle) between software simulation modes, through shape analysis, (3) hardware acceleration mode, in-circuit emulation mode, and post-simulation analysis mode, and (4) full hardware model visibility through software combination component regeneration (5) dual buffer clock modeling with software clock and gate clock / data logic to avoid race conditions, and (6) re-simulate or accelerate hardware design of the user's circuit design from randomly chosen points within the elapsed simulation session. doing ability. The end result is elastic, and rapid simulator / emulator systems and methods will perfect HDL functionality and emulator execution performance.

A. Simulation / Hardware Acceleration Mode

SEmulator systems, with automatic component type analysis, can model custom circuit designs in software and hardware. The entire user circuit design is modeled in software, while evaluation components (ie, register components, combination components) are modeled in hardware. Hardware modeling is facilitated by component type analysis.

The software kernel, which belongs to the main memory of the general-purpose process system, functions as the main program of the SEmulator system, which controls the execution and overall operation of various modes and features. As long as any test bench process works, the kernel evaluates active test bench components, evaluates clock components, detects clock edges, updates register and memory as well as combinatorial logic data, and advances simulation time. These software kernels are provided for a simulation engine that is tightly coupled with a hardware acceleration engine. At the software / hardware boundary, the SEmulator system provides many I / O address spaces-REG (register), CLK (software clock), S2H (software to hardware) and H2S (hardware to software).

The SEmulator has the ability to selectively switch between four modes of operation. The user of such a system starts a simulation, stops a simulation, asserts an input value, examines a value, goes through a single step every cycle, and switches back and forth between four different modes. For example, the system can simulate circuitry in software over a period of time, accelerate simulation through a hardware model, and return to software simulation mode again.

In general, SEmulation systems give users the ability to recognize all modeled components, whether they are modeled in software or hardware. For various reasons, the combinatorial component is not as visible as a register, so obtaining combinatorial component data is difficult. One reason is that instead of the actual combinatorial components, typically the combinatorial component, such as a lookup table (LUT), is modeled by the FPGA used in the reconfigurable board to model the hardware portion of the user circuit design. Thus, the SEmulation system reads the register value, regenerating the combinational component. Since there is a small burden of generating a combinatorial component, this regeneration process is not always performed, but rather only at the request of the user.

Since the software kernel resides on the software side, a clock edge detection mechanism is provided to trigger the generation of so-called software clocks that drive the operational inputs to the various registers in the hardware model. The timing is tightly controlled through double buffer circuit execution so that software clock enable signals enter the register model before modeling the data for them. Once the data inputs to these register models have stabilized, the software clock gates the data at the same time to ensure that all data values are gated together without any risk of breach of retention time.

Software simulation is also fast because the system logs all input values and selected register values / states, thus reducing the burden by reducing the number of I / O operations. The user can optionally select the logging frequency.

B. Emulation by Target System Mode

The SEmulation system can emulate the user's circuitry within its target system environment. The target system outputs data to the evaluation hardware model, which also outputs data to the target system. In addition, the software kernel controls the operation of this mode so that the user still starts, stops, asserts the value, goes through a single step, and makes a choice to switch from one mode to another.

C. Post-Simulation Analysis Mode

The log provides the user with a record of the simulation session. Unlike known simulation systems, the SEmulation system does not log every single value, internal state, or value change during the simulation process. The SEmulation system only logs selected values and states based on the logging frequency (ie log 1 record every N cycles). During the post-simulation phase, if you want to examine the various data near point X in the simulation session you just ended up, you can go to one of the logged points and select the logged point Y closest to and temporarily temporarily before point X. Say. The user then simulates from the selected logged point Y to the desired point X to obtain a simulation result.

In addition, a custom VCD system will be described below. This custom VCD system allows the user to observe an arbitrary simulation target range (ie simulation time) without restarting the simulation.

D. Hardware Execution Structure

The SEmulation system implements an FPGA chip array on a reconfigurable board. Based on the hardware model, the SEmulation system divides, maps, places and routes each selected portion of the user's circuit design onto the FPGA chip. Thus, for example, sixteen chips in a 4x4 array may be modeling of a large circuit that extends across these sixteen chips. The internal connection structure allows each chip to access another chip within two jumps or links.

Each FPGA chip implements an address pointer for each of the I / O address spaces (ie, REG, CLK, S2H, H2S). The combination of all address pointers associated with a particular address space is concatenated with each other. Thus, during data transfer, the word data in each chip is to / from the main FPGA bus and PCI bus one word at a time, one chip at a time, and one word at a time for the selected address space in each chip to the selected address space. Are selected continuously until they are accessed. This continuous selection of word data is accomplished by the transfer of a word select signal. This word select signal travels through the address pointer in the chip and then propagates to the address pointer of the next chip and continues until the last chip or system initializes the address pointer.

The FPGA bus system on the reconfigurable board operates at twice the bandwidth of PCI bus bandwidth and half the PCI bus speed. Thus, FPGA chips are divided into banks to use buses of higher bandwidth. The throughput of these FPGA bus systems can track the throughput of the PCI bus system so that it does not lose performance by reducing the bus speed. Expansion is possible through piggyback boards that extend the bank length.

In another embodiment of the present invention, a high density FPGA chip is used. One such high density chip is the Altera 10K 130V and 10K 250V chips. The use of these chips changes the board design so that only four FPGA chips (Altera 10K 100) are used per board instead of eight less dense FPGA chips.

The FPGA array of the simulation system is provided on the motherboard through specific board interconnects. Each chip can have up to eight internal connections, where the internal connections are direct neighbor internal connections (ie, N [73: 0], W [73: 0], E [73: 0). ]) And one-hop neighbor internal connections (ie NH [27: 0], SH [27: 0], XH [36: 0], excluding local bus connections within one single board and across other boards) XH [72:37]). Each chip is internally connected directly to adjacent neighboring chips or internally within one hop to non-adjacent chips located above, below, left and right. In the X direction (east-west), the array is a torus. In the Y direction (north-south), the array is a mesh structure.

Only internal connections can combine logic and other components within a single board. However, internal board connectors are provided to couple these boards and internally connect each other across the various boards to transfer signals between (1) the PCI bus through the motherboard and the array board and (2) any array board. .

The motherboard connector connects the board to the mother mode and thus to the PCI bus, power, and ground. In some boards, the motherboard connector is not used for direct connection to the motherboard. In a six board structure, only boards 1, 3, and 5 are directly connected to the motherboard, while the remaining boards 2, 4, and 6 rely on their adjacent boards for motherboard connectivity. Thus, all other boards are directly connected to the motherboard, and the local buses and internal connections of these buses are joined together through internal board connectors arranged on the solder side or component side. PCI signals are routed through only one of the boards (usually the first). Power and ground are applied to other motherboard connectors for their boards. When placed on the solder side or component side, various internal board connectors allow communication between PCI bus components, FPGA logic devices, memory devices, and various simulation system control circuits.

E. Simulation Server

In another embodiment of the present invention, a simulation server is provided to allow multiple users to access the same reconfigurable hardware unit. In a system architecture, multiple workstations across a network, or multiple users / processes in a non-network environment, can access the same server-based reconfigurable hardware units to review / debug the same or different user circuit designs. have. The access is achieved through a time sharing process in which the scheduler determines access priorities for multiple users, exchanges jobs, and optionally locks hardware model access among the scheduled users. In one scenario, each user can access a server to map his / her respective user designs to the first reconfigurable hardware model, in which case the system compiles the designs to generate software and hardware models, Reconfigure the FPGA chip of the reconfigurable hardware unit to perform clustering operations, perform place and route operations, generate bitstream structure files, and model the hardware portion of the user design. If one user uses a hardware model to accelerate the design and download the hardware state to his own memory for software simulation, the hardware unit can be freed from access by other users.

The server provides multiple users or processes to access reconfigurable hardware for acceleration and hardware state exchange. The simulation server includes a scheduler or one or more device drivers, and a reconfigurable hardware unit. The scheduler in the simulation server is based on a preemptive round robin algorithm. The server scheduler includes a simulation job queue table, a priority classifier and a job exchanger. The restoration and playback functions of the present invention facilitate not only network multi-user environments, but also non-network multiprocessing environments, where previous checkpoint state data can be downloaded, and the overall simulation state associated with the checkpoint is either replay debugging or cycle-by-cycle. Can be restored for stepping.

F. Memory Simulation

The memory simulation or memory mapping aspect of the present invention provides an effective way for a simulation system to manage various memory blocks associated with a configured hardware model of a user design, programmed with an array of FPGA chips in a reconfigurable hardware unit. In this memory simulation aspect of the present invention, numerous memory blocks associated with a user design are mapped to an SRAM memory device in the simulation system instead of inside the logic device, which is used to construct and model the user design. The memory simulation system, along with the memory state machine, evaluation state machine and their associated logic for control and mediation; FPGA logic devices including (1) a main computing system and associated memory system, (2) an SRAM memory device coupled to an FPGA bus within a simulation system, and (3) a formed and programmed user design to be debugged. Operation of the memory simulation system according to an embodiment of the present invention is generally as follows. The simulation write / read cycle is divided into three period-DMA data transfer, evaluation and memory accesses.

The FPGA logic unit side of the memory simulation system includes an evaluation state machine, an FPGA bus driver, and a logic interface for each memory block N to interface with the user's own memory interface in the user design: (1) data between FPGA logic units; Evaluate, (2) coordinate write / read memory access between FPGA logic and SRAM memory devices. In conjunction with the FPGA logic unit side, the FPGA I / O controller side may include a memory state machine and (1) a main computing system and an SRAM memory device, and (2) DMA, write and read operations between the FPGA logic device and the SRAM memory device. It includes interface logic to adjust this.

G. Joint Coverage System

One embodiment of the present invention is a co-verification system comprising a reconfigurable computing system (hereinafter referred to as RCC computing system) and a reconfigurable computing hardware array (hereinafter referred to as RCC hardware array). In some embodiments, the target system and external I / O devices are not essential because they can be modeled in software. In another embodiment, the target system and external I / O device are actually coupled to a joint verification system to use and obtain actual data rather than simulated test bench data. Thus, one joint verification system may use an actual target system and / or I / O device while merging the RCC computing system and the RCC hardware array with other functions to debug the software and hardware portions of the user design. .

The RCC computing system also includes clock logic (for edge detection and software clock generation), test bench processes for testing user designs, and any that the user decides to model in software instead of using actual physical I / O devices. Contains device models for I / O devices. Of course, the user can decide to use the actual I / O device as well as the modeled I / O device in one debug session. The software clock is provided on the interface to function as an external clock source for the target system and external I / O devices. The use of this software clock provides the synchronization necessary to process incoming and outgoing data. Since the RCC computing system-generated software clock is time based for the debug session, the simulated and hardware accelerated data is synchronized with any data passed between the joint verification system and the external interface.

When the target system and the external I / O device are coupled to the joint verification system, pinout data must be provided between the joint verification system and its external interface. The joint verification system is a control logic that provides traffic control between (1) the RCC computing system and the RCC hardware array and (2) the external interface (coupled to the target system and external I / O devices), and (3) the RCC hardware array. It includes. Since the RCC computing system has a model of the overall design in software, including user-designed parts modeled on the RCC hardware array, the RCC computing system must also access all data passing between the external interface and the RCC hardware array. Control logic ensures that the RCC computing system accesses this data.

II. System description

1 shows a high level schematic diagram of one embodiment of the present invention. The workstation 10 is coupled to the hardware model 20 and the emulation interface 30 via a PCI bus system. The reconfigurable hardware model 20 is coupled to the emulation interface 30 via the PCI bus 50 as well as the cable 61. The target system 40 is coupled to the emulation interface 30 via a cable 60. In another embodiment, the in-circuit emulation setup 70, including the emulation interface 30 and the target system 40 (indicated by dashed boxes), allows the emulation of the user design within the environment of the target system during a particular test / debug session. If not required, it is not provided within this setup. Without the in-circuit emulation setup 70, the reconfigurable hardware model 20 communicates with the workstation 10 via the PCI bus 50.

In conjunction with the in-circuit emulation setup 70, the reconfigurable hardware model 20 mimics or simulates the user's circuit design of several electronic subsystems in the target system. In order to ensure the correct operation of the circuit design of the user of the electronic subsystem in the environment of the target system, input and output signals between the target system 40 and the modeled electronic subsystem are passed to the reconfigurable hardware model 20 for evaluation. Should be provided. Thus, input and output signals of the target system 40 to and from the reconfigurable hardware model 20 are passed through the cable 60 through the emulation interface 30 and the PCI bus 50. Optionally, the input / output signal of the target system 40 can be delivered to the reconfigurable hardware model 20 via the emulation interface 30 and the cable 61.

Control data and some body simulation data pass between the reconfigurable hardware model 20 and the workstation 10 via the PCI bus 50. In practice, workstation 10 controls the operation of the entire SEmulation system and runs a software kernel that must be accessed (written / read) with the reconfigurable hardware model 20.

One workstation 10, complete with a computer, keyboard, mouse, monitor, and appropriate bus / network interface, allows the user to enter and modify data describing the circuit design of the electronic system. Typical workstations include Sun Microsystems SPRAC or ULTRA-SPARC workstations or Intel / Microsoft based computing stations. As known to those skilled in the art, the workstation 10 includes a CPU 11, a local bus 12, a host / PCI bridge 13, a memory bus 14, and a main memory 15. Various software simulations, hardware-accelerated simulations, in-circuit emulation and post-simulation analysis aspects of the present invention are provided within workstation 10, reconfigurable hardware model 20, and emulation interface 30. Algorithms implemented in software are stored in main memory 15 during the test / debug session and run through CPU 11 via the operating system of the workstation.

As is already known to those skilled in the art, after the operating system has been loaded into the memory of the workstation 10 by the initial firmware, control passes its initialization code to set up the required data structures to load and initialize the device driver. Control is then passed to the command line interpreter CLI, prompting the user to instruct the program to be run. The operating system then determines the amount of memory needed to run the program, locates the memory block, or allocates the memory block and accesses the memory either directly or through the BIOS. After the end of the memory loading process, the application program starts executing.

One embodiment of the present invention is a specific application program of SEmulation. During its execution, the application program may require numerous services from the operating system, including but not limited to reading and writing from disk files, performing data communications, and displaying / keyboard / mouse interfacing.

Workstation 10 has a suitable user interface that allows a user to enter circuit design data, edit circuit design data, monitor simulation and emulation processes, obtain results while essentially controlling the simulation and emulation process. Although not shown in FIG. 1, the user interface includes a set of user accessible menu options and commands that can be viewed with a monitor and entered with a keyboard and mouse.

The user typically creates a specific circuit design of the electronic system and inputs the HDL (usually configured at the RTL level) code description of his designed system to the workstation 10. The SEmulation system of the present invention performs component shape analysis among different operations to partition modeling between software and hardware. The SEmulation system models the software's behavior, RTL and gate level code. In hardware modeling, the system can model RTL and gate level codes, but the RTL level must be integrated at the gate level before hardware modeling. Gate level code can be processed directly into an available source design database format for hardware modeling. Using RTL and gate level codes, the system automatically performs component shape analysis to complete the segmentation step. Based on segmentation analysis during software compile time, the system maps several parts of the circuit design into hardware for rapid simulation through hardware acceleration. The user may combine the modeled circuit design into a target system for a real environment in circuit emulation. Because the software simulation and hardware acceleration engine are tightly coupled, the software kernel allows the user to simulate the entire circuit design using software simulation and to accelerate the test / debug process using the hardware model of the mapped furnace design. Return to the simulation section, and return to hardware acceleration until the test / debug process is performed. The ability to switch between cycle-by-cycle and software simulation and hardware acceleration at will is one of the valuable features of this embodiment. This feature is particularly useful in the debug process by using hardware accelerated mode and using software simulation to allow the user to go to a specific point or cycle very quickly to check for defects in the circuit design after examining various points. Moreover, the SE emulation system allows the user to see all components whether the internal realization of the components is hardware or software. The emulation system accomplishes this by reading the register values from the hardware model when the user requires such a reading, and then redesigning the combinatorial component using the software model. These and other features will be discussed in more detail in the detailed description.

Workstation 10 is connected to bus system 50. The bus system can be any available bus system that allows various agents, such as workstation 10, reconfigurable hardware model 20, and emulation interface 30, to operate in conjunction with one another. Preferably, the bus system is fast enough to provide the user in real time or near real time. One such bus system is the bus system described above in the Environmental Component Interconnect (PCI) standard referenced herein. Recently, PCI Standard Revision 2.0 provides a 33 MHz bus speed. Revision 2.1 provides 66 MHz bus speed support. Thus, workstation 10, reconfigurable hardware model 20, and emulation interface 30 conform to the PCI standard.

In one embodiment, the communication between workstation 10 and reconfigurable hardware model 20 is via a PCI bus. Other PCI performing devices can be found in this bus system. Such a device may be coupled to the PCI bus at the same level or at a different level, such as workstation 10, reconfigurable hardware model 20, and emulation interface 30. Like PCI bus 52, each PCI bus at a different level, if present, is connected to another PCI bus level, such as PCI bus 50, through PCI-to-PCI bridge 51. In the PCI bus 52, two PCI devices 53, 54 may be combined.

The reconfigurable hardware model 20 includes a field-programmable gate array (FPGA) chip array that is programmable and reconfigurable to design the hardware portion of the user's electronic system design. In this embodiment, the hardware model is reconfigurable; That is, the hardware can be reconfigured to suit a particular computational or manual user circuit design. For example, if many adders or multiplexers are required, the system is configured to include many adders and multiplexers. When other computing elements or functions are required, they may be modeled or formed in the system. In this way, the system can be optimized to perform certain computational or logical operations. The reconfigurable system is flexible such that a user can solve a few hardware defects that occur during manufacturing, testing or use. In one embodiment, reconfigurable hardware model 20 includes a two dimensional array of computing elements including FPGA chips to provide computational resources for various user circuit designs and applications. The hardware configuration process will be provided in more detail.

Two such FPGA chips include those sold by Altera and Xilinx. In some embodiments, the reconfigurable hardware model is reconfigurable through the use of a field programmable device. However, other embodiments of the present invention may be implemented using in an application specific integrated circuit (ASIC) technique. Other embodiments may be in the form of custom ICs.

In a typical test / debug scenario, the reconfigurable device will be used to simulate / emulate the user's circuit design so that appropriate changes are made before actual prototype fabrication. In another example, however, this deprives the user of the ability to quickly and cost-effectively change re-simulation and non-functional circuit design for re-emulation, although actual ASICs or custom integrated circuits may be used. Such ASICs or custom ICs may be better emulated with chips that are already manufactured and available, even if they are not practically reconfigurable.

According to the present invention, depending on the density of the external hardware model, the software in the workstation provides greater flexibility, control and performance for end users on the existing system. In order to run the simulations and emulations, the model of the circuit design and associated parameters (eg input test-bench stimulus, total system output, intermediate results) are determined and provided to the simulation software system. The user can use the schematic capture device or the analysis device to define the system circuit design. The user typically begins the design of the electronic system circuit in draft schematic form, and then uses an analysis device to call HDL. The HDL may be written directly by the user. Exemplary HDL languages include Verilog and VHDL; However, other languages are available. The circuit design represented in the HDL includes many cooperative components. Each component is a sequence of code that defines the behavior of a circuit element or controls simulation execution.

The SEmulation system analyzes to determine their component types, and the compiler uses this component type information to create different execution models in software and hardware. The user can then use the SEmulation system of the present invention. By applying various stimuli such as input signals, designers can verify the accuracy of the circuit through simulations and test the vector pattern of the simulated model. If during the simulation, the circuit does not work as planned, the user can redefine the circuit by adjusting the circuit schematic or HDL file.

The use of this embodiment of the present invention is shown in the flowchart of FIG. The algorithm starts at step 100. After loading the HDL file into the system, the system compiles, partitions, and maps the circuit design to fit the hardware model. Compiling, splitting and mapping steps will be discussed in more detail below.

Before running the simulation, the system must execute a reset sequence to remove all unknown "x" values in software before the hardware acceleration model can function. In one embodiment of the present invention, the bus signal-" 00 " is logic low, " 01 " is logic high, " 10 " is " z " and " 11 " Use a bit wide data path. As will be appreciated by those skilled in the art, the software model can handle "0", "1", "x" (bus crash or unknown value), and "z" (no driver or high impedance). On the contrary, the hardware cannot handle the unknown value "x", thus resetting the register value to all "0" or all "1" depending on the particular applicable code.

In step 105, the user determines whether to simulate the circuit design. Typically, the user will first start the system with software simulation. Therefore, if the decision is "Yes" in step 105, then a software simulation occurs in step 110.

The user stops the simulation to check the value, as shown in step 115. Indeed, the user may abort the simulation at any time during the test / debug session as shown by the dashed line extending to various nodes in the hardware acceleration mode, ICE mode and post-simulation mode in step 115. Execution of step 115 directs the user to step 160.

After aborting, if the user wants to check the combined component value, the user reads back the state of the hardware register component to regenerate the entire software model including the combined component. After saving the entire software model, the user can examine any signal value in the system. After stopping and checking, the user can continue to run in simulation mode or hardware acceleration mode. The abort / value check routine begins at step 160. In step 165, the user must stop the simulation at this point and decide whether to check the value. If step 165 determines "Yes," step 170 stops the simulation that is currently going on and checks various values to check the accuracy of the circuit design. In step 175, the algorithm returns to the point where it is branched to step 115. Here, the user can continue the simulation and interruption / value checking for the remainder of the test / debug session or proceed to the emulation phase in the circuit.

Similarly, if step 105 determines "no", the algorithm will proceed to hardware acceleration decision step 120. In step 120, the user determines whether to accelerate the test / debug process by accelerating the simulation through the hardware portion of the modeled circuit design. If the determination at step 120 is yes, then hardware model acceleration occurs at step 125. During the system editing process, the SEmulation system is partially mapped into the hardware model. Here, if hardware acceleration is required, the system moves registers and combinational components to the hardware model and input and evaluation values to the hardware model. Therefore, during hardware acceleration, evaluation takes place in the hardware model over long time periods at accelerated speeds. The kernel writes test-bench outputs to the hardware model, updates the software clock, and then writes the hardware model outputs every cycle. If required by the user, the value from the full software model of the user's circuit design, which is the overall circuit design, can be made available by outputting the register value and the combination component and regenerating the combination component with the register value. Because of the requirement of software intervention to regenerate this combinatorial component, the output for the entire software model is not provided every cycle, and the value is provided only if the user desires such a value. Such details will be discussed in the Combination Component Regeneration Processor.

Again, the user can stop the hardware acceleration mode at any time, as disclosed in step 115. If the user wants to abort, the algorithm proceeds to steps 115 and 160 to branch the abort / value checking routine. Here, as in step 115, the user may abort the hardware accelerated simulation process at any time, check the value coming from the simulation process, or the user may continue the hardware-accelerated simulation process. The stop / value checking routine is branched to steps 160, 165, 170, and 175, which are mentioned in the simulation stop. Returning to the main routine after step 125, the user can decide whether to continue the hardware-accelerated simulation or instead run a pure simulation in step 135. If the user wants to add more simulations, the algorithm proceeds to step 105. If not, the algorithm proceeds to post-simulation analysis in step 140.

In step 140, the SEmulation system provides a number of pros-simulation analysis features. The system logs all inputs to the hardware model. For hardware model output, the system writes all the values of the hardware register components at user defined logging frequencies (e.g., 1 / 10,000 writes / cycle). The logging frequency determines how often the output is recorded. During the logging frequency of 1 / 10,000 recordings / cycle, the output value is recorded once every 10,000 cycles. The higher the logging frequency, the more information is recorded during later post-simulation analysis. Since the selected logging frequency has a temporary relationship with the SEmulation rate, the user carefully selects the logging frequency. Higher logging frequencies will reduce the SEmulation rate because the system must spend time and resources to write output data by executing I / O operations in memory before more simulations are run.

Regarding post-simulation analysis, the user selects a particular point that the simulation requires. Then, after the SEmulation, the user analyzes by running a software simulation with an input log in the hardware model to calculate the value change and the internal state of all hardware components. Note that a hardware accelerator is used to simulate the data from the selected logging point to analyze the simulation results. It will be discussed in more detail below.

In step 145, the user can choose to emulate a simulated circuit design within the target system environment. If emulation with the target system is required, the algorithm proceeds to step 150. These steps include enabling the emulation interface board, plugging cables and chip pin adapters into the target system and executing the target system to obtain system I / O from the target system. The system I / P from the target system contains the signal between the emulation of the target system and the circuit design. The emulated circuit design receives an input signal from the target system, processes it, sends it to the SEmulation system for further processing, and outputs the processed signal to the target system.

In contrast, an emulated circuit design sends an output signal to the target system, processes the signal, and outputs the processed signal back to the emulated circuit design. In this way, the performance of the circuit design can be assessed in the original target system environment. After emulation with the target system, the user has a result that confirms the circuit design or shows a functional aspect. At this point, the user may again simulate / emulate, stop to adjust the circuit design, or proceed with integrated circuit fabrication based on the identified circuit design, as disclosed in step 135.

III. Simulation / Hardware Acceleration Mode

In accordance with one embodiment of the present invention, a high level diagram of software editing or hardware configuration during compilation time and execution time is disclosed in FIG. 3. 3 shows two sets of information; A set of information distinguishes actions performed during compilation time and simulation / emulation execution time; The other set of information shows the division between the software model and the hardware model. Initially, the SEmulation system in accordance with one embodiment of the present invention requires user circuit design as input data 200. The user circuit design is in the form of HDL files (eg Verilog, VHDL). The SEmulation system shrinks the HDL file so that the operation level code, register transfer level code and gate level code can be reduced in a form that can be used by the SEmulation system. The system creates a source design database for the front end processing step 205. The processed HDL file is available by the SEmulation system. The parsing process converts ASCII data into an internal binary data structure, which is known to those skilled in the art. See ALFRED V.AHO, RAVISETHI, JEFFREY D.ULLMAN, PRINCIPLE, THEHNIQUE AND TOOLS (1988).

Compilation time is represented by process 225, and execution time is represented by process / device 230. During the edit time, shown by process 225, the SEmulation system compiles the processed HDL file by performing component type analysis. Component shape analysis classifies HDL components into combination components, register components, clock components, memory components, and test-bench components. The system divides the user circuit design into control and evaluation components.

The SEmulation compiler 210 maps the control components of the simulation to software, and the evaluation components to software and hardware. Compiler 210 generates a software model for all HDL components. The software model is east of code 215. In addition, the SEmulation compiler 210 uses component type information in the HDL file, selects or creates hardware logic blocks / elements from the library or module generator, and generates a hardware model for a particular HDL component. The end result is a so-called "bitstream" configuration file 220.

In preparation of the execution time, the software model in the code form is stored in the main memory in which the application program associated with the SEmulation program according to one embodiment of the invention is stored. Such code is processed in a general purpose processor or workstation 240. At about the same time, the configuration file 220 for the hardware model is used to map the user circuit design to the reconfigurable hardware board 250. Here, the portion of the circuit design modeled in the hardware is mapped and divided into the FPGA chip in the reconfigurable hardware board 250.

As described above, user test-bench stimulus and test vector data and other test-bench resources 235 are provided to a general processor or workstation 240 for simulation purposes. In addition, the user can perform emulation of the circuit design through software control. Reconfigurable hardware board 250 contains a user's emulated circuit design. This SEmulation system has the ability for the user to selectively switch between software simulation and hardware emulation, to interrupt the simulation or emulation process at any time, and to check values from all components in the model. Thus, the SEmulation system passes data between the test-bench 235 and the processor / workstation 240 for simulation, and the test-bench through the data bus 245 and the processor / workstation 240 for emulation. Pass data between 235 and reconfigurable hardware board 250. If user target system 260 is included, emulation data may pass between target system 260 via reconfigurable hardware board 250 and emulation interface 255 and data bus 245. The kernel is found in a software simulation model in memory of the processor / workstation 240 so that data passes between the processor / workstation 240 and the reconfigurable hardware board 250 via the data bus 245.

4 shows a flowchart of an editing process according to one embodiment of the invention. The editing process is processes 205 and 210 shown in FIG. The editing process of FIG. 4 begins at 300. Step 301 processes the leaflet information. The gate level HDL code is generated here. The user transforms the initial circuit design into HDL form by using a schematic or analysis device to generate a gate level HDL representation of the code or by handwriting the code directly. The SEmulation system shrinks the HDL file (ASCII) into a binary format so that the behavior level code, register transfer level (RTL) and gate level code can be reduced to an internal data structure form acceptable by the SEmulation system. The system creates a source design database containing reduced HDL code.

Step 302 performs component type analysis by classifying the HDL component into a combination component, a register component, a clock component, a memory component, and a test-bench component shown as component type resource 303. The SEmulation system generates hardware models for registers and combinational components, with the exceptions discussed below. Test-bench and memory components are mapped to software. Some clock components (eg, derived clocks) are modeled in hardware, and others are modeled in software / hardware boundaries (eg, software clocks).

Combination components are stateless logic components whose output values are a function of the current input value and do not depend on past input values. Examples of combinational components include basic gates (eg, AND, OR, XOR, NOT), selectors, adapters, multiplexers, shifters, and bus drivers.

Register components are simple storage elements. The state transition of the register is controlled by the clock signal. One type of register is an edge-trigger register whose state changes when an edge is detected. Another type of register is a level triggered latch. Examples include flip-flops (D-type, JK-type) and level-sensitive latches.

The clock component is a device that sends periodic signals to the logic device to control the operation of the logic device. Typically the clock signal controls the update of the register. The main clock is generated from the self-time test-bench process. For example, a typical test-bench process for clock generation in Verilog is as follows.

start

Clock = 0;

# 5;

Clock = 1;

# 5

End;

According to this code, the clock signal is initially logic "0". After 5 time units, the clock signal changes to logic "1". After 5 time units, the clock signal changes back to logic " 0 ". Typically, the major clock signal is generated in software, and only a few (ie 1-10) major clocks occur in a typical user circuit design. The derived or gated clock is generated from a network of register and combinational logic that is in turn driven by the primary clock. Many (ie, more than 1000) derived clocks occur within conventional user circuit designs.

The memory component is a block storage component with an address and controls lines to access individual data within a particular memory location. Examples include ROM, asynchronous RAM, and synchronous RAM.

Test-bench components are software processes used to control and monitor the simulation process. Thus, these components are not part of the hardware during the test. The test-bench component controls the simulation by controlling the clock signal, initializing the simulation data, and reading the simulation test vector pattern from disk / memory. The test-bench component checks for value changes, runs a value change dump, checks for signal value relationship constraints, writes output test vectors to disk / memory, and monitors them by interfacing with various waveform viewers and debuggers.

The SEmulation system performs component type analysis as follows. The system tests the binary source design database. Based on the source design database, the system may classify as one of the component types. Consecutive assignment statements are classified as combinatorial components. The basic gate is a latch or combination of registers by language definition. The initialization code is treated as a test-bench in the initialization form.

The process of running a net without using a net is a test-bench in the form of a driver. The process of reading a net without running the net is a test-bench in the form of a monitor. A process with delay control or multiple event control is a common form of test-bench.

The process of driving a single event control and a single net can be one of the following: (1) If event control is an edge-triggered event, the process is an edge-triggered register component. (2) If a net driven in a process is not defined in all possible execution paths, the net is in the form of a latch of a register. (3) If a net driven in a process is defined in all possible execution paths, the net is a combinatorial component.

Processes with a single event control without multiple net drives are broken down into several processes that drive each net individually, driving individual component types. The decomposed process can be used to determine the component shape.

Step 304 generates a software model for all HDL components, regardless of component type. With the proper user interface, the user can simulate the entire circuit design using a complete software model. The test-bench process is used to drive the Cimamus input, test the vector pattern, control the overall simulation, and monitor the simulation process.

Step 305 performs clock analysis. Clock analysis consists of two general steps; (1) clock extraction and continuous mapping, and (2) clock network analysis. The clock extraction and continuous mapping steps include mapping a user's register component to the SEmulation system's hardware register model, and then extracting the clock signal out of the system's hardware register component. The clock network analysis step includes determining a derived clock based on the primary clock and the extracted clock signal and separating the gate clock network and the gate data network. Further details will be provided in conjunction with FIG. 16.

Step 306 executes residence selection. With respect to the user, the system selects a component for the hardware model; That is, among the hardware components that can be implemented in the hardware model of the user's circuit design, some hardware components will not be modeled in hardware for various reasons. These reasons include component type, hardware resource limitations (ie, floating point operation and large multiply operation in software), simulation and communication overhead (ie, small bridge logic between test-bench processes residing in software, and in software). Signal monitored by the test-bench process residing in the < RTI ID = 0.0 > For a variety of reasons, including performance and simulation monitoring, a user can be a specific component that is modeled in hardware to reside in software.

Step 307 maps the selected hardware model to a reconfigurable hardware emulation board. In particular, the step 307 map takes a netlist and maps the circuit design to a particular FPGA chip. This step includes grouping or clustering logic elements together. The system then assigns a single FPGA chip to each group, or assigns a single FPGA chip to several groups. The system may even separate groups to allocate to different FPGA chips. In general, the system assigns groups to FPGA chips. A more detailed discussion will be provided with respect to FIG. 6. The system places hardware model components on the mesh of the FPGA chip to minimize internal-chip communication overhead. In one embodiment, the array includes a 4x4 array of FPGAs, a PCI interface unit, and a software clock control unit. The FPGA array implements part of the user's hardware circuit design, as determined in steps 302-306 of this software editing process. The PCI interface unit allows a reconfigurable hardware emulation model to communicate with the workstation via the PCI bus. The software clock avoids race conditions for various clock signals in the array of FPGAs. Moreover, step 307 routes the FPGA chip in accordance with the communication schedule in the hardware model.

Step 308 inserts a control circuit. Such control circuitry includes data bus logic for communicating with the DMA engine to the I / O address pointer and simulator (discussed below in connection with FIGS. 11, 12 and 14), and hardware state transitions and wire multiplexing (see FIGS. 19 and 20 and Evaluation control logic) to control). As is known to those skilled in the art, a direct memory access (DMA) unit provides an additional data channel between the peripheral and the main memory, which can directly connect (i.e. read, write) to the main memory without CPU intervention. Can be. Address pointers within each FPGA chip allow data to move between software and hardware models in light of bus size limitations. The evaluation control logic is a finite state machine that ensures that the clock can enter the input into the register before the clock and data input enter this register.

Step 309 creates a configuration file for mapping the hardware model to the FPGA chip. In essence, step 309 assigns the circuit design component to a gate level component within a particular cell or each chip. Step 307 determines mapping a hardware model group to a particular FPGA chip, while step 309 takes this mapping result to generate a configuration file for each FPGA chip.

Step 310 generates software kernel code. The kernel is a sequence of software code that controls the entire SEmulation system. The kernel cannot be generated to this point because some of the code requires updates and hardware component evaluation. Only after step 309 proper mapping to the hardware model and the FPGA chip occurs. A more detailed discussion will be provided below with respect to FIG. 5. Editing ends at step 311.

As described above with respect to FIG. 4, the software kernel code is determined in step 310 after the software and hardware model have been determined. The kernel is the piece of software in the SEmulation system that controls the behavior of the entire system. The kernel controls the behavior of software simulation and hardware emulation. Because the kernel is located in the center of the hardware model, the simulator is integrated with the emulator. Unlike other known co-simulation systems, the SEmulation system according to one embodiment of the present invention does not require a simulator to interact with the emulator from the outside. One embodiment of the kernel is the control loop shown in FIG.

Referring to FIG. 5, the kernel begins at step 330. Step 331 evaluates the initialization code. Beginning at step 332, if bound by decision step 339, the control loop begins to iterate repeatedly until the system fails to observe the active test-bench process, in which case the simulation or emulation session is complete. . Step 332 evaluates an active test-bench component for simulation or emulation.

Step 333 evaluates the clock component. This clock component results from the test-bench process. Typically, the user tells the simulation system what type of clock signal will be generated. In one example (described above in connection with component shape analysis and reproduced herein), the clock component specified by the user in the test-bench process is as follows:

start

Clock = 0;

# 5;

Clock = 1;

# 5;

End;

In this clock component, the user determines that a logic "0" signal will be generated first, and after five simulation times, a logic "1" signal will be generated. This clock generation process continues to cycle until interrupted by the user. This simulation time is improved by the kernel.

Decision step 334 asks if any active clock edge has been detected and results in a logic evaluation within some sort of software and possible hardware model (if emulation is running). The kernel uses to detect active clock edges, and the clock signal is the clock signal from the test-bench process. If decision step 334 evaluates to "no", then the kernel proceeds to step 337. If the decision step 334 evaluates to "yes," then step 335 of updating the register and memory and step 336 of propagating the combinational component. Step 336 processes the combinatorial logic that requires time to propagate the value through the combinatorial logic network after the clock signal appears. If the value propagates through the combination component and stabilizes, the kernel proceeds to step 337.

Note that registers and combination components are modeled in hardware, so the kernel controls the emulator part of the SEmulation system. Indeed, the kernel may accelerate the evaluation of the hardware model at steps 334 and 335 whenever any active clock evi is detected. Therefore, unlike the prior art, the SEmulation system according to one embodiment of the present invention is based on component type (eg, registers, combinations) and can accelerate the hardware emulator through the software kernel. Moreover, the kernel controls the execution of software and hardware models on a periodic basis. In essence, the emulator hardware model can be characterized as a simulation coprocessor of a general-purpose processor running a simulation kernel. Coprocessors speed up simulation tasks.

Step 337 evaluates the active test-bench component. Step 338 improves simulation time. Step 339 provides a boundary for the control loop beginning at step 332. Step 339 determines if any test-bench process is active. If so, simulation and / or emulation still work, and more data is evaluated. Therefore, the kernel loops to step 332 to evaluate any active test-bench components. If the test-bench process is not active, the simulation and emulation processes are complete. Step 340 ends the simulation / emulation process. The kernel is also the main control loop that controls the operation of the entire SEmulation system. If any test-bench process is active, the kernel evaluates the active test-bench component, evaluates the clock component, detects clock edges to update registers, propagates and stores combinational logic data, and Improve.

6 illustrates one embodiment of a method for automatically mapping a hardware model to a reconfigurable board. The netlist file provides input to the hardware implementation process. The netlist details the logic functions and their interconnections. The hardware model to FPGA realization process involves three independent tasks; Includes mapping, deployment, and routing. The device is generally referred to as a "batch-and-route" device. Design devices used could be Viewlogic Viewdraw, schematic capture systems and Xilinx Xact batch and route software or Altera's MAX + PLUS II systems.

The mapping task divides the circuit design into logic blocks, I / O blocks, and other FPGA resources. Some logic functions, such as flip-flops and buffers, map directly to corresponding FPGA resources, while other functions, such as combinatorial logic, must be implemented in logic blocks using mapping algorithms.

Deployment tasks take logic and I / O blocks from mapping tasks and include assigning them to physical locations within the FPGA array. Current FPGA devices typically have three technologies; A combination of mincut, simulating annealing, and general force-directed relaxation (GFDR) is used. This technique determines the optimal placement based on various cost functions that depend on the delay along the set of critical signal paths over the entire net length or various variations of the interconnect. Xilinx XC4000 Series FPGA devices use a change in Mincut technology for the initial deployment, caused by GFDR for improvement in deployment.

Routing tasks include determining the routing paths used to interconnect the various mapped and placed blocks. Such a router, a so-called maze router, seeks the shortest path between two points. Since the routing task provides direct interconnection within the chip, the placement of the circuit associated with the chip is important.

In the offset, the hardware model may be detailed with gate netlist 350 or RTL 357. The RTL level code can be synthesized in the gate level netlist. During the mapping process, a synthesizer server 360, such as Altera MAX + PLUSII programmable logic development device system and software, can be used to produce an output file for mapping purposes. Synthesizer server 360 matches a user's circuit design component to any standard logic element (eg, standard adder or standard multiplier) in library 361, parameterized and often used logic module 362. (E.g., generate a nonstandard multiplexer or nonstandard adder), and have the ability to synthesize any logic element 363 (e.g., a table based on logic that implements the ordered logic function). The synthesizer server also removes extra logic and unused logic. The output file synthesizes or optimizes the logic required by the user's circuit design.

When some or all of the HDL is at the RTL level, the circuit design components are at a high level, allowing the SEmulation system to easily model these components using SEmulation registers or components. When some or all of the HDL is at the gate netlist level, the arc design component becomes more circuit design-specific, making it more difficult for the user circuit design component to map to the SEmulation component. Thus, the synthesizer server may create any logic element based on changes in the standard logic element or any logic element that is not parallel to such a change or library standard logic element.

If the circuit design is in the form of a gate netlist, the SEmulation system will first perform a grouping or clustering operation 351. The hardware model structure is based on the clustering process because the combinational logic and registers are separated from the clock. Therefore, logic elements that share a common major clock or gated clock signal can work better by being grouped together and placed on a chip. Clustering algorithms are based on derived connections, hierarchical extraction and canonical structure extraction. If described in structured RTL 358, the SEmulation system can decompose the function into smaller units represented by logic functional decomposition operation 359. At any stage, if logic synthesis or logic optimization is required, synthesizer server 360 may convert the circuit design into a more efficient representation based on user instructions. For clustering operation 351, the link to the synthesizer server is represented by dashed arrow 364. For structured RTL 358, the link to synthesizer server 360 is represented by arrow 365. For logic functional decomposition operation 359, the link to synthesizer server 360 is represented by arrow 366. .

Clustering operation 351 groups the logical components in an optional manner based on function and size. Clustering includes several clusters for large circuit designs or one cluster for small circuit designs. This cluster of logic elements will be used in the next step to map to the designated FPGA chip; That is, one cluster will be targeted for a particular chip and the other cluster will be targeted for the same chip as a different chip or as a first cluster. In general, logic elements within a cluster lie with the cluster within the chip, but for optimization purposes, the cluster is separated into one or more chips.

After the cluster is formed in clustering operation 351, the system performs a batch-and-route operation. First, a rough-grain placement operation 352 of the cluster in the FPGA chip is performed. Rough-grain placement operation 352 first places a cluster of logic elements on a selected FPGA chip. If necessary, the system makes synthesizer server 360 available for coarse-grain placement operation 352 as represented by arrow 367. The fine-grain placement operation is performed after the coarse-grain placement operation to fine-tune the initial placement. The SEmulation system uses a cost function based on pin usage requirements, gate usage requirements, and gate-to-gate hops to determine optimal placement for coarse-grain placement and fine-grain placement operations.

Cluster determination methods that are placed within a particular chip are based on placement costs and include cost functions (P, G, P) for two or more circuits (ie, CKTQ = CKT1, CKT2, ..., CKTN) and individual locations within the FPGA chip array. Calculated via D), where P is generally the pin usage / availability, G is the gate usage / availability in general, and D is the gate defined by the connection matrix M (shown in FIG. 7 with respect to FIG. 8). Vs. distance or number of "hops". The user's circuit design, modeled within the hardware model, is the overall combination of circuit CKTQ. Each cost function is calculated such that the calculated value of the calculated placement cost is generally (1) the minimum number of "hops" between any two circuits CKTN-1 and CKTN in the FPGA array and (2) the circuit CKTN- in the FPGA array. The placement of 1 and CKTN tends to minimize pin usage.

In one embodiment, the cost function F (P, G, D) is defined as follows.

This equation can be simplified as follows.

f (P, G, D) = C0 * P + C1 * G + C2 * D

Claim 1 (ie C0 * P) makes a first placement cost value based on the number of pins used and the number of pins available. The second term (i.e. C1 * G) makes a second placement cost value based on the number of gates used and the number of gates available. The third term (i.e., C2 * D) makes a placement cost value based on the number of hops present between the various interconnect gates in the circuit CKTQ (i.e., CKTl, CKT2, ..., CKTN). The total batch cost value is created by iteratively adding these three batch cost values. The constants CO, C1 and C2 selectively skew the total placement cost value generated from the cost function for the most important factors or factors (ie, pin usage, gate usage or gate-to-gate hop) during any placement cost calculation. Represents a weighting constant.

The batch cost is calculated iteratively when the system selects different relative values for the weighting constants C0, C1 and C2. Therefore, in one embodiment, during the rough-grain batch operation, the system selects large values for CO and C1 relative to C2. In this iteration, the system determines that the optimization of pin usage / availability and gate usage / availability is more important than the optimization of gate-to-gate hop in the initial placement of circuit CKTQ within the array of FPGA chips. In this iteration, the system determines that the optimization of gate-to-gate hop is more important than the optimization of pin usage / availability and gate usage / availability.

During the fine-grain placement operation, the system uses the same cost function. In one embodiment, the repeating steps for the selection of CO, C1 and C2 are the same as for the rough-grain operation. In another embodiment, the micro-grain placement operation includes the system selecting a smaller value for CO and C1 compared to C2.

Descriptions of these variables and equations will be discussed below. In deciding whether to place a particular circuit CKTQ within FPGA chip x or FPGA chip y (among other FPGA chips), the cost functions are pin usage / availability (P), gate usage / availability (G) and gate-to- Test the gate hop (D). Based on the cost function variables P, G, and D, the cost function f (P, G, D) produces a placement cost value for the circuit CKTQ at a specific location within the FPGA array.

Pin usage / availability (P) may also indicate I / O capacity. P _used is the number of pins used by the circuit CKTQ for each FPGA chip. P _available is the number of pins _available in the FPGA chip. In one embodiment, P _available is 264 (44 pin x 6 interconnect / chip), whereas in other embodiments, P _available is 265 (44 pin x 6 interconnect / chip + 1 spare pin). However, the specific number of pins available depends on the type of FPGA chip used, the total number of interconnects used per chip, and the number of pins used for each interconnect. Therefore, P _available can vary significantly. In order to evaluate the first term (ie C0 * P) of the cost function F (P, G, D), the P _used / P _available ratio is calculated for each FPGA chip. Therefore, for a 4x4 array of FPGA chips, 16 ratios P _used / P _available are calculated. If more pins are used for a given number of available pins, the ratio is higher. 16 Of the calculated ratios, the highest number yielding the ratio is selected. The first batch cost value is calculated from the first term C0 * P by multiplying the selected maximum ratio P _used / P _available by the weighting constant C0. Since this term depends on the calculated ratio P _used / P _available and the specific maximum ratio calculated for each FPGA chip, the placement cost value is higher for higher pin usage, and all other values are equal. . The system selects the batch that produces the lowest batch cost. P _used / P _{available, which yields} the lowest specific placement of all the maximums calculated for the various placements, is generally considered as the optimal placement within the FPGA array, and all other factors are equal.

Gate usage / availability G is based on the number of gates allowable by each FPGA chip. In one embodiment based on the position of the circuit CKTQ in the array, if the number of gates _used G is above a certain threshold, then the second placement cost C1 * G is a value indicating that the placement cannot be performed. Will be assigned. Similarly, if the number of gates used in each chip containing circuit CKTQ is below a certain threshold, then this second term C1 * G will be assigned a value indicating that the placement is feasible. Therefore, initially, the system wants to place circuit CKTQ within a particular chip, and if the chip does not have enough gates to accommodate circuit CKT1, the system concludes that this placement is a cost function that is not feasible. In general, a high number (eg, infinite) for G will represent a high placement cost value indicating that the cost function indicates that the preferred placement of the circuit CKTQ is not feasible and ensures that another placement should be determined.

In another embodiment based on the position of circuit CKTQ in the array, the ratio G _used / G _available is calculated for each chip, where G _used is the number of gates used by circuit CKTQ in each FPGA chip, where G _available is The number of gates available in each chip. In one embodiment, the system uses a FLEX 10K100 chip for the FPGA array. The FLEX 10K100 chip contains approximately 100,000 gates. Therefore, in this embodiment, G _available is equal to 100,000 gates. Therefore, for a 4x4 array of FPGA chips, 16 ratios G _used / G _available are calculated. If more gates are used for a given number of available gates, the ratio is higher. Of the 16 proportions calculated, the highest number is selected. The second placement cost value is calculated from the second term C1 * G by multiplying the selected maximum ratio G _used / G _available with the weighting constant C1. Since the second term depends on the specific maximum ratio and the calculated ratio G _used / G _available among the ratios calculated for each FPGA chip, the placement cost value is higher for higher gate usage and the other factors will be the same. will be. The system selects the circuit layout that produces the lowest cost. Of all the maximums calculated for the various placements, the particular placement that produces the lowest maximum ratio G _used / G _available is generally considered as the optimal placement within the FPGA array, and all other factors are equal.

In another embodiment, the system selects some value for C1. If the ratio G _used / G _available is greater than " 1 ", this particular arrangement is not feasible (ie at least one chip does not have enough gates for this particular placement of the circuit). As a result, the system adjusts C1 to a very high number (e.g. infinity), Clause 2 (C1 * G) becomes a very high number, and the overall deployment cost value f (P, G, D) becomes very high. will be. On the other hand, if the ratio G _used / G _available is less than or equal to " 1 ", this particular arrangement is feasible (ie, each chip has enough gates to support the worst implementation). As a result, the system does not regulate C1, and paragraph 2 (C1 * G) will determine a certain number.

Clause 3 (C2 * D) represents the number of hops between all gates requiring interconnection. The number of robs also depends on the interconnect metrics. The connection metrics provide the basis for determining the circuit path between any two gates requiring chip to chip interconnect. Not all gates require a gate-to-gate interconnect. Based on the user's original circuit design and division into specific chips in the cluster, some gates do not require any interconnection because their individual inputs and outputs are located on the same chip. However, other gates require interconnection because logic elements connected to their respective inputs and outputs are placed on different chips.

In order to understand "hop", reference is made to the connection matrix in the form of a table in FIG. 7 and the diagram in the form of a pictorial in FIG. 8. In FIG. 8, the interconnection 602 between chip F11 and chip F14 and each interconnection between the armored chips represents a 44 pin or 44 wire line. In other embodiments, each interconnect represents at least 44 pins. In other embodiments, each interconnect represents 44 pins or less.

Using this interconnect technology, data can pass in two "hops" or "jumps" from one chip to another. Thus, data can pass from chip F11 to chip F12 within one hop through interconnect 601, and the data can pass within two hops through either interconnect 600, 606 or interconnect 603, 610. Pass from F11 to chip F 33. This exemplary hop is the shortest path hop between these sets of chips. In some examples, signals are routed through various signals such that the number of hops between gates in one chip and gates in another chip exceeds the shortest path. Circuit paths that must be tested when determining the number of gate-to-gate hops are those requiring interconnection.

The connection is represented by the sum of all hops between the gates requiring the internal chip interconnect. The shortest path between any two chips can be represented by one or two "hops" using the connection metrics of FIGS. 7 and 8. However, for certain hardware model implementations, the I / O capacity limits the number of direct shortest path connections between any two gates in the array, so such signals may require longer paths (two to reach their target). Must be routed through more than one hop). Thus, the number of hops may exceed two for some gate-to-gate connections. In general, everything is the same, with fewer hops resulting in less deployment costs.

Clause 3 (ie, C2 * D) is expressed in the long form as follows.

The third term is the product of the sum of the weighting constants C2 and components S ... The sum component is the sum of all hops between each gate i and gate j in the user's circuit design requiring chip to chip interconnect. As mentioned above, not all gates require internal chip interconnect. For gate i and gate j requiring internal chip interconnection, the number of hops is determined. For all gates i and j, the total number of hops is added together.

Distance calculation may be defined as follows.

Where M is the connection matrix. One embodiment of the connection matrix is shown in FIG. The distance is calculated for each gate-to-gate connection that requires interconnection. Therefore, for each gate i and gate j comparison, the connection matrix M is tested. More specifically

The matrix is set with all chips in the array such that each chip is identifiable numbered. This confirmation number is set on top of the matrix as a column header. Similarly, this confirmation number is set up along the side of the matrix as a row header. A particular entry at the intersection of a row and a column in this matrix directly provides connection data between the chip identified by the row and the chip identified by the column, which occurs at the intersection. For calculating the arbitrary distance between chip i and chip j, the entry in the matrix Mij contains "1" for direct connection or "0" for non-direct connection. Index k represents the number of hops needed to interconnect any gate in chip j and any gate in chip i that require interconnect.

First, the connection matrix Mij for k = 1 must be tested. If the entry is "1", the direct connection is at the selected gate in chip j for this gate in chip i. therefore. The index or hop k = 1 is specified as the result of Mij, which is the distance between these two gates. At this point, other gate-to-gate connections can be tested. However, if the entry is "0", there is no direct connection.

If no direct connection exists, then k shall be tested. This new k (ie k = 2) can be calculated by multiplying the matrix Mij by itself; That is, M ² = M * M, where k = 2.

This process of multiplying M by the specific row and column entries for chip i and chip j continues until the calculated result is " 1 ", and index k is selected as the number of hops. The operation ANDs with the matrix M and includes ORing the ANDed results. If the AND operation between the matrices m _{i, l} and m _{l, j} results in a logic “1” value, then there is a connection through any chip l through hop k between the selected gate in chip i and the selected gate in chip j. ; Otherwise, there is no connection within this particular hop k, and other calculations are required. The matrices m _{i, l} and m _{l, j} are the connection metrics M defined for this hardware modeling. For a given gate i and gate j requiring interconnection, the row containing the FPGA chip for gate i in matrix m _{i, l} is logically the column containing the FPGA chip for gate j and _{ml, j} . AND is The individually ANDed components are ORed to determine if the Mij value for the index or hop k is "1" or "0". If the result is "1", there is a connection and index k is specified as the number of hops. If the result is "0", then no connection exists.

The following example illustrates this principle. See FIGS. 35A-35D. 35A shows the circuit design of the user represented as the cloud 1090. This circuit design 1090 can be simple or complex. Part of circuit design 1090 includes an OR gate 1091 and two AND gates 1092 and 1093. The outputs of the AND gates 1092 and 1093 are connected to the inputs of the OR gate 1091. These gates 1091, 1092, 1093 may be connected to other portions of the circuit design 1090.

Referring to FIG. 35B, components of such circuit 1090 that include portions containing three gates 1091, 1092, and 1093 may be constructed and disposed within FPGA chips 1094, 1095, and 1096. This particular array of FPGA chips has an interconnect technology as shown; That is, the set of interconnects 1097 connects the chip 1094 and the chip 1095, and the other set of interconnects 1098 connects the chip 1095 and the chip 1096. There is no direct connection provided between chip 1094 and chip 1096. When the components of this circuit design 1090 are placed on a chip, the system uses a predetermined interconnect technology to connect the circuit paths of the different chips.

Referring to FIG. 35C, one possible configuration and arrangement is an OR gate 1091 disposed within the chip 1094, an AND gate 1092 disposed within the chip 1095, and an AND disposed within the chip 1096. Gate 1093. The connection between OR gate 1091 and AND gate 1092 is located in a different chip and therefore requires interconnection, so a set of interconnects 1097 are used. The number of hops for this interconnect is "1". The connection between OR gate 1091 and AND gate 1093 also requires interconnection, so a set of interconnects 1097 and 1098 are used. The number of hops is "2". For the example for this arrangement, the total number of hops is "3" and the contribution from interconnects and other gates is reduced in the rest of the circuit 1090, not shown.

35D shows another arrangement example. Here, the OR gate 1091 is disposed in the chip 1094, and the AND gates 1092 and 1093 are disposed in the chip 1095. Also, other parts of circuit 1090 are not shown for educational purposes. The connection between OR gate 1091 and AND gate 1092 is required because the gates are arranged differently, so a set of 1097 is used. The number of hops for this is "1". The connection between OR gate 1091 and AND gate 1093 is required and a set of 1097 is used. The number of hops is also "1". For this arrangement example, the total number of hops is " 2 ", and pre-calculates the contribution of the other gates and the gates in the rest of circuit 1090, not shown. Therefore, on the basis of the distance D, assuming that the other factors are the same, the cost calculates the lower cost of FIG. 35 (D) than the arrangement example of FIG. 35 (C). However, all other factors are not the same. More similarly, it is based on the cost / availability G of Fig. 35D. In FIG. 35D, more than one gate is used in chip 1095 rather than the same chip in FIG. 35C. In addition, the pin usage / availability P for the chip 1095 in the placement example shown in FIG. 35C is greater than the pin usage / availability for the same chip in the other placement example shown in FIG. 35 (D). .

After coarse-grain placement, fine control of the flattening cluster placement will further optimize the placement results. This fine-grain placement operation 353 elaborates the placement initially selected by the coarse grain placement operation 352. Here, the initial cluster can be partitioned if you increase the optimization of the placement. For example, assume that logical elements X and Y are the original part of cluster A and designed for FPGA chip 10. Due to the fine grain placement operation 353, the logic elements X and Y can be designed as part of a separate cluster B or other cluster C or for the placement of the FPGA chip 2. Thus, an FPGA netlist 354 is designed that binds the user's circuit design for a particular FPGA.

Determination of the cluster division and placement method in any chip is made based on the placement cost calculated through the cost function f (P, G, D) for the circuit CKTQ. In one embodiment, the cost function used for the fine grain batching process is the same as the cost function used for the coarse grain batching process. The difference between only two batch processes is not the process itself, but the size of the clusters to be placed. The coarse grain batching process uses a larger cluster than the fine grain batching process. In another embodiment, the cost functions for the coarse grain and fine grainbatch processing are different as described above with respect to selecting the weighting constants C0, C1 and C2.

Once the placement is complete, a routing task 355 between the chips is performed. If the number of routing wires for connecting circuits deployed on other chips exceeds the available pins in the FPGA chip allocated for chip-to-chip routing, a time division multiplex (TDM) circuit is used. For example, if only 44 pins are allowed to connect a circuit where each FPGA chip is placed on two different FPGA chips, and 45 wires are required between the chips in a particular model implementation, a particular time division multiplex circuit will It will run on each chip. This particular TDM circuit couples at least two wires together. One embodiment of a TDM circuit is shown in Figures 9 (A), 9 (B), and 9 (C), which will be discussed later. Thus, a routing task can always be completed because the pins are arranged in a time division multiplex between the chips.

Once the placement and routing of each FPGA is determined, each FPGA is configured with optimized working circuitry, and thus the system generates a "bitstream" configuration file 356. In the altera technique, the system generates one or more programmer object files (-pof). Other generated files include SRAM object files (.sof), JECED files (.jed), hexadecimal (Intel-format) files (.hex), and table text files (.ttf). Altera The MAX + PLUS II programmer uses POF, SOF, and JEDEC files with Altera hardware programmable devices to program the FPGA array. Optionally, the system generates one or more raw binary files (.rbf). The CPU modifies the .rbf file and programs the FPGA array through the PCI bus.

At this point, the configured hardware prepares for hardware start-up 370. This completes the automatic configuration of the hardware model on the reconfigurable board.

Referring back to the TDM circuit that causes the pin output groups to be time multiplexed together so that only one pin output is actually used, the TDM circuit is essentially a multiplexer with at least two inputs (for two wires), one output, And register couples configured in the loop as selector signals. If the SEmulation system requires more wires to group together, more input and loop registers can be provided. Like selector signals for TDM circuits, some registers configured in the loop provide a suitable signal for the multiplexer, so that at any time period, one of the inputs is selected as an output and another input is selected as an output at another time period. . Thus, the TDM circuit manages to use only one output wire between the chips, so that the hardware model of the circuit implemented on a particular chip for this embodiment is achieved using 44 pins instead of 45 pins. Thus, the routing task can always be completed because the pins can be divided in time division multiplex form across the chip.

9 (A) shows an overview of the pin out problem. Since this requires a TDM circuit, Fig. 9B provides the TDM circuit for the transmitting side, and Fig. 9C provides the TDM circuit for the receiving side. These figures show only one specific embodiment where the SEmulation system requires one wire instead of two wires between the chips. If two or more wires must be joined together in a time multiplex arrangement, one of ordinary skill in the art can form suitable strains due to the following techniques.

9 (A) shows one embodiment of a TDM circuit in which the SEmulation system combines two wires in a TDM configuration. Two chips 990 and 991 are provided. Circuit 960, which is part of the completed user circuit design, is modeled and placed on chip 991. Circuit 973, which is part of the completed user circuit design, is modeled and placed on chip 990. Several interconnects are provided between circuits 960 and 973, including interconnect 994, interconnect 992, and a group of interconnects 993. In this embodiment the number of interconnects is 45 total. If, in one embodiment, each chip provides only 44 pins for these interconnects, one embodiment of the present invention is time multiplexed to require only one interconnect between these chips 990 and 991. It provides at least two interconnects.

In this embodiment, the group of interconnects 994 will continue to use 43 pins. For the 44th and last pins, TDM circuits according to one embodiment of the present invention can be used to couple interconnects 992 and 993 together in a time division multiplexed form.

9B shows one embodiment of a TDM circuit. Modeled circuitry (or portions thereof) 960 in FPGA chip 991 provides two signals on wires 966 and 967. These wires 966 and 967 are output to the circuit 960. These outputs are generally coupled to the modeled circuit 933 of the chip 990 (see FIGS. 9A and 9C). However, the availability of only one pin for these two output wires 966 and 967 prevents direct pin-to-pin connections. Because outputs 966 and 967 are transmitted unidirectionally to other chips, suitable transmit and receiver TDM circuits are provided to couple these lines together. One embodiment of the transmitting side TDM circuit is shown in Fig. 9B.

The transmission-side TDM circuit includes AND gates 961 and 962, each output 970 and 971 of the gates coupled to an input of an OR gate 963. The output 972 of the OR gate 963 is the output of the chip assigned to one pin and connected to the other chip 990. One set of inputs 966 and 967 for AND gates 961 and 962 are provided by circuit model 960, respectively. The other set of inputs 968 and 969 are provided by a loop register method that functions as a time division multiplex select signal.

The loop register method includes registers 964 and 965. Output 995 of register 964 is provided to an input of register 965 and an input 968 of AND gate 961. Output 996 of register 965 is provided to an input of register 964 and an input 968 of AND gate 962. Each register 964 and 965 is controlled by a common clock source. At any given time, only one output 995 or 996 provides a logic "1". The other output provides a logic "0". Thus, after each clock edge, logic "1" shifts between outputs 995 and 996. This in turn provides "1" for AND gate 961 or "1" for AND gate 962 and "selects" either wire 966 or wire 967. Thus, data on wire 972 resides in wire 966 or wire 967 from circuit 960.

One embodiment of the receiving side of the TDM circuit is shown in Fig. 9C. In chip 991 (FIGS. 9A and 9B), signals from wires on wires 966 and 967 are coupled to appropriate wires 985 or 986 for circuit 973 in FIG. 9C. Should be. Time division multiplex signal from chip 991 enters from wire / pin 978. The receiving TDM circuit couples these signals on wire / pin 978 to the appropriate wires 985 and 986 for circuit 973.

The TDM circuit includes input registers 974 and 975. Signals on wire / pin 978 are provided to these input registers 974 and 975 via wires 979 and 980, respectively. Output 985 of input register 974 is provided to a suitable port of circuit 973. Similarly, the output 986 of the input register 975 is provided to an appropriate port of the circuit 973. These input registers 974 and 975 are controlled by loop registers 976 and 977.

The output 984 of the register 976 is coupled to the input of the register 997 and the clock input 981 of the register 974. The output 983 of the register 997 is coupled to the input of the register 976 and the clock input 982 of the register 975. Each register 976 and 977 is controlled by a common clock source. At any given time, only one enable input 981 or 982 becomes a logic "1". The other input is a logic "0". Thus, after each clock edge, logic “1” shifts between enable input 981 and output 982. This in turn is suitably coupled to circuit 973 via wire 979 or 980.

As briefly discussed with respect to FIG. 4, an address pointer according to an embodiment of the present invention will now be discussed in more detail. To repeat, some address pointers are placed on each FPGA chip of the hardware model. In general, the first purpose of implementing an address pointer is to provide a system for transferring data between a particular FPGA chip and software model 315 in hardware model 325 via a 32-bit PCI bus 328 (see FIG. 10). Is to enable it. More specifically, the first purpose of the address pointer is to address each of the FPGA chip and respective address spaces within the software / hardware boundary of the banks 326a-326d of the FPGA chip due to bandwidth limitations of the 32-bit PCI bus (ie, REG, S2H). , H2S and CLK). Although a 64-bit PCI bus is implemented, these address pointers are still needed to control data transfer. Thus, if the software model has five address spaces (ie, REG read, REG write, S2H read, H2S write, and CLK write), then each FPGA chip has five address pointers corresponding to these five address spaces. Each FPGA needs these five address pointers because the particular selected word in the selected address space being processed remains on any one or more FPGA chips.

The FPGA I / O controller 381 selects specific address spaces (ie, REG, S2H, H2S, and CLK) corresponding to software / hardware boundaries by using spatial indexes. Once the address space is selected, the specific address pointer corresponding to the selected address space in each FPGA chip selects the specific word corresponding to the same word in the selected address space. The maximum size of the address pointer in each FPGA chip and the address space in the software / hardware boundary is dependent on the memory / word capacity of the selected FPGA chip. For example, one embodiment of the present invention uses an alternate FLEX 10K family of FPGA chips. Thus, the estimated maximum size for each address space is: REG, 3,000 words; CLK, 1 word; S2H, 10 words; And H2S, 10 words. Each FPGA chip can hold approximately 100 words.

The SEmulation system is characterized by allowing the user to start, assert the input value, and check the value at any time during the SEmulation process. To provide simulator adaptability, the SEmulator must be visible to the user, regardless of whether the component's internal implementation is software or hardware. In software, the coupling part is modeled and the values are calculated during the simulation process. Thus, these values are completely "visible" for the user to access at any time during the simulation process.

However, in the hardware model, the coupling component is not directly "visible". Although registers are easily and directly accessible (ie, read / write) by the software kernel, the combined components are more difficult to determine. In FPGAs, most coupled components are modeled as lookup tables to increase gate utilization. As a result, lookup table mapping provides effective hardware modeling but impairs the visibility of most combined logic signals.

Despite these problems due to lack of visibility of the mating components, the SEmulation system can reinforce or regenerate the mating components for inspection by the user after hardware acceleration mode. If your circuit design has only coupling and resistor components, the values of all coupling components can be derived from the resistor components. That is, the coupling component is constructed from and includes various registers in accordance with specific logic functions required by the circuit design. The SEmulator has a hardware model of registers and coupling components only, and consequently the SEmulator reads all register values from the hardware model and then augments or regenerates all coupling components. Due to the overhead required to perform this regeneration process, the mating part regeneration may not be performed at all times; Rather, it is performed only upon request by the user. In fact, one of the advantages of using hardware models is to speed up the simulation process. Determining the coupled part value in every cycle (or even most cycles) further reduces the simulation speed. In any case, checking the register value alone should be sufficient for most simulation analysis.

The process of regenerating the combined part value from the register value ensures that the SEmulation system is in hardware acceleration mode or ICE mode. Otherwise, the software simulation provides the user with a combined component value. The SEmulation system retains the combined component values as well as the registers remaining in the software model before the start of hardware acceleration. These values remain in the software model until further overwrite operations by the system. Since the software model has the combined part value and register value from the time period just before the start of hardware acceleration, the combined part regeneration process includes updating some or all values of the software model in response to the updated input register value.

The combined component creation process is as follows: First, if required by the user, the software kernel reads all output batts of the hardware register components from the FPGA chip into the REG buffer. This process involves the DMA transfer of register values in the FPGA chip into the REG address space through a chain of address pointers. Placing a register value in the hardware model into an REG buffer in the software / hardware boundary allows the software model to access the data for further processing.

Second, the software kernel compares register values before and after hardware acceleration begins. If the register value before hardware acceleration is equal to the value after hardware acceleration, the value of the combined component is not changed. Instead of extending the time and resources for regenerated coupling results, these values can be read from a software model with the coupling component values stored from the time just before hardware acceleration. On the other hand, if one or more of these register values change, one or more coupling components may change the value according to the changed register value. These coupling parts must be regenerated in the next third step.

Third, for registers with different values from pre-acceleration and post-acceleration comparisons, the software kernel schedules fan-out coupling components to the event queue. Here, a register whose value changes during acceleration detects an event. More similarly, these coupling components will produce different values according to these changed register values. Despite any change in the value of these coupling parts, the system ensures that these coupling parts evaluate these changed register values in the next step.

Fourth, the software kernel then executes a standard event simulation algorithm to propagate the value change from the register to all the combined parts of the software model. In other words, the register values that changed during the time interval from pre-acceleration to post-acceleration are passed to all lower coupling components that depend on these register values. These coupling parts then evaluate these new register values. In accordance with the fan out and propagation principle, the other second level coupling components disposed below from the first level coupling components directly dependent on the changed register values must evaluate the changed data. This progression of register values to other parts placed underneath can contribute to the purpose of the fan out network. Thus, these coupled components placed below and affected by the changed register values are updated in the software model. None of the mating part values are affected. Thus, if only one register value changed during the time interval from acceleration to acceleration, and only one coupling part is affected by this register value change, then only this coupling part will re-evaluate the value due to this changed register value. . Other parts of the modeled circuit will not be affected. For this small change, the mating part regeneration process will occur relatively quickly.

Finally, when event progress is complete, the system is ready for any mode of operation. In general, the user wants to check the value after a long run. After the combined part regeneration process, the user simulates pure software for debug / test purposes. However, at another point in time, the user hardware accelerates to the next desired point. In other cases, the user would like to proceed further to the ICE mode.

In summary, coupled component regeneration involves using register values to update coupled component values in a software model. When any register value changes, the changed register value will go through the register's fan out network when the value is updated. When the register value does not change, the software model value will not change, so the system does not need to rebuild the coupling part. In general, hardware accelerated operation will occur for several hours. As a result, many register values change, affecting many of the combined component values placed under the fan out network of those registers with the changed values. In such a case, the mating part regeneration process may be relatively slow. In other cases, after a hardware accelerated run, only a few register values may change. The fan out network for registers with changed register values can be small, and the combined component regeneration process can be relatively fast.

Ⅳ. Emulation Using Targeted System Mode

10 illustrates a SEmulation system architecture in accordance with an embodiment of the present invention. 10 illustrates the relationship between a software model, a hardware model, an emulation interface, and a target system when the system is operating in an in-circuit emulation mode. As noted above, the SEmulation system includes a general purpose microprocessor and reconfiguration hardware board interconnected by a high speed bus such as a PCI bus. The SEmulation system compiles your circuit design and generates emulation hardware configuration data during the hardware model to reconfiguration board mapping process. The user then simulates the circuit through a general-purpose processor, hardware accelerates the simulation process, emulates the circuit design into the target system via the emulation interface, and then performs post simulation analysis.

Software model 315 and hardware model 325 are determined during the compilation process. The emulation interface 382 and the target system 387 are provided to the system during the in-circuit emulation mode. At the user's discretion, the emulation interface and target system do not need to be initially coupled to the system.

The software model 315 includes a kernel 316 that controls all system and four address spaces for software / hardware boundary-REG, S2H, H2S and CLK. The SEmulation system maps the hardware model to four address spaces of main memory according to different component types and control functions: REG space 317 is designed for register components; CLK space 320 is designed for a software clock; S2H space 318 is designed for the output of software test bench components for hardware models; H2S space 319 is designed for the output of a hardware model for software test bench components. These dedicated I / O buffer spaces are mapped into the kernel's main memory space during system initialization time.

The hardware model includes an FPGA chip and several banks 326a-326d of the FPGA chip of the FPGA I / O controller 327. Each bank (eg, 326b) includes at least one FPGA chip. In one embodiment, each bank consists of four FPGA chips. In a 4x4 array of FPGA chips, banks 326b and 326d may be low banks and banks 326a and 326c may be high banks. The mapping, placement and routing of specific hardware modeling user circuit design elements for a particular chip and its interconnects are discussed with reference to FIG. 6. The interconnect 328 between the software model 315 and the hardware model 325 is a PCI bus system. The hardware model includes a PCI interface 380 and a control unit 381 to control data traffic between the PCI bus and the banks 326a-326d of the FPGA chip while maintaining the throughput of the PCI bus. Each FPGA chip further includes several address pointers, where each address pointer corresponds to a respective address space (ie, REG, S2H, H2S, and CLK) in the software / hardware boundary, bank of the FPGA chip 326a Combine the data between each of these address spaces and each FPGA chip within -326d).

Communication between software model 315 and hardware model 325 occurs via the DMA engine or address pointer of the hardware model. Optionally, communication occurs through both the address point and the DMA engine in the hardware model. The kernel initiates DMA transfer with an evaluation request through a direct mapping I / O control register. The REG space 317, CLK space 320, S2H space 318, and H2S space 319 are each an I / O data path line (I / O data path line) for data transfer between software model 315 and hardware model 325. 321, 322, 323 and 324).

Double buffering is required for all first inputs to the S2H and CLK space since these spaces take several clock cycles to complete the update process. Double buffering prevents disruption to internal hardware model states that can cause race conditions.

S2H and CLK space are the main inputs from the kernel to the hardware model. As noted above, the hardware model substantially holds both the coupling components and the resistor components of the user's circuit design. In addition, the software clock is modeled in software and provided at the CLK I / O address to interface with the hardware model. The kernel accelerates simulation time, finds active test bench parts, and evaluates clock parts. When any clock edge is detected by the kernel, the registers and memory are updated and the values passed through the coupling components. Thus, any change in value in these spaces triggers the hardware model to change the logic state if the hardware acceleration mode is selected.

During the in-circuit emulation mode, the emulation interface 382 is coupled to the PCI bus 328 to communicate with the hardware model 325 and the software model 315. The kernel 316 controls the hardware model as well as the software model during the hardware acceleration simulation mode and the circuit emulation mode. Emulation interface 382 is coupled to target system 387 via cable 390. Emulation interface 382 includes interface port 385, emulation I / O control 386, target-to-hardware I / O buffers (T2H) 384, and hardware-to-target I / O buffers (H2T) (383). ).

The target system 387 includes a connector 389, a signal input / output interface socket 388, and other modules or chips that are part of the target system 387. For example, target system 387 may be an EGA video controller and the user's circuit design may be one specific I / O controller circuit. The user circuit design of the I / O controller for the EGA video controller is fully modeled in the software model 315 and partially modeled in the hardware model 325.

The kernel 316 of the software model 315 controls the in-circuit emulation mode. Control of the emulation clock is present in the software, gate clock logic, and gate data logic via the software clock so that setup and holding time is in-circuit. It will occur during emulation mode. Thus, the user can start, stop, single step, value assertion, and value check at any time during the in-circuit emulation process.

For this task, all clock nodes between the target system and the hardware model are identified. In the target system, the clock generator is disabled, the clock port from the target system is disconnected, or the clock signal from the target system is prevented from reaching the hardware model. Instead, the clock signal starts with another form of software generated clock or test bench processing, so that the software kernel detects an active clock edge and thus triggers data evaluation. Thus, in ICE mode, the SEmulation system uses a software clock to control the hardware model instead of the target system clock.

In order to simulate user circuit design operation within the environment of the target system, the primary input (signal input) and output (signal output) signals between the target system 40 and the modeled circuit design are sent to the hardware model 325 for evaluation. Is provided. This is accomplished through two buffers: target to hardware buffer (T2H) 384 and hardware to target buffer (H2T) 383. Target system 387 uses T2H buffer 384 to apply an input signal to hardware model 325. The hardware model 325 uses the H2T buffer 383 to deliver the output signal to the target system 387. In this in-circuit emulation mode, the hardware model sends and receives I / O signals through the T2H and H2T buffers instead of the S2H and H2S buffers. This is because the system uses the target system 387 instead of the test bench processing in the software model 315 to evaluate the data. Because the target system runs substantially faster than the speed of software simulation, the in-circuit emulation mode will run at higher speeds. The transmission of these input and output signals occurs on the PCI bus 328.

In addition, bus 61 is provided between emulation interface 382 and hardware model 325. This bus is similar to the bus 61 of FIG. This bus 61 allows the emulation interface 382 and the hardware model 325 to communicate via the T2H buffer 384 and the H2T buffer 383.

Typically, target system 387 is not coupled to the PCI bus. However, the combination may be realized if the emulation interface 382 is integrated into the design of the target system 387. The signal between the target system 387 and the hardware model 325 will still pass through the emulation interface.

Ⅴ. Post Simulation Analysis Mode

The SEumlation system of the present invention supports a value change dump (VCD) and a simulator function widely used for post simulation analysis. Essentially, the VCD provides a historical record of all inputs and selected register outputs of the hardware model, allowing the user to review the various inputs and resulting outputs of the simulation process during later post simulation analysis. To support the VCD, the system logs all inputs to the hardware model. For output, the system logs all values of hardware register components at user-defined logging frequencies (e.g., 1 / 10,000 writes / cycle). The logging frequency determines how the output value is recorded. For a logging frequency of 1 / 10,000 recordings / cycle, every 10,000 cycles is recorded in the output value. The higher the logging frequency, the more information is recorded for later post simulation analysis. The lower the logging frequency, the less information is stored for later post simulation analysis. Since the selected logging frequency has a causal relationship with the SEmulation rate, the user must select the logging frequency carefully. Higher logging frequencies reduce the speed of SEmulation because the system spends time and resources to write output data by performing I / O operations to memory before further simulations are performed.

With regard to post simulation analysis, the user selects a particular point at which the simulation is targeted. If the logging frequency is 1/500 writes / cycle, the register value writes points 0, 500, 1000, 1500, etc. every 500 cycles. If the user wants the result at point 610, for example, the user selects the recorded point 500 and simulates until the simulation reaches point 610. During the analysis phase, the analysis rate is equal to the simulation rate because the user first accesses data for point 500 and then simulates to point 610. It is noted that at higher logging frequencies, more data is stored for post simulation analysis. Thus, for a logging frequency of 1/300 recording / cycle, data for points 0, 300, 600, 900 and the like are recorded every 300 cycles. To get the result at point 610, the user selects the initially recorded point 600 and simulates it with point 610. When the logging frequency is 1/300 rather than 1/500, it reaches faster at the target point 610 during post simulation analysis. However, this is not always the case. In combination with the logging frequency, a particular analysis point determines how quickly a post simulation analysis point is reached. For example, the system can reach point 523 sooner if the VCD logging frequency is 1/500 rather than 1/300.

The user then performs the analysis by running a software simulation with input logs for the hardware model to calculate a value change dump of all hardware components after SEmulation. The user selects any register log point in a timely manner and starts a value change dump where the log point progresses in a timely manner. This value change dump method can be linked to any simulation waveform viewer for post simulation analysis.

VCD Ordering System

One embodiment of the invention is a system for creating a VCD order without a simulation return. According to one embodiment of the present invention, VCD ordering techniques as described herein incorporate the following high level attributes; (1) RCC based parallel simulation history compression and recording, (2) RCC based parallel simulation history decompression and VCD file generation, and (3) custom software regeneration for selected simulation target range and design overview without simulation return. Each of these attributes will be described in more detail below.

During the debug session, the EDA tool (hereinafter referred to as the RCC system incorporating various aspects of the present invention) records the first input from the test bench process so that any simulation portion is played. The user can optionally command the EDA tool, or the RCC system, to dump hardware status information into the VCD file from any simulation time range during later analysis. The user can then immediately begin debugging his design within the selected simulation time range. If the debugger the user seeks to repair does not include the selected simulation time range, the user can select a different simulation time range to dump to the VCD file. The user can then analyze these new VCD files. Due to this VCD ordering feature, the user may stop the simulation at any point and require the creation of another optional VCD file on demand from any desired simulation time start point to any simulation time end point.

In a typical debug session, the user debugs his design using the RCC system shown in FIG. During the first simulation, the user quickly simulates his design at any target end simulation time from the target start simulation time, referred to herein as the simulation session range . During this fast simulation, the highly compressed form of the first input is recorded in an "input history" file so that part of the simulation session can be played. At the end of the simulation session scope, the RCC system stores hardware state information from these end points in the "simulation history" file so that if desired, the user can return to debugging the design past these end points.

At the end of the fast simulation run, the user analyzes the results and detects without exception some problems with his design. The user then assumes that the cause of the problem (i.e., the bug) is located within a broader simulation session range and then within a certain narrow simulation time range called the simulation target range . For example, if the simulation session range includes 1,000 simulation time steps, the narrower simulation target range includes only 100 simulation time steps at a particular location within the wider simulation session range.

Once the user has guessed about the exact location of the simulation target range to isolate the bug, the RCC system decompresses the first compressed input in the input history file and passes the uncompressed first input to the hardware model for evaluation. Simulate quickly from the start. When the RCC system reaches the simulation target range, it dumps the evaluated results (eg, hardware node values and register status) into the VCD file. The user can then analyze this area more carefully by replaying his design with a VCD file starting at the start of the simulation target range, or even immediately after the start of the simulation, rather than returning the simulation from the start of the simulation session range. . This feature of storing hardware state from a simulation target range, such as a VCD file, saves a significant amount of debug time that is not wasted during a simulation restart.

Referring again to FIG. 83, there is shown a high level RCC system incorporating one embodiment of the present invention. The RCC system includes an RCC calculation system 2600 and an RCC hardware accelerator 2620. As described elsewhere in this patent specification, RCC calculation system 2600 includes computational resources needed to allow a user to simulate the user's entire software modeling design in software and to control hardware acceleration of the hardware modeling portion of the design. do. For this purpose, the RCC calculation system 2600 may include a CPU 2601, various clocks 2602 (including software clocks described in various patent specifications), test bench processes 2603, and the like required by various components of the RCC system. System disk 2604. In contrast to some conventional hardware based event history buffers, system disks are used to write compressed data rather than small hardware RAM buffers. Although not shown, RCC calculation system 2600 includes a bus subsystem that provides computational power to circuit designers to run diagnostics, various software, and management files among various tasks performed by the calculation system. .

In another session of this patent document, an RCC hardware accelerator 2620, called an RCC array, includes a reconstruction array of logical elements (eg, FPGAs) that a user can model at least a portion of a user design in hardware to speed up the debugging process. . For this purpose, the RCC hardware accelerator 2620 includes an array of reconfigurable logic elements 2621 that provide a hardware model of the user design portion. The RCC calculation system 2600 is securely fastened to the RCC hardware accelerator 2620 via a software clock and bus system, such as the one described in various places in this patent document, with portions of the bus as lines 2610 and 2611 in FIG. 83. Shown.

The custom VCD of the present invention will be discussed with reference to FIG. 84. 84 shows timelines-t0, t1, t2 and t3 at several simulation times. The simulation session range is between simulation time t0 and simulation time t3, the path of which includes simulation times t1 and t2. Simulation time t0 represents a first simulation time within the scope of a simulation session that starts a fast simulation. This simulation time t0 represents the first simulation time during any separable simulation session, or simulation session range. In other words, suppose today's debug session tests a simulation session range of t = 10,000 to t = 12,000. The user assumes that a particular bug is placed between t = 10,500 and t = 10,750. For this simulation session range, the simulation time t0 is t = 10,000. It is assumed that a particular bug is deployed and repaired for the simulation session range t = 10,000 to t = 12,000. Then, the user moves to the next simulation session range t = 12,000 to t = 15,000 tomorrow. Here, simulation time t0 is t = 12,000. In some cases, simulation time t0 represents the first simulation time immediately during the first bug session of the user design (ie t0 corresponds to t = 0).

Similarly, simulation time t3 represents the final simulation time for the selected simulation session range. In other words, today's debug sessions include simulation session coverage extensions from t = 14,555 to t = 16,750. For this simulation session range, the simulation time t3 is t = 16,750. It is assumed that a particular bug is deployed and repaired for this simulation session range t = 14,555 to t = 16,750. The user then moves over the next simulation session range t = 16,750 to t = 19,100. Here, simulation time t3 is t = 19,100. In some cases, simulation time t3 represents the final simulation time during the final debug session of the user designer.

The user can continue the simulation beyond this simulation time t3 if desired, but for the move the user is focused on debugging his design during simulation time t0 to t3, ie the current simulation session scope. Typically, when a bug is ironed during the current simulation session scope, the user will simulate his design over the simulation time t3 to the next simulation session scope.

In this greedy representation of the simulation session range, these simulation time periods t0-t3 are essentially adjacent to each other; In other words, the simulation times t0 and t1 are not immediately adjacent to each other. Indeed, the simulation times t0 and t1 can be thousands of individual simulation time periods.

Since one embodiment of the invention is implemented in an RCC system, reference will be made to various components of the RCC system shown in FIG. First, the input and simulation history generation behavior of the RCC system will be discussed. This generation operation includes some form of data compression for the first input and some form of recording of the compressed first input. Second, the VCD creation operation of the RCC system will be discussed. This VCD generation operation includes decompressing the first input to replay the simulation history and dumping the hardware state into the VCD file during the simulation target range. Third, the VCD review process will be discussed. Although the term "simulation history" is sometimes used, this does not mean that the entire debug session includes software simulation. Indeed, the RCC system creates a VCD file from the hardware state and the software model is used only for later analysis of the VCD file.

Input and simulation history generation—compression and recording

Initially, the user models the software design in the RCC calculation system 2600 of FIG. For some parts of the design, the RCC calculation system 2600 generates a hardware model of the design based on a hardware description language (eg, VHDL). The hardware model is configured in an array of reconfigurable logic elements 2621 that are part of the RCC hardware accelerator 2620. With this setup, the user simulates a software design in the RCC calculation system 2600, accelerates a portion of the design (ie, a simulation time step or distinct physical section of the circuit) using the RCC hardware accelerator 2620, or Combines simulation and hardware acceleration.

The user has just completed his final circuit design. This is the time to debug the design to find the defect. If the user has debugged a previous version of the design beforehand, he thinks of some places where the bug was placed. On the other hand, if this is the first debug session for the new design, the user should have some idea about the location of the potential bug. In either case, some guesswork is usually required to place the bug. For this discussion, assume that you debug your design during the first hour.

When debugging a design, the user selects the scope of the simulation session. In theory, this simulation session range can be any length of simulation time. In practice, however, the simulation session range should be chosen long enough to isolate some bugs in the design and long enough to minimize the number of debug sessions that need to be moved quickly and completely debug the design. Obviously, the simulation session scope of two or three simulation time steps will not indicate the presence of any bugs. In addition, this small simulation session scope will force the user to perform many repetitive tasks that will slow debug processing. If the selected simulation session scope is one million simulation steps, too many bugs appear on their own, making it difficult for the user to execute a more focused attack on the problem.

Once the user selects the simulation session range, he instructs the RCC system to speed up the simulation from simulation time t0 to simulation time t3 as shown in FIG. As noted above, independent simulation times t0 to t3 may be any selected range, but simulation time t0 represents the start of the simulation and simulation time t3 represents the final simulation time for the simulation session range.

At simulation time t0, a quick simulation starts in RCC calculation system 2600. Fast simulation is performed from simulation time t0 to simulation time t3 instead of the normal simulation mode because the representation of the software model is not needed during this time period. As discussed elsewhere in this patent specification, the regeneration operation requires the RCC calculation system 2620 to receive hardware state information (e.g., node values, register state), thereby providing more sophisticated logic elements (e.g., The join logic is regenerated in software for further analysis by the user. Of course, some users want to observe the software model during the simulation process, in which case the RCC calculation system 2600 does not perform a quick simulation. In this case, the simulation process is slower due to the additional time required by the RCC calculation system 2600 to regenerate the software model from the first output of the hardware model.

Initially, a complete state design, such as software model state and hardware model registers and node values, is stored at simulation time to in a file called the "simulation history" file on the system disk. This allows the user to load the design state into the RCC system at any time in the future for debugging. During this fast simulation period for the simulation session range from simulation time t0 to simulation time t3, the RCC calculation system 2600 applies two distinct processes to the first input I _P in parallel. The raw first input from test bench processing 2603 is provided to line 2610 for RCC hardware accelerator 2620 for evaluation. At the same time, the same first input from the test bench process is compressed and written to the system disk as a separate file called an "input history" file so that the entire history of the first input can be collected for the user to play back any part of the simulation later. have. In particular, the first input corresponding to simulation time t0 to simulation time t3 is compressed and stored on the system disk.

When the RCC hardware accelerator 2620 receives the first input I _P from the test bench process 2603, the accelerator processes the first input. As a result, the hardware state of the hardware model is likely to change when various logic and other circuit devices evaluate the data. During the time period from simulation time t0 to simulation time t3, the RCC system does not have to wait for the RCC calculation system 2600 to perform logic generation because there is no benefit for the user to elaborately debug in the design during the fast simulation period. The RCC system also does not store the first output (eg, hardware node value and register state) at all. It is noted that while the RCC calculation system 2600 compresses the first input to write to the "input history" file, the RCC hardware accelerator 2620 does not evaluate the low and uncompressed first input. In another embodiment, the RCC system does not compress the first input to write to the input history file.

Why does the RCC calculation system 2600 pass the first input to the RCC hardware accelerator for evaluation when the output is not stored at all during a fast simulation cycle. The RCC system needs to store the hardware state of the design based on the evaluation of the first input from the start of the simulation to the simulation time t3. An accurate snapshot of the hardware model state cannot be obtained at simulation time t3 if the hardware model does not evaluate the entire history of the first input from the start to point t3 but not at the input from simulation time t3. Logic circuits have memory properties that affect the evaluation results based on the input order. Thus, if the first input from the simulation time t3 (or the simulation time just before the simulation time t3) is supplied to the hardware model for evaluation, the hardware model will show an incorrect state at the simulation time t3.

Why is the hardware model state stored during simulation time t3? Large designs with more than one million gates and more than one million simulation steps cannot be debugged in a relatively short time period. The user needs multiple simulation sessions to debug this design. To quickly move from one simulation session to the next, the RCC system saves the hardware state (with the compressed first input) from simulation time t3 so that the user debugs the next simulation session range starting at simulation time t3. can do. Due to the stored hardware model state, the user does not need to simulate immediately after the start of the simulation; Rather, the user can debug the design from simulation time t0 to simulation t3 and return quickly and conveniently to simulation time t3. The hardware model state at simulation time t3 stored in the simulation history file represents a correct snapshot of the design, which is a complete history reflection of the first input up to that point.

The hardware model in the RCC hardware accelerator 2620 provides the internal hardware state on the line 2611 to the RCC calculation system 2600 so that the RCC calculation system 2600 can be configured with various logic of the software model if needed and targeted by the user. An element (eg join logic) can be constructed or regenerated. However, as mentioned above, the user is not concerned with observing software simulations during a quick simulation of the simulation session range. Thus, since internal hardware states are not tested for current bugs by the user, these internal hardware states from the RCC hardware accelerators are not stored on the system disk.

At the end of simulation time t3, or at the end of the simulation session range, this particular fast simulation operation is stopped. The evaluation result or first output (eg, register value) from the design hardware model in the RCC hardware accelerator 2620 corresponding to the simulation time t3 is stored in the simulation history file. This is done so that when the user debugs the design from simulation time t0 to simulation time t3, the user proceeds directly to simulation time t3 for further debugging as needed. The user does not need to rerun the simulation from simulation time t0 to debug his design at some point beyond simulation time t3.

In summary, from simulation time t0 to simulation time t3 (i.e., simulation session range), the user may compress and store the same first input to the system disk for future reference, while at the same time from test bench processing 2603 on line 2610. Accelerate the design by supplying a first input of the RCC hardware accelerator 2620. The RCC calculation system 2600 needs to store the first input (compressed or uncompressed) in the input history file to replay the debug session. Compression operation occurs concurrently with data evaluation within RCC hardware accelerator 2620. Finally, at simulation time t3, the end of the simulation session scope, the RCC system stores the state information of the hardware model in the simulation history file.

In one embodiment of the invention, all recorded and compressed first inputs from the simulation session range are part of the same file which will later be modified for hardware state information from simulation time t3. In another embodiment, the information stored from the simulation session range and the hardware state information at simulation time t3 are stored as distinct files on the system disk. Similarly, any of the aforementioned files can be transformed into custom VCD information that is later generated for the simulation target range. Optionally, the VCD on-demand information can be stored as a separate VCD file in the system disk that is separated from the compressed first input file and the hardware state information file at simulation time t3. In other words, according to one embodiment of the present invention, the input history file, the simulation history file and the VCD file can be integrated with each other in one file. In another embodiment, the input history file, simulation history file, and VCD file may be separate files. In addition, the input history file and the simulation history file can be combined into one file separate from the VCD file.

Compression methods will now be discussed. According to one embodiment of the invention, the compression of the RCC system allows a compression ratio of 20X for the first input event with 10% input events per simulation time step. Thus, a large ASIC design of more than one million gates may require 200 first input events. For 10% input events per simulation time step, approximately 20 inputs need to be compressed and recorded. If each input signal is 2 bytes, 20 input signals require 40 bytes of data to be processed at the first input per simulation time step. For a compression ratio of 20X, 40 byte data can be compressed to 2 bytes of data per simulation time step. Thus, for a design that requires about one million simulation steps, the RCC system compresses the first input with two megabytes of data. Files of this size can be easily managed by any computational file system and waveform viewer. In one embodiment, ZIP compression is used.

According to one embodiment, the first input compression is performed concurrently with the first input evaluation by the RCC hardware accelerator 2620; Input story file generation occurs concurrently with the first input evaluation. Thus, the compression method does not provide a direct adverse effect on RCC system performance. One possible bottleneck is the phenomenon of writing a compressed first input to the system disk. However, because the data is highly compressed, the RCC system experiences a slowdown of less than 5% for most designs that run at 50,000 simulation time steps per second.

For a particular manner in which recording is controlled in the RCC system, the user first uses $ rcc (record) to initialize the RCC recording feature in accordance with one embodiment of the present invention:

$ rcc (record, name, <disk space>, <checkpoint control>);

The extension of argument names, <disk space>, and <checkpoint control> will now be discussed. The "name" argument is the record name for the current simulation session scope. Different names are required to distinguish different simulation runs of the same design. A distinct record name is required for off-line VCD on-demand debugging.

The <disk space> argument is an optional parameter for indicating the maximum disk space (in MB units) allocated for RCC system write processing. The combined value is 100 MB. The RCC system only records the last portion of the current simulation session range within a particular disk space. In other words, if the <disk space> value is specified as 100 MB but the current simulation session range is set to 140 MB, the RCC system writes only the last 100 MB and discards the first 40 MB of the compressed first input. This aspect of the invention is one advantage for defect analysis. In one embodiment of the present invention, the test bench process has a self test function to detect simulation defects and stop the simulation. The final history of the RCC simulation can provide most of the information for the defect analysis.

The <checkpoint control> argument is an optional parameter that indicates the number of simulation time steps needed to perform a full state checkpoint. The default is 1,000,000 times. As with most conventional compression algorithms, the compressed first input is based on the state difference between successive simulation steps. During long simulation runs, a checkpoint on the overall RCC state at a given low frequency can facilitate simulation history extraction. For decompression ratios of 20K to 200K simulation time steps per second in RCC systems and checkpoints deployed at one million steps, the RCC system extracts any simulation history within 5 to 50 seconds (ie, the first input and selected Simulation playback from VCD file creation).

When this $ rcc command is called, the RCC system will record the simulation history; In other words, one file will be compressed in the first input for storage of the system disk. The first input from the RCC hardware accelerator is ignored because software logic regeneration is not needed at this point. The write process can be maintained with the command $ rcc (stop) or $ rcc (off), at which point the RCC system switches the control of the simulation back to the software model. At this point, the first output is processed for software logic regeneration.

VCD Creation-Compression and Dump

As described above, the RCC system stores the software model and hardware model at the beginning of the simulation session range at simulation time t0, records the first input compressed for the entire simulation session range in the input history file, and simulates in the simulation history file. Save the hardware model state for the design at the end of the session scope. The user has enough information to load the design at the start of the simulation session range from the design information from the simulation time t0. Due to the compressed first input, the user can software simulate any part of his design. However, due to the VCD on-demand feature, the user would not want to software simulate his design at this point. Rather, the user wants to create a VCD file during the selected simulation target range for fine analysis to isolate and repair the bug. In fact, due to the recorded compressed first input, the RCC system can play any point within the scope of the simulation session. In addition, the RCC system can simulate beyond the current simulation session range by loading previously stored hardware state information from simulation time t3 if desired.

After simulating the design quickly, the user reviews the results to determine if a bug exists. If a bug appears to the user, the design can eliminate the bug during the current simulation session scope. The user then proceeds to simulate the scope of the next simulation session beyond the scope of the current simulation session, whatever the selected range. However, if the user decides that they have some kind of problem with the design, the user must analyze the simulation more carefully to isolate and repair the bug. Because the entire simulation session range is too large for careful and detailed analysis, the user must target a specific narrower range for further learning. Based on the user's familiarity with the design and past debugging efforts, the user makes a reasonable guess as to the location of the bug within the scope of the simulation session. The user will focus on the selected simulation target range that must respond to the user's guess about the location of the bug (or where the bug will represent itself). The user determines that the simulation target range exists between the simulation time T1 and the simulation time t2 as shown in FIG.

The RCC system loads the hardware model in the RCC hardware accelerator 2620 with the configuration information previously stored from the simulation state t0 and the software model of the design in the RCC calculation system 2600. The RCC system then simulates at high speed from simulation time t0 to simulation time t1. During the fast simulation operation, the RCC calculation system loads a prestored file containing the compressed first input. The RCC calculation system decompresses the compressed first input and inputs the decompressed first input to the RCC hardware accelerator 2620 for evaluation. As with the initial high speed simulation operation in which the first input is compressed and stored for the simulation session range, the first output (e.g., hardware model node value and register state) that is the result of the evaluation is the simulation time (t0) It is not stored during the high speed simulation to t1).

Once the high speed simulation operation reaches the beginning of the simulation target range, i.e., simulation time t1, the RCC system sends the evaluated result (i.e., the first output O _p ) from the hardware model in the RCC hardware accelerator 2620. Dump into a VCD file on disk. Unlike the initial high speed simulation operation for the simulation session range, the RCC calculation system 2600 does not perform any compression. Again, the RCC calculation system 2600 does not perform a playback operation on the software model because the user does not need to see the evaluation results at this time. By not performing any playback operation on the software model, the RCC system can quickly create a VCD file.

However, in another embodiment, the user can view the user design software model together during this simulation time period from t1 to t2 while saving the first output. If so, the RCC calculation system 2600 performs a software model playback operation to allow the user to see any and all states from the user design of any shape.

At simulation time t2, the RCC calculation system 2600 stops storing the evaluation output from the RCC hardware accelerator 2620 to a VCD file. At this point, the user can stop high speed simulation. The RCC system now has a complete VCD file for the simulation target range and can proceed to further analyze the VCD file.

When the user wants to analyze the VCD file, the user does not need to rerun the simulation from the start (eg simulation time t0). Instead, the user can instruct to load the stored hardware state information from the start of the RCC system simulation target range and view the simulated results with the software model. This will be described in more detail below in the simulation history review section.

When analyzing a VCD file, the user may or may not find a bug. If a bug is found, the user, of course, initiates the design modification. If no bug is found, the user may make a false guess in the scope of the simulation target that he suspects has a bug. The user must use the same process used above for decompression and VCD file dump. The user may hopefully make another conjecture that there is a better simulation target range within the simulation session scope. In doing so, the RCC system rapidly simulates from the start of the simulation session range to the new simulation target range, decompresses the first input and passes it to the RCC hardware accelerator 2620 for evaluation. When the RCC system reaches the start of a new simulation target range, the first output from the RCC hardware accelerator 2620 is dumped into the VCD file. At the end of the new simulation target range, the RCC system stops dumping hardware state information into the VCD file. At this point, the user can see the VCD file to isolate the bug.

In short, from simulation time t0 to simulation time t1, the RCC system simulates high speed by decompressing a previously compressed first input and passing it to a hardware model for evaluation. During the simulation target range from simulation time t1 to simulation time t2, the RCC system dumps the first output from the hardware model into the VCD file. At the end of the simulation target range, the user can stop simulating the design at high speed. At this point, the user can then view the VCD file by going directly to simulation time t1 without rerunning the simulation from the very beginning at simulation time t0.

When the review of this simulation target scope is complete and the bug is isolated and removed, the user can proceed to the next simulation session scope. This new simulation session range starts at simulation time t3. The particular length of the new simulation target range, which may be the same length as the previous simulation time session range, is selected by the user. The RCC system loads previously stored hardware state information corresponding to the simulation time t3. The RCC system is now ready to simulate this new simulation session range at high speed. Note that this new simulation session range corresponds to the range from simulation time t0 to t3, where the loaded hardware state now corresponds to simulation time t0. The high speed simulation, VCD on-demand dump and VCD review processes are similar to those described above.

According to one embodiment of the invention, the decompression step does not negatively affect performance. The RCC system decompresses the simulation history (ie, the compressed and recorded first input) at a rate of 20,000 to 200,000 simulation time steps per second. Using appropriate checkpoint control, the RCC system can extract the simulation history (ie, play the selected VCD file from the first input) within 50 seconds.

Regarding the particular way that the VCD on-demand feature is controlled in the RCC system, the user must use the $ axis_rpd command. $ axis_rpd is an interactive command for extracting RCC evaluation records and creating VCD files on demand. Unlike conventional simulation rewind techniques, the execution of the $ axis_rpd command neither rewinds the internal simulation state nor causes errors in external PLI and file I / O states. The user can continue the simulation after executing the $ axis_rpd command in the same way that he can simulate after the $ stop command.

When no argument is specified, the $ axis_rpd command displays all available simulation time periods within the scope of the simulation session; That is, the user can select the simulation target range. The time unit is the same time unit in the command line interface. An example of a simulation log is as follows:

C1> $ rcc (record, r1);

C2> # 1000 $ rcc (xt0, run);

C3> # 50000 $ rcc (off);

C4> # 50500 $ rcc (run);

C5> # 60000 $ rcc (stop);

… Start RCC engine at 100500

… Return to SIM: Stop RCC engine at 5000000

… Start RCC engine on 5050500

… Return to SIM: RCC engine stopped at 60000.0000ns

C6> $ axis_rpd;

Available simulation history:

1005.000000 to 50000.000000

50505.000000 to 60000.00000

Interrupt at simulation time 60000.0000ns

From this simulation logo, the RCC engine used by the user forms a time immediately after 1000 to 50000 and a time immediately after 50500 to 60000. Therefore, $ axis_rpd represents the recorded simulation window.

To generate a VCD file from the simulation history, the user uses the $ axis_rpd command with the following control arguments:

$ axis_rpd (start-time, end-time, dump-file-name ", <level and range control>);

The start-time and end-time define the simulation time window for the VCD file, ie the simulation target range. The unit of time control argument is the time unit used in the command line interface. "Dump-file-name" is the name of the VCD file. The dump <level and range control> parameter is identical to the standard $ dumpvars command in IEEE Verilog.

As an example of the $ axis_rpd command:

C7> $ axis_rpd (50505,50600, “fl.dump”);

… RCC VCD start at 50505.0100000 !!

… RCC VCD exit at 50600.000000 !!

Interrupt at simulation time 60000.0000ns

This $ axis_rpd command generates a VCD file called "kl.dump" for the simulation target range from simulation time 50505 to 50600. If no level and range control parameters are provided, such as $ dumpvars, the $ axis_rpd command will dump the entire hardware state or first output.

Another example of using the $ axis_rpd command is:

C8> $ axis_rpd (40444,50600, "fl.dump", 2, dp0)

… RCC VCD start at 40000.000000 !!

… Skipped at time 50000.000000

… Keep on time 50505.000000 !!

… RCC VCD exit at 50600.000000 !!

Interrupt at simulation time 60000.0000ns

This $ axis_rpd command generates a two-level VCD file "f2.dump" from time 40000 to 50600 on the range dp0. Since the simulation is switched back to software control for time 50000 to 50500, $ axis_rpd skips that window because the simulation record is not available.

VCD on-demand is also useful after the user has finished the simulation process. To perform the off-line VCD on-demand, the user starts a simulation program called "vlg" with the + rccplay option. With this option, the RCC system is instructed to extract the simulation record instead of performing the normal initialization sequence for the simulation. Once the user enters the simulation program, the user can use the same $ axis_rpd command to achieve the VCD on-demand. An example of this procedure is as follows:

axis1: 3-dpo_rtlc> vlg + rccplay_rl -s

… Record replay at time 100500 ./AxisWork/rl start

C1> $ axis_rpd;

Available simulation history:

1005.000000 to 50000.000000

50505.000000 to 60000.000000

Interrupt at simulation time 100500

C2> $ axis_rpd (40000,45000, “f2.dump”);

… RCC VCD start at 40000.000000 !!

… RCC VCD ends at 45000.000000 !!

Interrupt at simulation time 4500000

C3>

In the above example, a simulation record ("rl") is used to extract the simulation history and generate a VCD over the entire design from time 40000 to 45000.

Simulation history review

Once the VCD file of the simulation target range (ie, simulation time t1 to t2) is generated by the RCC system, the user does not need to simulate at high speed from simulation time t2 to t3. Instead, the RCC system allows the user to stop the simulation and proceed directly to the simulation target range, i.e. the beginning of the simulation time t1. Therefore, in contrast to the prior art, the user does not have to rerun the simulation from the start (eg, simulation time t0). The hardware state dumped into the VCD file reflects an evaluation of the entire history of the first input from simulation time t0 and includes the first input from simulation time t1 to t2.

The RCC system loads the VCD file. Thereafter, the stored first output is passed to the RCC calculation system 2600 so that both the software model and many of its combined logic circuits can be reproduced by accurate state information. Then, the user sees the software model with a waveform viewer for debugging. With VCD, users can step very carefully through their software model until the bug is priced.

This VCD on-demand feature allows the user to select any simulation target range within the simulation session range. If a bug cannot be found within the selected simulation target range, the user can select another different simulation target range on request. Since all first inputs from the test bench process can be recorded for the entire simulation parser range, any portion of this simulation can be reproduced and viewed on demand without rerunning the simulation. . This feature allows the user to repeatedly focus on multiple and different simulation target ranges until the user fixes bugs within the scope of this simulation session.

Moreover, this VCD on-demand feature can be supported on-line during the simulation process, as well as off-line after the simulation process ends. This on-line support is possible because at the simulation time t0 the hardware state can be stored in the system disk and the first input can be recorded compressed for any length of the simulation session range. The user can then define a simulation target range for more focused analysis of the first output.

Off-line support is possible because the hardware state is all stored in the system disk at the simulation time t1 and the first full input to the simulation session range at the simulation time t0. Therefore, the user can return to debug his design by loading the design corresponding to the simulation time t0 and then defining the simulation target range. In addition, the user can proceed directly to the next simulation target range by loading the hardware state corresponding to the simulation time t3.

Ⅵ. Hardware implementation

A. Overview

The SE emulation system implements an array of FPGA chips on a reconfigurable board. Based on the hardware model, the SE emulation system divides, wraps, positions and routes each selected portion of the user circuit design onto the FPGA chip. Thus, for example, a 4x4 array of 16 chips can model large circuits spread across these 16 chips. The interconnect scheme allows each chip to access two "jumps" or other chips within the link.

Each FPGA chip implements an address pointer for each I / O address space (ie, REG, CLK, S2H, H2S). Combinations of all address pointers associated with a particular address space can be chained together. Thus, during data transfer, the word data in each chip is one word at a time for the selected address space on each chip to and from the main FPGA bus and the PCI bus until the desired word data is accessed for that selected address space. The chips are selected sequentially. This sequential selection of word data is achieved by understanding the word select signal to be propagated. This word select signal travels through the address pointer in the chip and then propagates to the address pointer in the next chip and continues on the last chip or the system initializes the address pointer.

The FPGA bus system on the reconfigurable board doubles the PCI bus bandwidth, but halves the PCI bus speed. Therefore, FPGA chips are separated into banks to use larger bandwidth buses. The throughput of this FPGA bus system is proportional to the throughput of the PCI bus system, so the performance is reduced by reducing the bus speed. Expansion is possible through larger boards that include more FPGA chips or piggyback boards that extend the group length.

B. Address Pointer

Figure 11 illustrates one embodiment of an address pointer of the present invention. All I / O operations perform DMA streaming. Since the system has only one bus, the system accesses the data sequentially one word at a time. Therefore, one embodiment of an address pointer uses a shift register chain to sequentially access selected words in this address space. The address pointer 400 includes flip-flops 401-405, AND-gates 406, and control signal combinations, INITIALIZE 407 and MOVE 408.

Each address pointer has n outputs (W0, W1, W2, ..., Wn-1) to select one word from n possible words in each FPGA chip corresponding to the same word in the selected address space. . Depending on the particular user circuit design being modeled, the number n of words can vary from circuit design to design, and for a given circuit design, n is variable per FPGA chip. In FIG. 11, the address pointer 400 is only a five word (ie n = 5) address pointer. Therefore, this particular FPGA chip containing this 5-word address pointer for that particular address space has only 5 words to select. Of course, the address pointer 400 can implement any number of words n. This output signal Wn may be referred to as a word select signal. When this word select signal reaches the output of the last flip-flop in this address pointer, it is named the OUT signal to propagate to the input of the address pointer of the next FPGA chip.

When the INITIALIZE signal appears, the address pointer is initialized. The first flip-flop 401 is set to "1" and all other flip-flops 402-405 are set to "0". At this point, initialization of the address pointer will not enable any word selection; that is, all Wn outputs are still "0" after initialization. The address pointer initialization procedure will be discussed with respect to FIG.

The MOVE signal controls the progress of the pointer for word selection. This MOVE signal is derived from the READ, WRITE, and SPACE index control signals from the FPGA I / O controller. Since all operations are essentially read or write, the SPACE index signal essentially determines which address pointer will be provided with the MOVE signal. Therefore, the system operates only one address pointer associated with the selected I / O address space at a time, during which time the system provides a MOVE signal to that address pointer. MOVE signal generation is discussed below with respect to FIG. 13. Referring to FIG. 11, when the MOVE signal appears, the MOVE signal is provided to the input of the AND gate 406 to enable the inputs of the flip-flops 401-405. Therefore, logic "1" will move from word output Wi to Wi + 1 every system clock cycle; That is, the pointer will move from Wi to Wi + 1 to select a particular word every cycle. When the shifting word select signal proceeds to the output 413 of the final flip-flop 405 (shown herein as "OUT"), this OUT signal is then associated with Figures 14 and 15 unless the address pointer is reinitialized. It must proceed to the next FPGA chip through the multiplexed cross chip address pointer chain described.

The address pointer initialization procedure will be described below. 12 shows a state transition diagram of address pointer initialization for the address pointer of FIG. Initially, state 460 is at rest. When DATA_XSFR is set to "1", the system proceeds to state 461 where the address pointer is initialized. Here, the INITIALIZE signal appears. The first flip-flop in each address pointer is set to "1" and all other flip-flops in the address pointer are set to "0". At this point, the initialization of the address pointer will not enable any word selection: that is, all Wn outputs are still "0". The next state is the wait state 462 and DATA_XSFR is still "1". When DATA_XSFRdl becomes " 0 ", the address pointer initialization procedure is complete and the system returns to the idle state 460.

MOVE signal generators for generating various MOVE signals for the address pointer will be discussed below. The SPACE index generated by the FPGA I / O controller (FIG. 10; item 327 in FIG. 22) selects a particular address space (ie, REG read, REG write, S2H read, H2S write, and CLK write). Within this address space, the system of the present invention sequentially selects specific words to be accessed. Sequential word selection is achieved within each address pointer by the MOVE signal.

One embodiment of a MOVE signal generator is shown in FIG. Each FPGA chip 450 has an address pointer corresponding to various software / hardware boundary address spaces (ie, REG, S2H, H2S, and CLK). In addition to the user's circuit design and address pointer modeled and implemented in the FPGA chip 450, a MOVE signal generator 470 is provided within the FPGA chip 450. MOVE signal generator 470 includes an address space decoder 451 and several AND gates 452-456. The input signals are the FPGA read signal F_RD on the wire line 457, the FPGA write signal F_WR on the wire line 458, and the address space signal 459. The output MOVE signal for each address pointer is REGR-move on wire line 464, REGW-move on wire line 465, S2H-move on wire line 466, H2S-move on wire line 467, Corresponds to CLK-move on wire line 468, and accordingly these address pointers in the address space are applicable. This output signal corresponds to the MOVE signal on wire line 408 (FIG. 11).

The address space decoder 451 receives the 3-bit input signal 459. This decoder can also only receive a 2-bit input signal. The 2-bit signal provides four possible address spaces, while the 3-bit input provides eight possible address spaces. In one embodiment, CLK is assigned "00", S2H is assigned "01", H2S is assigned "10" and REG is assigned "11". According to the input signal 459, the output of the address space decoder outputs "1" on one of the wire lines 460-463 corresponding to REG, H2S, S2H, and CLK, respectively, but the remaining wire lines are "0". Is set to ". Therefore, when any such output wire lines 460-463 are "0", the corresponding output of AND gates 452-456 is "0". Similarly, if any such input wire lines 460-463 are "1", the corresponding output of AND gates 452-456 is "1". For example, when the address space signal 459_ is "10", the address space H2S is selected. The wire line 461 is "1", but the remaining wire lines 460, 462, and 463 are "0." Thus, the wire line 466 is "1", but the remaining output wire lines 464, 465, 467 and 468 are "0". Similarly, if the wire line 460 is "1", the REG Depending on whether the space is selected and the read (F_RD) or write (F_WR) operation is selected, either the REGR-move signal on the wire line 464 or the REGW-move signal on the wire line 465 will be "1".

As mentioned above, the SPACE index is created by the FPGA I / O controller. In the code, the MOVE control is:

REG space read pointer: REGR-Move = (SPACE-Index == # REG) &READ;

REG space write pointer: REGW-Move = (SPACE-Index == # REG) &WRITE;

S2H Space Read Pointer: S2H-Move = (SPACE-Index == # S2H) &READ;

H2S space write pointer: H2S-Move = (SPACE-Index == # H2S) &WRITE;

CLK space read pointer: CLK-Move = (SPACE-Index == # CLK) &WRITE;

This is the registration code for the logic diagram of the MOVE signal generator of FIG.

As mentioned above, each FPGA chip has the same number of address pointers as the address space at the software / hardware boundary. If the software / hardware boundary has four address spaces (ie, REG, S2H, H2S, and CLK), each FPGA chip has four address pointers corresponding to the four address spaces. Each FPGA has a particular select word in the selected address space being processed in any one or more FPGA chips, or because the data in the selected address space affects the various circuit elements modeled and implemented in each FPGA chip. Four address pointers are required. In order for the selected word to be processed by the appropriate circuit element (s) in the appropriate FPGA chip (s), each set of address pointers associated with a given software / hardware boundary address space (ie, REG, S2H, H2S and CLK) may be "Chain" together across the four FPGA chips. The characteristic shifting or propagation word selection mechanism via the MOVE signal as described above with respect to FIG. 11 is that in this "chain" embodiment, the address pointer associated with a particular address space in one FPGA chip is the same address space in the next FPGA chip. It is still used, except that it is "chained" to the address pointer associated with.

Implementing four input pins and four output pins to concatenate address pointers will accomplish the same purpose. However, such an implementation would be too expensive in terms of efficient use of resources; That is, four wires will be needed between the two chips, and four input pins and four output pins will be needed on each chip. One embodiment according to the present invention is a multiplexed cross chip in which the hardware model allows only one wire to be used between the chips and only one input pin and one output pin (2 I / O pins within the chip) to be used on each chip. Use an address pointer chain. One embodiment of a multiplexed cross chip address pointer chain is shown in FIG.

In the embodiment shown in FIG. 14, the user's circuit design is mapped and partitioned on three FPGA chips 415-417 in the reconfigurable hardware board 470. The address pointer is shown in blocks 421-432. Each address pointer, for example address pointer 427, may vary depending on how many words Wn and flip-flop words are to be implemented on each chip by the user's custom circuit design. It has a structure and function similar to that of the address pointer shown in FIG.

For the REGR address space, the FPGA chip 415 has an address pointer 421, the FPGA chip 416 has an address pointer 425, and the FPGA chip 417 has an address pointer 429. For the REGW address space, the FPGA chip 415 has an address pointer 422, the FPGA chip 416 has an address pointer 426, and the FPGA chip 417 has an address pointer 430. For the S2H address space, the FPGA chip 415 has an address pointer 423, the FPGA chip 416 has an address pointer 427 and the FPGA chip 417 has an address pointer 431. For the H2S address space, for the address space, the FPGA chip 415 has an address pointer 424, the FPGA chip 416 has an address pointer 428 and the FPGA chip 417 has an address pointer 432. Have

Each chip 415-417 has a multiplexer 418-420, respectively. Such multiplexers 418-420 may be models and the actual implementation may be a combination of registers and logic elements, as known to those skilled in the art. For example, the multiplexer can be several AND gates that go into the OR gate as shown in FIG. 15. Multiplexer 487 includes four AND gates 481-484 and OR gate 485. Inputs to the multiplexer 487 are OUT and MOVE signals from each address pointer in the chip. The output 486 of the multiplexer 487 is a chain-out signal that is passed to the input to the next FPGA chip.

In Figure 15, this particular FPGA chip has four address pointers 475-478 corresponding to the I / O address space. The output of the address pointer, OUT and MOVE signals are input to the multiplexer 487. For example, address pointer 475 has an OUT signal on wire line 479 and a MOVE signal on wire line 480. This signal is input to AND gate 481. The output of this AND gate 481 is an input to the OR gate 485. The output of the OR gate 485 is the output of this multiplexer 487. In operation, the OUT signal at the output of each address pointer along with the corresponding MOVE signal and SPACE index act as a selector signal for multiplexer 487; That is, both the OUT and MOVE signals (derived from the SPACE index signal) must appear active (eg, a logic "1") to propagate word select signals from the multiplexer to the chain-out wire line. do. The MOVE signal will appear periodically to move the word select signal through the flip-flop in the address pointer so that it can be characterized as an input MUX data signal.

Referring to Figure 14, these multiplexers 418-420 have four sets of inputs and one output. Each input set includes (1) an OUT signal found on the final output Wn-1 wire line (e.g., wire line 413 in the address pointer shown in FIG. 11) for an address pointer associated with a particular address space, and ( 2) Contains the MOVE signal. The output of each multiplexer 418-420 is a chain-out signal. The word select signal Wn through the flip-flop in each address pointer becomes an OUT signal when the output of the last flip-flop in the address pointer is reached. The chain-out signal on wire line 433-435 will be "1" only when both the OUT signal and the MOVE signal associated with the same address pointer appear active (eg, appear as "1"). .

Inputs to the multiplexer 418 are MOVE signals 436-439 and OUT signals 440-443, respectively, corresponding to the OUT and MOVE signals from the address pointers 421-424. For the multiplexer 419 the inputs are MOVE signals 444-447 and OUT signals 452-455, respectively, corresponding to the OUT and MOVE signals from the address pointers 425-428. For the multiplexer 420, the inputs are MOVE signals 448-451 and OUT signals 456-459 corresponding to the OUT and MOVE signals from address pointers 429-432, respectively.

In operation, for any given shift of word Wn, only such an address pointer or chain of address pointers associated with the selected I / O address space within the software / hardware boundary is active. Therefore, in FIG. 14, only address pointers in chips 415, 416 and 417 associated with one of the address spaces REGR, REGW, S2H or H2S are active for the provided shift. Also, for a given shift of the word select signal Wn via flip-flop, the selected words are accessed sequentially due to limitations in the bus bandwidth. In one embodiment, the bus is 32 bits wide and the words are 32 bits so that only one word can be accessed at a time and transferred to the appropriate resource.

When the address pointer is propagating or shifting the word select signal through the flip-flop, the output chain-out signal is not active (for example, not "1"), so this multiplexer in this chip is not yet the next FPGA chip. It is not ready to propagate the word select signal. When the OUT signal appears active (eg "1"), the chain-out signal is active (eg "1") indicating that the system is ready to propagate or shift the word select signal to the next FPGA chip. Appears. Therefore, access is generated for one chip at a time; That is, the word select signal is shifted through flip-flops in one chip before the word select shift operation is performed on the other chip. The chain-out signal appears only when the word select signal reaches the end of the address pointer on each chip. In the code, the chain-out signal is:

Chain-out = (REGR-move & REGR-out) | (REGW-move * REGW-out) | (S2H-move & S2H-out) | (H2S-move &H2S-out);

In other words, for X number of I / O address spaces (ie, REG, H2S, S2H, CLK) in the system, each FPGA has X address pointers, one address pointer for each address spacer. The size of each address pointer depends on the number of words needed to model your custom circuit design on each FPGA chip. Assuming n words for a particular FPGA chip and n words for an address pointer, this particular address pointer has n outputs (ie, W0, W1, W2, ..., Wn-1). This output Wi is also termed a word select signal. When a particular word Wi is selected, the Wi signal appears active (ie, "1"). This word select signal shifts or propagates the address pointer of this chip down until it reaches the end of the address pointer in this chip, at which point the signal is passed through the word select signal Wi through the address pointer in the next chip. Trigger the generation of a chain-out signal that initiates propagation of. In this manner, a chain of address pointers associated with a given I / O address space can be implemented across all FPGA chips in this reconfigurable hardware board.

C. Gated Data / Clock Network Analysis

Various embodiments of the present invention perform clock analysis associated with gated data logic and gated clock logic analysis. Gated clock logic (or clock network) and gated data network decisions are important for the logic implementation in the hardware model and successful implementation of the software clock during emulation. As described in connection with FIG. 4, clock analysis is performed in step 305. To further illustrate this clock analysis process, FIG. 16 shows a flowchart in accordance with one embodiment of the present invention. 16 also shows gated image analysis.

The SE emulation system has a complete model of the user circuit design in software and part of the user circuit design in hardware. This hardware part includes clock elements, in particular derived clocks. The issue of clock transfer timing occurs due to the boundary between software and hardware. Since the full model is in software, the software can detect clock edges that affect register values. In addition to the software model of the registers, these registers are physically located within the hardware model. In order for the hardware registers to also evaluate their respective inputs (ie, moving data from the D input to the Q output), the software / hardware boundary includes a software clock. The software clock ensures that the registers in the hardware model evaluate correctly. The software clock essentially controls the enable input of the hardware register rather than controlling the clock input to the hardware register element. This software clock avoids race conditions and therefore does not require precise timing control to avoid hold-time violations. The clock network and gated data logic analysis process shown in FIG. 16 provides a way to model and implement a clock and data delivery system for hardware registers so that race conditions are avoided and flexible software / hardware boundary implementations are provided.

As mentioned above, the first clock is a clock signal from the test-bench process. All other clocks, such as those clock signals derived from the combined device, are derived or gated clocks. The first clock can derive both the gated clock and the gated data signal. For the most part, only a few (eg 1-10) derived or gated clocks are present in the user's circuit design. This derived clock can be implemented as a software clock and will be in software. If a relatively large number (eg 10 or more) of induction clocks is provided in the circuit design, the SE emulation system will model it into hardware to maintain the performance of the SE emulation system to reduce I / O overhead. The gated data is a data or control input in a register different from the clock derived from the first clock through some combinatorial logic.

The gated data / clock analysis process begins at 500. Step 501 uses the useful resource design database code generated from the HDL code and maps the user's register elements to the register elements of the SE emulation system. This one-to-one mapping of user registers to SE simulation registers facilitates subsequent modeling steps. In some cases, this mapping requires handling the user circuit design that describes the register element with a particular primitive. Therefore, for RTL level code, the SE emulation register can be easily used at high speed because the RTL level code is at a high enough level to vary the lower level implementation. For a gate level netlist, the SE emulation system will access the device's cell library and modify it to suit a particular circuit design-specific logic element.

Step 502 extracts the clock signal from the register element of the hardware model. This step allows the system to determine the first clock and derived clock. This step also determines all clock signals needed by the various elements of the circuit design. The information from this step facilitates the software / hardware clock modeling step.

Step 503 determines the first clock and derived clock. The first clock is generated from the test-bench element and modeled only in software. The derived clock is derived from the combining logic, which in turn is derived by the first clock. By default, the SE emulation system of the present invention will maintain the derived clock in software. If the number of derived clocks is small (eg 10 or less), these derived clocks can be modeled as software clocks. The number of coupling elements to generate such a derived clock is small, so that such coupling elements are present in software without adding significant I / O overhead. However, if the number of derived clocks is large (eg 10 or more), such derived clocks can be modeled in hardware to minimize I / O overhead. Often, the user's circuit design uses a significant number of inductive clock elements derived from the first clock. Therefore, the system configures the clock in hardware to keep the number of software clocks small.

Decision step 504 requires the system to determine if any derived clock is found in the user's circuit design. Otherwise, step 504 determines "NO" and clock analysis ends at step 508 because all clocks in the user circuit design are the first clock and these clocks are simply modeled in software. If the derived clock is found in the user's circuit design, step 504 determines "YES" and the algorithm proceeds to step 505.

Step 505 determines a fan-out coupling element from the first clock to the clock derived. In other words, this step tracks the clock signal datapath from the first clock through the coupling element. Step 506 determines a fan-in coupling element from the derived clock. In other words, this step tracks the clock signal datapath from the coupling element to the clock derived. Determining fan-out and fan-in sets in the system is done repeatedly in software. The fan-in set of net N is as follows:

FanIn Set of a net N:

find all the components driving net N;

for each component X driving net N do:

if the component X is not a combination component then

return;

else

for each input net Y of the component X

add the FanIn set W of net Y to the FanIn Set of net N

end for

add the component X into N;

end if

endfor

The gated clock or data logic network is determined by iteratively determining the net-in fan-in and fan-out sets and determining their intersections. The final goal here is to determine the so-called net-in fan-in set. Net N is typically a clock input node for determining gated clock logic from a fan-in perspective. To determine the gated data logic from the fan-in prediction, net N is the clock input node associated with the nearby data input. If a node is on a register, net N is the clock input to that register for data input associated with that register. The system finds all the devices driving net N. For each device X driving net N, the system determines whether device X is a coupling device or not. If each element X is not a coupling element, the fan-in set of net N has no coupling element and net N is the first clock.

However, if at least one element X is a coupling element, the system determines the input net Y of element X. Here, the system considers the circuit design by finding the input node to element X. For each input net Y of each element X, there may be a fan-in set W coupled to the net Y. This fan-in set W of net Y is added to the fan-in set of net N, and then element X is added to set N.

The fan-out set of net N is determined in a similar manner. The fan-out set of net N is determined as follows:

FanOut Set of a netN:

find all the components using the net N;

for each component X using net N do:

if the component X is not a combination component then

return;

else

for each output net Y of the component X

add the FanOut Set of net Y to the FanOut Set of net N

end for

add the component X into N;

end if

endfor

Again, a gated clock or data logic network is determined by determining the fan-in and fan-out sets of net N and determining their intersections. The final goal here is to determine the so-called net-out fan-out set. Net N is typically a clock output node for determining gated data logic from a fan-out perspective. Therefore, all logical element sets using net N will be determined. To determine the gated data logic from the fan-out prediction, net N is the clock output node associated with the nearby data output. If the node is on a register, net N is the output of that register for the first clock-driven input associated with that register. The system finds all devices using net N. For each device X using net N, the system determines whether device X is a coupling device or not. If each element X is not a coupling element, the fan-out set of net N has no coupling element and net N is the first clock.

However, if at least one element X is a coupling element, the system determines the output net Y of element X. Here, the system considers the circuit design by finding the output node from element X. For each output net Y from each element X, there may be a fan-out set W coupled to the net Y. This fan-out set W of net Y is added to the fan-out set of net N, and then element X is added to set N.

Step 507 determines the clock network or gated clock logic. The clock network is the intersection of fan-in and fan-out coupling elements.

Similarly, the same fan-in and fan-out principles are used to determine gated logic circuits. Like the gated clock, the gated data is the data or control input (except the clock) of the register driven by the first clock through some combinational logic. Gated data logic is the intersection of fan-in of the gated data and fan-out from the first clock. Therefore, clock analysis and gated data analysis result in gated clock network / logic and gated data logic through some combinational logic. As discussed below, gated clock network and gated data network decisions are important for logical implementation in hardware models and successful implementation of software clocks during emulation. Clock / data network analysis ends at step 508.

17 illustrates basic structural blocks of a hardware model according to an embodiment of the present invention. For register devices, the SE emulation system uses a D-type flip-flop with asynchronous load control as the basic block for constructing both the edge trigger (i.e. flip-flop) and level sense (i.e. latch) register hardware models. use. This register model constituting the block includes the following ports: Q (output state); A_E (asynchronous enable); A_D (asynchronous data); S_E (synchronous enable); S_D (synchronous data); And system.clk (system clock).

This SE emulation register model is triggered by either the positive level of the asynchronous enable (A_E) input or the positive edge of the system clock. When one of these two positive edges or positive level triggering events occurs, the register model looks for an asynchronous enable (A_E) input. When the asynchronous enable A_E input is enabled, the output Q indicates the value of the asynchronous data A_D; Otherwise, when the sync enable S_E is enabled, the output Q indicates the value of the sync data S_D. On the other hand, if neither the asynchronous enable A_E nor the synchronous enable S_E input are enabled, the output Q is not evaluated despite the determination of the positive edge of the system clock. In this way, input to this enable port controls the behavior of this basic building block register model.

The system uses a software clock, which is a specific enable register to control the enable input of this register model. In a complex user circuit design, millions of elements are found in the circuit design, so the SE emulation system will implement millions of elements in the hardware model. Controlling all of these elements individually is expensive because the overhead of sending millions of signals to the hardware model will take more time than evaluating these elements in software. However, this complex circuit design typically requires only a few clocks (1-10) and the clocks are sufficient to control the state change of the system with only registers and coupling elements. The hardware model of the SE emulator system uses only registers and coupling elements. The SE emulator system also controls the evaluation of the hardware model through the software clock. In a SE emulation system, the hardware model for registers does not have a clock directly connected to another hardware element; Rather, the software kernel controls the values of all clocks. By controlling several clock signals, the kernel has full control over the evaluation of the hardware model with negligible coprocessor intervention overhead.

Depending on whether the register model is used as a latch or flip-flop, the software clock may be an input to one of the asynchronous enable (A_E) or synchronous enable (S_E) wire lines. The application of the software clock from the software model to the hardware model is triggered by edge detection of the clock element. When the software kernel detects the edge of the clock element, it sets the clock-edge register through the CLK address space. This clock-edge register controls the enable input, not the clock input to the hardware register model. The global system clock still provides the clock input to the hardware register model. However, the clock-edge register provides a software clock signal to the hardware register model through a double-buffered interface. As discussed below, the dual-buffer interface from the software clock to the hardware model allows all register models to be updated synchronously with respect to the global system clock. Therefore, using a software clock eliminates the risk of holding time violations.

18 (a) and 18 (b) illustrate the implementation of component block registers for latches and flip-flops. This register model is software-clock controlled through the appropriate enable input. Depending on whether the register model is used as a flip-flop or as a latch, the asynchronous ports A_E and A_D and the sync ports S_E and S_D are used for either software clock or I / O operations. 18A shows a register model implementation when used as a latch. Latch is level sensitive; In other words, as long as the clock signal appears (eg, "1"), the output Q follows the input D. Here, the software clock signal is provided to the asynchronous enable (A_E) and the data input is provided to the asynchronous data (A_D) input. For I / O operations, the software kernel uses the sync enable (S_E) and sync data (S_D) inputs to download values into the Q port. The S_E port is used as a REG space address pointer and S_D is used to access data to and from the local data bus.

18 (b) shows a register model implementation when used as a design flip-flop. The design flip-flop uses the following ports: data (D), set (S), reset (R), and enable (E) to determine the next state logic. All next state logic of the design flip-flop is factored into hardware coupled elements that are fed into the sync data (S_D) input. The software clock is the input to the sync enable (S_E) input. For I / O operations, the software kernel uses asynchronous enable (A_E) and asynchronous data (A_D) inputs to download values into the Q port. The A_E port is used as the REG space write address pointer and the A_D port is used to access data to and from the local data bus.

The software clock will be described below. One embodiment of the software clock of the present invention is a clock enable signal to a hardware register model so that data at the input to this hardware register model is evaluated with the system clock and synchronously with the system clock. This eliminates race conditions and maintenance-time violations. One embodiment of software clock logic includes clock edge detection logic in software that triggers additional logic in hardware upon clock edge detection. This enable signal logic generates an enable signal for the enable input into the hardware register model before data arrives in this hardware register model. Gated clock network and gated data network decisions are important for the logical evaluation of the hardware model and successful implementation of the software clock during hardware acceleration mode. As mentioned above, the clock network or gated clock logic is the intersection of the fan-in of the gated clock and the fan-out of the first clock. Likewise, the gated data logic is also the intersection of the fan-in of the gated data and the fan-out of the first clock with respect to the data signal. This fan-in and fan-out concept is described above with respect to FIG.

As mentioned above, the first clock is generated by a test-bench process in software. The derived or gated clock is generated from a network of registers and register logic that are in turn driven by the first clock. By default, the SE emulation system of the present invention will maintain the derived clock in software. If the number of derived clocks is small (eg 10 or less), these derived clocks can be modeled as software clocks. The number of coupling elements to generate such an induction clock is small, so no I / O overhead is added by modeling such coupling elements in software. However, if the number of derived clocks is large (eg, 10 or more), these derived clocks and their combinations can be modeled in hardware to minimize I / O overhead.

Ultimately, according to one embodiment of the present invention, clock edge detection generated in software (via input to the first clock) may be changed to clock detection in hardware (via input to the clock edge register). . Clock edge detection in software triggers an event in hardware to receive a clock enable signal prior to the data signal, such that the evaluation of the data signal occurs in synchronization with the system clock to avoid hold-time violations.

As mentioned above, the SE emulation system has a complete model of the user's circuit design in software and part of the user's circuit design in hardware. As defined in the kernel, software can detect clock edges that affect hardware register values. In order for the hardware registers to also evaluate their respective inputs, the software / hardware boundary includes a software clock. The software clock allows the registers in the hardware model to be evaluated in synchronization with the system clock and without any hold-time violation. The software clock essentially controls the enable input of the hardware register device rather than the clock input to the hardware register device. The double-buffered method for implementing a software clock allows the registers to be evaluated in synchronization with the system clock to avoid race conditions and eliminates the need for accurate timing control to avoid hold-time violations.

19 illustrates one embodiment of a clock implementation system in accordance with the present invention. Initially, the gated clock logic and gated data logic are determined by the SE emulation system as described above with respect to FIG. The gated clock logic and gated data logic are then separated. When implementing a double buffer, the drive source and the double buffered first logic must be separated. Thus, from the fan-in and fan-out analysis, gated data logic 513 and gated clock logic 514 are separated.

The modeled first clock register 510 includes a first buffer 511 and a second buffer 512, both of which are D registers. This first clock is modeled in software but the dual-buffer implementation is modeled in both software and hardware. Clock edge detection is generated in a first clock register 510 in software to trigger the hardware model to generate a software clock signal for the hardware model. Data and addresses enter the first buffer 511 on wire lines 519 and 529, respectively. The Q output of this first buffer 511 on wire line 521 is coupled to the D input of second buffer 512. The Q output of this first buffer 511 is also provided to the clock logic 514 gated on the wire line 522 ultimately to drive the clock input of the first buffer 516 of the clock edge register 515. . The output of the second buffer 512 on the wire line 523 is ultimately gated data logic 513 to drive the input of the register 518 through the wire line 530 in the user's custom-designed circuit model. Is provided). The enable input to the second buffer 512 in the first clock register 510 is an INPUT-EN signal on the wire line 533 from the state machine, which determines the evaluation cycle and thus controls the various signals.

Clock edge register 515 also includes a first buffer 516 and a second buffer 517. Clock edge register 515 is implemented in hardware. When clock edge detection occurs in software (via input to first clock register 510), it can trigger the same clock edge detection in hardware (via clock edge register 515) in hardware. The D input to the first buffer 516 on wire line 524 is set to a logic “1”.

Board 1551 has a connector 1590 and board 1556 has a connector 1581 for inter-board communication. Interconnects from one board to another board, such as interconnects 1600,1971,1977,1541,1540, advance to these connectors 1590,1581; In other words, inter-board connectors 1590 and 1581 allow interconnects 1600, 1971, 1977, 1541 and 1540 to connect between one element on one board and another element on the other board. Inter-board connectors 1590 and 1581 transfer control data and control signals on the FPGA bus.

In a four-board configuration, board 1 and board 6 are provided with a bookend board, while boards 21551 and boards 3153 (see FIG. 39) are intermediate boards. When coupled to the motherboard according to the present invention (as described with reference to FIGS. 38A and 38B), board 1 and board 2 are paired and board 3 and board 6 are paired. Achieve.

In a six-board configuration, the board 1 and the board 6 are provided with a bookend board as described above, but boards 21551, boards 315353, and boards 4554. And board 5 1555 (see FIG. 39) are intermediate boards. When coupled to a motherboard in accordance with the present invention (as described with reference to FIGS. 38A and 38B), board 1 and board 2 are paired and board 3 and board 4 are paired. The board 5 and the board 6 are paired.

More boards may be provided as needed. However, regardless of the number of boards to be added to the system, the bookend boards (such as boards 1 and 6 of FIG. 39) have a required termination to complete the mesh array connection. . In one embodiment, the minimum configuration is the dual-board configuration of FIG. 44. More boards can be added by increasing the 2-board. If the initial configuration is board 1 and board 6, then changing to a four-board configuration, as mentioned above, moves board 6 outward and moves board 1 and board 2 into place. Pairing together, and then pairing board 3 and board 6 together.

As described above, each logic device is not adjacent to an adjacent neighboring logic device but is coupled with a neighboring logic device across one space. Thus, in FIGS. 39 and 44, logic device 1577 couples with adjacent neighboring logic device 1578 through interconnect 1547. The logic device 1577 also couples with the non-neighboring logic device 1579 via interconnect 1548 across one space. However, logic device 1580 may be considered adjacent to logic device 1577 due to a wraparound torus configuration having coupling interconnect 1549.

42 shows a top view (component side) of on-board components and connectors for a single board. In one embodiment of the invention, only one board is needed to model the user design in the simulation system. In other embodiments, several boards (at least two boards) are required. Thus, for example, FIG. 39 shows six boards 1551-1556 coupled together through several 600-pin connectors 1581-1590. At the top end and the base end, the board 1551 is terminated by one set of 10-ohm R-packs and the board 1556 is terminated by another set of 10-ohm R-packs.

Referring back to FIG. 42, the board 1820 has four FPGAs, namely a logic device 1822 (FPGA0), a logic device 1827 (FPGA1), a logic device 1824 (FPGA2), and a logic device 1825 (FPGA3). )). Also provided are two SRAM memory devices 1828 and 1829. The SRAM memory devices 1828 and 1829 are used to map memory blocks from logic devices on the board; That is, the memory simulation feature of the invention is mapping from a logic device on the board to an SRAM memory device on the board. Other boards may have different logic devices and memory devices to achieve similar mapping operations. In one embodiment, memory mapping is board dependent; That is, the memory mapping for board 1 is limited to logic devices and memory devices on board 1 but is independent of other boards. In another embodiment, memory mapping is not board-based. Thus, a few large memory devices are used to map memory blocks from logic devices on one board to memory devices located on another board.

A light emitting diode (LED) 1821 is also provided to visually illustrate some selection activities. LED displays are shown in Table A in accordance with one embodiment of the present invention:

Table A: LED Display

LED color condition Explanation LED1 green On +5 V and +3.3 V are normal off +5 V or +3.3 V is abnormal LED2 amber off All On-Board FPGA Configurations Work Flashing On-board FPGA is not configured or fails to configure On FPGA configuration is in progress LED3 Red On Data transfer is in progress off Do not send data Flashing Health check failed

Several other control chips, such as the PLX PCI controller 1826 and the CTRL_FPGA unit 1827, control inter-FPGA and PCI communications. One example of a PLX PCI controller 1826 that may be used in a system is PCI9080 or PCI9060 from PLX Technology. The PCI9080 has an appropriate local bus tin interface, control registers, FIFO, and PCI interface to the PCI bus. Data Book PLX Technology, PCI9080 data sheet (February 28, 1997 ver.0.93), is incorporated herein by reference. One example of the CTRL_FPGA unit 1827 is a programmable logic device (PLD) in the form of an FPGA, such as an Altra 10K50 chip. In many board configurations, only the first board coupled to the PCI has a PCI controller.

Connector 1830 connects board 1820 to the motherboard (not shown) and to the PCI bus, power, and ground. For some boards, the connector 1830 is not used to connect directly to the motherboard. Thus, in a dual-board configuration, only the first board is coupled to the motherboard. In a six-board configuration, only boards 1, 3, 5 are directly connected to the motherboard while the remaining boards 2, 4, 6 rely on neighboring boards for connection with the motherboard. Inter-board connectors J1-J28 are also provided. As named, the connectors J1-J28 enable connection between different boards.

Connector J1 is for external power and ground connection. Table B below shows the pins and corresponding descriptions for the external power connector J1 in accordance with one embodiment of the present invention.

Table B: External Power-J1

Pin number Explanation One VCC 5V 2 GND 3 GND 4 VCC 3V

The connector J2 is for parallel port connection. The connectors J1, J2 are used for stand-alone single-board boundary scan test in production. Table C below shows the pins and corresponding descriptions for the parallel JTAG port connector J2 in accordance with one embodiment of the present invention.

Table C: Parallel JTAG Port-J2

J2 pin number J2 signal I / O from the board DB25 pin number DB25 signal 3 PARA_TCK I 2 D0 5 PARA_TMS I 3 D1 7 PARA_TDI I 4 D2 9 PARA_NR I 5 D3 19 PARA_TDO O 10 NACK 10,12,14,16,18,20,22,24 GND 18-25 GND

Connectors J3 and J4 are for local bus connection to the board. Connectors J5-J16 are a set of FPGA interconnect connections. Connectors J17-J28 are a second set of PGA interconnect connections. When the component-side is located at the solder-side, the connector provides a valid connection between one component on one board and another component on the other board. Tables D and E below show all lists and descriptions of connectors J1-J28 in accordance with one embodiment of the present invention.

Table D: Connectors (J1-J28)

connector Explanation type J1 + 5V / + 3V External Power 4-pin power RA header, comp side J2 Parallel port 0.1 "pitch, 2-low through-hole RA header, comp side J3 Local bus 0.05 "pitch, 2x30 through-hole header, SAMTEC, Comp Side J4 Local bus 0.05 "pitch, 2x30 through-hole receptacle, SAMTEC, solder side J5 Low A: NH [0], VCC3V, GND Low B: J17 Low B, VCC3V, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J6 Low A: J5 Low B, VCC3V, GND Low B: J17 Low B, VCC3V, GND 0.05 "pitch, 2x30 receptacle, SAMTEC, solder side J7 Low A: N [0], 4x VCC3V, 4x GND, N [2] Low B: N [0], 4x VCC3V, 4x GND, N [2] 0.05 "pitch, 2x45 through-hole header, SAMTEC, Comp / Solder Side J8 Low A: N [0], 4x VCC3V, 4x GND, N [2] Low B: N [0], 4x VCC3V, 4x GND, N [2] 0.05 "pitch, 2x45 through-hole receptacle, SAMTEC, comp / solder side J9 Low A: NH [2], LASTL, GND Low B: J21 Low B, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J10 Low A: J9 Low B, FIRSTL, GND Low B: J9 Low A, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J11 Low A: NH [1], VCC3V, GND Low B: J23 Low B, VCC3V, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J12 Low A: J11 Low B, VCC3V, GND Low B: J11 Low A, VCC3V, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J13 Low A: N [1], 4x VCC3V, 4x GND, N [3] Low B: N [1], 4x VCC3V, 4x GND, N [3] 0.05 "pitch, 2x45 through-hole header, SAMTEC, Comp / Solder Side J14 Low A: N [1], 4x VCC3V, 4x GND, N [3] Low B: N [1], 4x VCC3V, 4x GND, N [3] 0.05 "pitch, 2x45 through-hole receptacle, SAMTEC, comp / solder side J15 Low A: NH [3], LASTH, GND Low B: J27 Low B, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J16 Low A: J15 Low B, FIRSTH, GND Low B: J15 Low A, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J17 Low A: SH [0], VCC3V, GND Low B: J5 Low B, VCC3V, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J18 Low A: J17 low B, VCC3V, GND Low B: J17 low A, VCC3V, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J19 Low A: S [0], 4x VCC3V, 4x GND, S [3] Low B: S [0], 4x VCC3V, 4x GND, S [3] 0.05 "pitch, 2x45 through-hole header, SAMTEC, Comp / Solder Side J20 Low A: S [0], 4x VCC3V, 4x GND, S [3] Low B: S [0], 4x VCC3V, 4x GND, S [3] 0.05 "pitch, 2x45 through-hole receptacle, SAMTEC, comp / solder side J21 Low A: SH [2], LASTL, GND Low B: J9 Low B, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J22 Low A: J21 Low B, FIRSTL, GND Low B: J21 Low A, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J23 Low A: SH [1], VCC3V, GND Low B: J11 Low B, VCC3V, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J24 Low A: J23 Low B, VCC3V, GND Low B: J23 Low A, VCC3V, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side J25 Low A: S [1], 4x VCC3V, 4x GND, S [3] Low B: S [1], 4x VCC3V, 4x GND, S [3] 0.05 "pitch, 2x45 through-hole header, SAMTEC, Comp / Solder Side J26 Low A: S [1], 4x VCC3V, 4x GND, S [3] Low B: S [1], 4x VCC3V, 4x GND, S [3] 0.05 "pitch, 2x45 through-hole receptacle, SAMTEC, comp / solder side

connector Explanation type J27 Low A: SH [3], LASTH, GND Low B: J15 Low B, GND 0.05 "pitch, 2x30 SMD header, SAMTEC, Comp Side J28 Low A: J27 Low B, FIRSTH, GND Low B: J27 Low A, GND 0.05 "pitch, 2x30 SMD Receptacle, SAMTEC, Solder Side

Shaded connectors are through-hole rudders. In Table D, parentheses [] indicate SMS FPGA logic device numbers (0-3). Thus, S [0] points to the south interconnect (S [73: 0] in FIG. 37) and 74 bits of FPGA (0).

Table E: Local Bus Connectors-J3, J4

Pin number Signal name I / O Pin number Signal name I / O A1 GND PWR B1 LRESET_N I / O A2 J3_CLK for J3 J4_CLK for J4 I / O B2 VCC5V PWR A3 GND PWR B3 LD0 I / O A4 LD1 I / O B4 LD2 I / O A5 LD3 I / O B5 LD4 I / O A6 LD5 I / O B6 LD6 I / O A7 LD7 I / O B7 LD8 I / O A8 LD9 I / O B8 LD10 I / O A9 LD11 I / O B9 GND PWR A10 VCC3V PWR B10 LD12 I / O A11 LD13 I / O B11 LD14 I / O A12 LD15 I / O B12 LD16 I / O A13 LD17 I / O B13 LD18 I / O A14 LD19 I / O B14 LD20 I / O A15 LD21 I / O B15 VCC3V PWR A16 LD22 I / O B16 LD23 I / O A17 LD24 I / O B17 LD25 I / O A18 LD26 I / O B18 LD27 I / O A19 LD28 I / O B19 LD29 I / O A20 LD30 I / O B20 LD31 I / O A21 VCC3V PWR B21 LHOLD OT A22 ADS_N I / O B22 GND PWR A23 DEN_N OT B23 DTR_N 0 A24 LA31 O B24 LA30 0 A25 LA29 O B25 LA28 0 A26 LA10 O B26 LA7 0 A27 LA6 O B27 LA5 0 A28 LA4 O B28 LA3 0 A29 LA2 O B29 complete OD A30 VCC5V PWR B30 VCC5V PWR

I / O direction to board (1)

FIG. 43 shows a legend for the connectors J1-J28 of FIGS. 41A-41F, 42. In general, the blanks in the block indicate surface mounting and the green in the block indicates the through hole type. The solid outline block also represents a connector located on the component side. Dot outline blocks represent connectors located on the solder side. Thus, the blank solid outline block 1840 represents a 20x30 header mounted to the surface and located on the component side. The blank dot outline block 1841 represents a 2x30 receptacle mounted on the surface and located on the solder side of the board. Solid outline block 1882 filled in green represents a 2x30 or 2x45 header located on the component side in the form of a through hole. The green dot outline block 1843 represents a 2x30 or 2x45 receptacle located on the solder side in the form of a through hole. In one embodiment, the simulation system uses the Samtec SFM and TFM series of 2x30 or 2x45 microstrip connectors for both surface mount and through hole types. The solid outline block 1844 filled with grid marks is an R-pack mounted on the surface of the board and located on the component side. The dot outline block 1845 filled with grid marks is an R-pack mounted on the surface and located on the solder side. Samtec description of the Samtec catalog on the website is incorporated herein by reference. Referring again to FIG. 42, the connectors j3-j28 are of the same type as pointed out in the legend of FIG.

41A-41F show top views of each board and each connector of these boards. 41A shows the connector to the board 6. Thus, board 1660 includes connectors 1601-1681 along motherboard connector 1802. 41B shows the connector to the board 5. Thus, board 1690 includes connectors 1691-1708 along motherboard connector 1709. 41C shows the connector to board 4. Thus, board 1715 includes connectors 1171-1733 along motherboard connector 1734. 41D shows the connector to the board 3. Thus, board 1740 includes connectors 1741-1758 along motherboard connector 1759. 41E shows the connector to board 2. Accordingly, board 1765 includes connectors 1762-1783 along motherboard connector 1784. 41F shows the connector to board 1. Thus, board 1790 includes connectors 1791-1812 along motherboard connector 1813. As shown in the legend of FIG. 43, the connector for the six boards is a combination of (1) surface mount type or through hole type, (2) component side or solder side, (3) header or receptacle or R-pack .

In one embodiment, these connectors are used for inter-board communication. Related buses and signals are grouped together and supported by these inter-board connectors to route signals between any two boards. Also, only half of the boards are directly coupled to the motherboard. In FIG. 41A, board 6 (1660) includes connectors designated for one set of FPGA interconnects (1661-1668), connectors designated for another set of FPGA interconnects (1669-1674, 1676, 1679), and a local bus. And a connector 1801 designated for the purpose. Since the boards 6 and 1660 are located as one of the boards at the end of the motherboard (along board 1 (1790) of FIG. 41F at the other end), the connectors 1675, 1677, 1678, 1680 are Designated as a 10-ohm R-pack for a given north-south interconnect. Motherboard connector 1802 also includes board 6 (1660), as in FIG. 38B showing that sixth board 1535 is coupled to fifth board 1534 but not directly to motherboard 1520. Not used for

In FIG. 41B, board 5 1690 is designated connector 1691-1698 for one set of FPGA interconnects, connector 1699-1706 designated for another set of FPGA interconnects, and a connector designated for the local bus. (1707). Connector 1709 is used to couple boards 5 and 1690 to the motherboard.

In FIG. 41C, board 4 and 1715 are designated connectors 1716-1723 for one set of FPGA interconnects, connectors 1724-1731 designated for another set of FPGA interconnects, and connectors designated for the local bus. (1732,1733). The connector 1709 is not used to directly couple the boards 4 and 1715 to the motherboard. This configuration is in FIG. 38B showing that the fourth board 1533 is coupled to the third board 1532 and the fifth board 1534 but not directly to the motherboard 1520.

In FIG. 41D, board 3 (1740) is a connector (1741-1748) designated for one set of FPGA interconnects, a connector (1749-1756) designated for another set of FPGA interconnects, and a connector designated for the local bus. (1757,1758). Connector 1759 is used to couple board 3 (1740) to the motherboard.

In FIG. 41E, board 2 (1765) includes connectors designated for one set of FPGA interconnects (1766-1733), connectors designated for another set of FPGA interconnects (1774-1781), and connectors designated for local buses. (1782,1783). Connector 1784 is not used to directly join board 2 (1765) to the motherboard. This configuration is in FIG. 38B showing that the second board 1525 is coupled to the third board 1532 and the first board 1526 but not directly to the motherboard 1520.

In FIG. 41F, board (1) 1790 is a connector (1791-1798) designated for one set of FPGA interconnects, a connector (1799-1804, 1806, 1809) designated for another set of FPGA interconnects, and a local bus. Connectors 1811 and 1812 designated for the purpose of designation. Connector 1813 is used to couple board (1) 1790 to the motherboard. The boards 1805 1790 are positioned as one of the boards at the end of the motherboard (along the board 1 (1660 of Figure 41A at the other end)), so the connectors 1805, 1807, 1808, 1810 are Designated as a 10-ohm R-pack for a given north-south interconnect.

In one embodiment of the invention, several boards are combined with the motherboard and each other in a unique manner. Several boards are joined together from component-side to solder-side. In addition, one of the boards, the first board, is coupled to the motherboard and is connected to the PCI bus through the motherboard connector. The FPGA interconnect bus on the first board is also coupled to the FPGA interconnect bus on the other board, the second board, through a pair of FPGA interconnect connectors. The FPGA interconnect connector of the first board is on the component side and the FPGA interconnect connector of the second board is on the solder side. The component side and solder side on the first and second boards respectively allow the FPGA interconnect buses to be coupled together.

Similarly, local buses on two boards are joined together via local bus connectors. The localbus connector on the first board is on the component side and the local bus connector on the second board is on the solder side. Thus, the component side and solder side connectors on the first and second boards respectively allow the local buses to be joined together.

More boards can be added. The third board may have a solder side on the component side of the second board and be added. Similarly, FPGA interconnect and local bus inter-board connections can also be made. As described below, the third board is also coupled to the motherboard through other connectors, but these connectors simply provide power and ground to the third board.

The component side connector of the solder side of the dual board configuration will be described with reference to FIG. 38A. The figure shows a side view of an FPGA board connection on a motherboard in accordance with an embodiment of the present invention. 38A shows a dual-board configuration, in which only two boards are named. These two boards 1525 (board 2) and 1526 (board 1) shown in FIG. 38A correspond to the two boards 1552 and 1551 shown in FIG. 39. Component sides of boards 1525 and 1526 are indicated by reference numeral 1988. Solder sides of the two boards 1525 and 1526 are indicated by reference numeral 1988. As shown in FIG. 38A, these two boards 1525 and 1526 are coupled to the motherboard 1520 through the motherboard connector 1523. Other motherboard connectors 1521, 1522, and 1524 may also be extended. Signals between the PCI bus and the boards 1525 and 1526 are routed through the motherboard connector 1523. The PCI signal is first routed through the first board 1526 between the dual-board architecture and the PCI bus. Thus, signals from the PCI bus first count the first board 1526 before they are sent to the second board 1525. Analogically, signals of the PCI bus from the dual-board architecture are transmitted from the first board 1526. Power is also applied to the boards 1525 and 1526 via the motherboard connector 1523 from the power supply (not shown).

As shown in FIG. 38A, board 1526 includes several components and connectors. One component is the FPGA logic device 1530. Also provided are connectors 1528A, 1153A. Similarly, board 1525 includes several components and connectors. One such component is the FPGA logic device 1529. Also provided are connectors 1528B, 1153B.

In one embodiment, connectors 1528A, 1528B are inter-board connectors, such as an FPGA bus, such as 1590,1581 (of FIG. 44). These inter-board connectors are N [73: 0], S [73: 0], W [73: 0], E [73: 0], NH [27: 0], SH [27: 0 except local buses. ], Provides inter-board connectivity for several FPGA interconnects such as XH [36: 0] and XH [72:37].

Moreover, connectors 1531A-1531B are inter-board connectors for the local bus. The local bus handles signals between the PCI bus (via the PCI controller) and the FPGA bus (via the FPGA I / O controller (CTRL_FPGA) unit). The local bus also handles configuration and boundary scan test information between the PCI controller and FPGA logic device and FPGA I / O controller (CTRL_FPGA) units.

In the end, the motherboard connector is a pair of boards that couple a board to the PCI bus and power. One set of connectors couples the FPGA interconnect to the solder side of another board through the component side of one board. Another set of connectors couples the local bus to the solder side of the other board through the component side of one board.

In another embodiment of the present invention, two or more boards are used. In addition, Figure 38B shows a six-board configuration. The configuration is similar to that of FIG. 38A. All other boards are directly connected to the motherboard, and their interconnects and local buses are joined together through inter-board connectors placed at the solder-side and component-side.

38B shows six boards 1526 (first board), 1525 (second board), 1532 (third board), 1533 (fourth board), 1534 (fiveth board), and 1535 (6th board). do. The six boards are coupled to the motherboard 1520 through connectors on boards 1526 (first board), 1532 (third board), and 1534 (fifth board). The other boards 1525 (second board), 1533 (fourth board), 1535 (sixth board) do not directly couple with the motherboard 1520; Indirectly couples with the motherboard through connections with their respective neighboring boards.

By placing the solder-side on the component-side, several inter-board connectors enable communication between PCI bus components, FPGA logic devices, memory devices, and various simulation system control circuits. The first set of inter-board connectors 1990 corresponds to connectors J5-J16 of FIG. 42. The second set of inter-board connectors 1991 corresponds to connectors J17-J28 of FIG. 42. The third set of inter-board connectors 1992 corresponds to connectors J3-J4 of FIG. 42.

Motherboard connectors 1521-1524 are provided on motherboard 1520 to couple the motherboard (and therefore PCI bus) to the six boards. As mentioned above, the boards 1526 (first board), 1532 (third board), and 1534 (fifth board) are directly coupled with the connectors 1523, 1522, and 1521, respectively. The other boards 1525 (second board), 1533 (fourth board), and 1535 (6th board) do not directly couple with the motherboard 1520. Since only one PCI controller is needed for all six boards, only the first board 1526 includes the PCI controller. In addition, a motherboard connector 1523 coupled to the first board 1526 provides access to / from the PCI bus. Connectors 1522 and 1521 only couple power and ground. The center-to-center spacing between adjacent motherboard connectors is approximately 20.32 mm in one embodiment.

For boards 1526 (first board), 1532 (third board), and 1534 (fifth board) directly bonded to the motherboard connectors 1523, 1522, and 1521, respectively, the connectors J5-J16 have component side Are located on the solder side and each of the local bus connectors J3-J4 is located on the component side. For boards 1525 (second board), 1533 (fourth board), and 1535 (fourth board) that are not directly coupled to the motherboard connectors 1523, 1522, and 1521, respectively, the connectors J5-J16 are Located on the solder side, each connector J17-J28 is located on the component side, and local bus connectors J3-J4 are located on the solder side. For end boards 1526 (first board), 1535 (sixth board), the pair of connectors J17-J28 is a 10-ohm R-pack termination.

40A and 40B show array connections between different boards. To facilitate the manufacturing process, a single layout structure is used for all boards. As described above, the board connects to other boards via a backplane switch. FIG. 40A shows two exemplary boards 1611 (board 2) and 1610 (board 1). The component side of the board 1610 faces the solder side of the board 1611. Board 1611 includes various FPGA logic devices, other components, and wire lines. Specific nodes of the logic device and other components on the board 1611 are denoted by Node A '(reference number 1612) and Node B' (reference number 1614). Node A 'couples to connector pad 1616 via PCB trace 1620. Similarly, node B 'is connected to connector pad 1617 via PCB trace 1623.

Similarly, board 1610 includes various FPGA logic devices, other components, and wire lines. Specific nodes of the logic device and other components on board 1610 are denoted by Node A (reference number 1613) and Node B (reference number 1615). Node A couples to connector pad 1618 through PCB trace 1625. Similarly, Node B is connected to connector pad 1619 via PCB trace 1622.

Signal routing between nodes located on different boards using surface mount connectors is described. In FIG. 40A, the preferred connection is: (1) between Node A and Node B 'indicated by virtual paths 1620, 1641 and 1622, and (2) indicated by virtual paths 1623, 1624, 1625. Node B and node A '. The connection forms the same path as the asymmetrical connection between board 1551 and board 1552 of FIG. 39. Other asymmetric interconnects include NH-SH interconnects 1577, 1579, 1581 on both sides of connectors 1589-1590.

A-A 'and B-B' correspond to symmetrical interconnections such as interconnects (1515 (N, S)). N and S interconnects use through-hole connectors, NH and SH asymmetric interconnects use SMD connectors. Use See Table D.

Actual implementations using surface mount connectors are described with reference to FIG. 40B using the same numbers for the same items. In FIG. 40B, board 1611 shows node A 'on the component side coupled to component-side connector pad 1636 via PCB trace 1620. Component-side connector pad 1636 couples to solder-side connector pad 1639 via conductive path 1651. Solder-side connector pad 1639 couples to component side connector pad 1644 on board 1610 via conductive path 1648. Finally, component-side connector pad 1644 couples to Node B via PCB trace 1622. Thus, node A 'on board 1611 may be combined with node B on board 1610.

Likewise, in FIG. 40B, board 1611 shows NodeB ′ on the component side coupled to component-side connector pad 1638 through PCB trace 1623. Component-side connector pads 1638 couple to solder-side connector pads 1637 through conductive paths 1650. Solder-side connector pad 1637 couples to component side connector pad 1640 via conductive path 1645. Finally, component-side connector pad 1640 couples to Node A via PCB trace 1625. Thus, Node B ′ on board 1611 may be combined with Node A on board 1610. Since these boards share the same layout, the conductive paths 1652 and 1653 can be used in the same manner as the conductive paths 1650 and 1651 to other boards located adjacent to the board 1610. Thus, a unique inter-board connection scheme is provided using surface mount and through hole connectors without using switching components.

F. Timing-Insensitive Glitch-Free Logic Devices

One embodiment of the present invention solves the hold time and clock glitch problems. According to one embodiment of the invention, while a user designs with a hardware model of a reconfigurable computing system, the standard logic devices (latch, flip-flop) shown in the user design may be emulated logic devices, timing-insensitive glitch-free ( TIGF) is replaced by a logic device. In one embodiment, the trigger signal included in the EVAL signal is used to update the value stored in the TIGF logic device. After going through the user-designed hardware model during the estimation cycle and waiting for several inputs and other signals to reach a stable-state, a trigger signal is provided to update the values stored or latched by the TIGF logic device. After that, a new calculation cycle begins. In one embodiment, the calculation period-trigger period is periodic.

The above-mentioned hold time problem is briefly described. As is known, a common problem in logic circuit design is a hold time violation. The hold time must remain stable after the data input (s) of the logic element changes the latch, capture, or storage of the value indicated by the data input (s), but otherwise the logic element It is defined as the minimum time that does not work properly.

The shift register example is described to illustrate the hold time condition. 75A shows that multiple D-type flip-flops are connected in series, i.e., the output of flip-flop 2400 is connected to the input of flip-flop 2401, the output of which is the input of flip-flop 2402. An example shift register, shown, is shown. The entire input signal S _in is connected to the input of flip-flop 2400 and the entire output signal S _out is generated from the output of flip-flop 2402. All three flip-flops each receive a common clock signal at their clock inputs. The shift register design is based on the assumption that (1) the clock signal reaches every flip-flop in the illustration, and (2) the input of the flip-flop does not change during the hold time after detecting the edge of the clock signal.

Referring to the timing diagram of FIG. 75B, a hold time assumption is shown that the system does not violate the hold time condition. The hold time changes from one logic element to the next, but is not always specified on a particular sheet. At time t ₀ , the clock input changes from logic 0 to logic 1. As shown in FIG. 75A, a clock input is provided to each flip-flop 2400-2402. From the clock edge at (t ₀ ), input S _in must be stable for hold time T _H that lasts from time t ₀ to time t ₁ . Similarly, the inputs of flip-flops 2401 (D ₂ ) and 2402 (D ₃ ) must also be stable for the hold time from the trigger edge of the clock signal. Since the condition is satisfied in Figs. 75A and 75B, the input S _in is shifted to the flip-flop 2400, the input at (D ₂ (logic 0)) is shifted to the flip-flop 2401, ( The input at D ₃ (logic 1) is shifted to flip-flop 2402. As is known, after the clock edge is triggered, the new values at the flip-flop 2401 (logic 1 at input D ₂ and flip-flop 2402 (logic 0 at input D ₃ ) hold time conditions The shift is stored or stored at the next flip-flop in the next clock cycle, assuming it is satisfied The following table summarizes the operation of the shift register for the example values.

D ₁ D ₂ D ₃ Q ₃ Before clock edge One 0 One 0 After clock edge One One 0 One

In practical implementations, the clock signal does not reach all the logic elements at the same time, but the circuit is designed such that the clock signal arrives at all or substantially the same time for all the logic elements. The circuit is designed such that the clock skew, or time difference, between clock signals reaching each flip-flop is less than the hold time condition. Thus, every logic element captures the appropriate input value. In the example shown in Figs. 75A and 75B, the hold time violation due to the clock signal arriving at the flip flops 2400-2402 at different times may result in some flip-flops being moved while the other flip-flops are capturing new input values. This can result in capturing input values. As a result, the shift register does not operate properly.

In a reconfigurable logic (FPGA) implementation of the same shift register design, if the clock is generated directly from primary, the circuitry allows the low skew network to distribute the clock signal to all logic elements so that the logic elements are substantially simultaneously It can be designed to detect clock edges. The previous clock is generated from the self-time test-bench process. In general, the primary clock signal is generated in software and only a small (1-10) primary clock is found in a typical user circuit design.

However, if the clock signal is generated from internal logic instead of the primary input, the hold time becomes more important. The derivation or gate clock is generated from a network of register logic and combinational logic obtained by the primary clock. Many (more than 1000) inductive clocks are found in typical user circuit designs. Without external precautions or additional control, the clock signal may reach each logic element at a different time and the clock skew may be longer than the hold time. This causes circuit design such as the shift register circuit shown in Figs. 75A and 75B to fail.

Using the same shift register circuit shown in Fig. 75A, the hold time violation is described. However, at this time, individual flip-flops of the shift register circuit are spread over several reconfigurable logic chips (multiple FPGA chips) shown in FIG. 75A. The first FPGA chip 2411 includes internally obtained clock logic 2410 that provides a clock signal CLK to some components of the FPGA chip 2412-2416. In the above example, the internally generated clock signal CLK is provided to flip-flops 2400-2402 of the shift register circuit. Chip 2412 includes flip-flop 2400, chip 2415 includes flip-flop 2401, and chip 2416 includes flip-flop 2402. Two different chips 2413 and 2414 are provided to illustrate the concept of hold time violations.

Clock logic 2410 of chip 2411 receives a primary clock input (or another obtained clock input) to generate an internal clock signal CLK. The internal clock signal CLK is transmitted to the chip 2412 and is named CLK1. Internal clock signal CLK from clock logic 2410 is also sent to chip 2415 and is named (CLK2) via chips 2413 and 2414. As shown, CLK1 is input to flip-flop 2400 and CLK2 is input to flip-flop 2401. (CLK1) and (CLK2) have wire trace delays such that the deg of (CLK1) and (CLK2) is delayed from the edge of the internal clock signal (CLK). Moreover, (CLK2) has an additional delay since it is transmitted through two different chips 2413 and 2414.

Referring to the timing diagram of FIG. 76B, an internal clock signal CLK is generated and triggered at time t ₂ . Due to the wire trace delay, CLK1 does not reach flip-flop 2400 of chip 2412 until time t ₃ , which is a delay of time T ₁ . As shown in the table above, the output at (Q ₁ ) (or input D ₂ ) is logic 0 until the clock edge of (CLK1) is reached. After the edge of CLK1 is sensed at flip-flop 2400, the input at D ₁ must be stable for the required hold time H ₂ (up to time t ₄ ). At this time, the flip-flop 2400 shifts or stores the input logic 1 so that the output at Q ₁ (or D ₂ ) becomes logic 1.

While this occurs in flip-flop 2400, clock signal CLK2 proceeds to flip-flop 2401 of chip 2415. The delay T ₂ caused by chips 2413 and 2414 causes CLK2 to reach flip-flop 2401 at time t ₅ . If the input at D ₂ is logic 1 and then the hold time is satisfied for the flip-flop 2401, the logic value 1 appears at output Q ₂ (or D ₃ ). Thus, output Q ₂ is logic 1 before the arrival of CLK2 and output 1 continues logic 1 after the arrival of CLK2. This is a wrong result. The shift register is shifted to logic zero. Flip-flop 2400 correctly shifts to the previous input value (logic 1), while flip-flop 2401 incorrectly shifts to the new input value (logic 1). Typically this incorrect behavior occurs when the clock skew (or timing delay) is greater than the hold time. In this example, T2> T1 + H2. Consequently, hold time violations occur when some precautionary measures are not implemented, as shown in FIG. 76A, when the clock signal is generated from one chip and distributes the clock signal to other logic elements on another chip.

The aforementioned clock glitch problem is described with reference to FIGS. 77A and 77B. In general, when the circuit input changes, it changes to some random value for a very short time before the output stabilizes to the correct value. If another circuit examines the output at the wrong time and reads a random value, the result may be incorrect and it becomes difficult to debug. Any value that affects another circuit badly is called a glitch. In a typical logic circuit, one circuit can generate a clock signal for another circuit. If an uncompensated timing delay is present in one or two circuits, clock glitches (unplanned occurrences of the clock edges) may occur and this may cause incorrect results. Like hold time violations, clock glitches occur because any logic element in the circuit design changes values at different times.

77A generates a clock signal for another set of logic elements, namely D-type flip-flop 2420, D-type flip-flop 2421, and exclusive OR (XOR) gate 2422 is a D-type flip-flop. The clock signal CLK3 is generated for the 2423. Flip-flop 2420 receives data input at D ₁ at line 2425 and outputs data at Q ₁ at line 2427. The clock input CLK is received from the clock logic 2424. CLK is called the clock signal originally generated from clock logic 2424 and CLK1 is called the same signal delayed in the time it reaches flip-flop 2420.

Flip-flop 2421 receives data input at D ₂ at line 2426 and outputs data at Q ₂ at line 2428. Clock input CLK2 is received from clock logic 2424. CLK is called the clock signal originally generated from clock logic 2424 and CLK2 is called the same signal delayed in the time it reaches flip-flop 2421.

Outputs from flip-flops 2420 and 2421, respectively, at lines 2427 and 2428 are input to XOR gate 2422. XOR gate 2422 outputs data labeled CLK3 to the clock input of flip-flop 2423. Flip-flop 2423 also inputs data at D ₃ on line 2429 and outputs data at Q ₃ .

The clock glitch problem that may occur in the circuit is described with reference to the timing diagram shown in FIG. 77B. The CLK signal is triggered at time t ₀ . When the clock signal CLK1 reaches the flip-flop 2420, the time is t ₁ . CLK2 does not reach flip-flop 2421 until time t ₂ .

Assume that the inputs of D ₁ and D ₂ are both logic ones. When CLK1 reaches flip-flop 2420 at time t ₁ , the output at Q ₁ will be logic 1 (as shown in FIG. 77B). CLK2 arrives somewhat late at flip-flop 2420 at time t ₁ , so output Q ₂ at line 2428 remains logic 0 from time t ₁ to time t ₂ . XOR gate 2422 is CLK3 for being present at the clock input of flip-flop 2423 during the time period between time t ₁ and time t ₂ , even if the desired signal is logic 0 (1 XOR 1 = 0). As a result, logic 1 is generated. CLK3 generation during the time period between times t ₁ and t ₂ is a clock glitch. Thus, any logic value present at D ₃ in input line 2429 of flip-flop 2423, whether desired or not, is stored and the flip-flop 2423 prepares for the next input on line 2429. If properly designed, the time delays of CLK1 and CLK2 are minimized so that clock glitches are not generated, or at least, clock glitches last for a short period of time without affecting the rest of the circuit. In the latter case, if the clock skew between CLK1 and CLK2 is short enough, the XOR gate delay is long enough to filter out the glitches and will not affect the rest of the circuit.

Two known solutions to the hold time violation problem are (1) timing adjustment and (2) timing synthesis. The timing adjustment disclosed in US Pat. No. 5,475,830 requires the installation of sufficient delay elements (such as buffers) in any signal path to increase the hold time of the logic elements. For example, adding a sufficient delay on inputs D ₂ , D _{3 in} the shift register circuit can prevent hold time violations. Thus, in FIG. 78, the same shift register circuit is shown with delay elements 2430 and 2430 added to inputs D ₂ and D ₃ , respectively. As a result, delay element 2430 can be designed such that time t ₄ occurs after time t ₅ so that T2 < T1 + H2 (FIG. 76B) and hold time violations do not occur.

A potential problem with timing adjustment solutions is that too much is placed on a particular sheet of FPGA chip. As is known, reconfigurable logic chips, such as FPGA chips, implement logic elements with lookup tables. The delay of the lookup table in the chip is provided in a particular sheet and the designer relies on the specific time delay using a timing adjustment method that prevents hold time violations. However, the delay is only an estimate and varies from chip to chip. Another potential problem with the timing adjustment method is that the designer also compensates for the wiring delays that exist throughout the circuit design. Although this is not possible, the estimation of the wiring delay is time consuming and error prone. Moreover, the timing adjustment method does not solve the clock glitch problem.

Another solution is the timing synthesis introduced in IKOS's VirtualWires technology. The timing synthesis concept involves transforming the user's circuit design into a functionally identical design during the timing of the clock and tight control of the pin-out signal through remote machines and registers. Timing synthesis retimes the user's circuit design introduced by a single high speed clock. It also converts latches, gate clocks, and multiple synchronous and asynchronous clocks into flip-flop-based single-clock synchronous designs. Thus, timing synthesis uses registers at the input and output pin-out of each chip to control sophisticated inter-chip signal movement so that no inter-chip hold time violations occur. Timing synthesis also uses a machine in each chip's remote state to plan inputs from other chips, plan outputs to other chips, and schedule updates of internal flip-flops based on reference clocks.

Using the same shift register circuit described with respect to Figures 75A, 75B, 76A, 76B, Figure 79 shows an example of a timing synthesis circuit. The basic three flip-flop shift register designs have been transformed into functionally identical circuits. Chip 2430 includes an original internal clock that generates logic 2435 coupled to register 2443 via line 2448. Clock logic 2435 generates a CLK signal. The first remote state machine 2438 is also connected to the register 2443 via a line 2449. Register 2443 and first remote state machine 2438 are controlled by a design-independent global reference clock.

The CLK signal is also propagated across chips 2432 and 2433 before reaching chip 2434. At chip 2432, second remote state machine 2440 controls register 2445 via line 2442. The CLK signal is sent from register 2443 to register 2445 via line 2461. The register 2445 outputs the CLK signal through the line 2463 to the next chip 2433. Chip 2433 includes a third remote state machine 2441 that controls register 2446 via line 2464. The register 2446 outputs the CLK signal to the chip 2434.

Chip 2434 includes original flip-flop 2436. Register 2444 receives an input Sin and outputs an input S _in to the D ₁ input of flip-flop 2436 via line 2452. Q ₁ output of flip-flop 2436 is connected to register 2466 via line 2454. Fourth remote state machine 2439 controls register 2444 via line 2451, register 2466 via line 2455, and flip-flop 2436 through latch enable line 2453. To control. The fourth remote state machine 2439 also receives the original clock signal CLK from the chip 2430 via line 2450.

Chip 2434 includes an original flip-flop 2437, which receives a signal from register 2466 of chip 2431 at the D ₂ input over line 2456. Q ₂ output of flip-flop 2437 is connected to register 2447 via line 2457. Fifth remote state machine 2439 controls register 2447 through line 2459 and flip-flop 2437 through latch enable line 2458. The fifth remote state machine 2442 also receives the original clock signal CLK from the chip 2430 via the chips 2432 and 2433.

Using timing synthesis, remote state machines 2438-2442, registers 2443-2447, 2466, and a single global reference clock are used to control a single flow across multiple chips and to update internal flip-flops. Thus, at chip 2430, distributing the CLK signal to another chip is planned by the first remote state machine 2438 via the register 2443. Similarly, at chip 2431, fourth remote state machine 2439 passes input S _in to flip-flop 2436 through register 2444 and Q ₁ output through register 2466. To plan. The latching function of flip-flop 2436 is also controlled by the latch enable signal from the fourth remote state machine 2439. The same principle applies to logic in other chips 2432-2434. Using the inter-chip input transfer schedule, the inter-chip output transfer schedule, and strict control of internal flip-flop state update, the inter-chip hold-time violation is eliminated.

However, time synthesis techniques require transforming the user's circuit design into most functionally identical circuits, including remote state machines and registers. In general, the additional logic needed to implement this technique is 20% of the logic available in each chip. Moreover, the technique is not affected by clock glitch problems. To avoid clock glitch, designers must take additional precautionary steps using timing synthesis techniques. One conventional design approach is to design the circuit so that the input of the logic device using the gate clock does not change at the same time. The improved approach uses gate delay to filter the glitches so that the rest of the circuit is unaffected. However, as described above, timing synthesis requires some additional untried means to avoid clock glitches.

Various embodiments of the present invention that address hold time and clock glitch problems are discussed. While structurally mapping the user design to a software model of the RCC computing system and a hardware model of the RCC array, the latch shown in FIG. 18A is emulated with a timing insensitive cleat-free (TIGF) latch in accordance with one embodiment of the present invention. do. Similarly, the flip-flop design shown in FIG. 18B is emulated with a timing insensitive cleat-free (TIGF) latch in accordance with one embodiment of the present invention. TIGF logic devices in the form of latches or flip-flops may also be called emulation logic devices. Updates of TIGF latches and flip-flops are controlled by global trigger signals.

In one embodiment of the invention, not all logic devices found in the user design circuit are replaced by TIGF logic devices. The user design circuit includes a portion enabled or clocked by the primary clock and another portion controlled by the gate or obtained clock. Since hold time violations and clock glitches occur when a logic device is controlled by a gate or an obtained clock, only a particular logic device controlled by the gate or an obtained clock is replaced by TIGF in accordance with one embodiment of the present invention. In another embodiment, all logic devices found in the user designed circuit are replaced with TIGF logic devices.

Before describing the TIGF latch and flip-flop embodiments of the present invention, a global trigger signal is described. In general, the global trigger signal causes the TIGF latch and flip-flop to maintain the state (old input) during the calculation period and to update the state (new input) during the short trigger period. In one embodiment, the global trigger signal shown in FIG. 82 is separated and obtained from the EVAL signal described above. In this embodiment, the global trigger signal has a long calculation period followed by a short trigger period. The global trigger signal tracks the EVAL signal during the calculation period, and as a result of the EVAL cycle, a short trigger signal is generated to update the TIGF latch and flip-flop. In another embodiment, the EVAL signal is a global trigger signal, and the EVAL signal has one logic state (logic 0) during the calculation period and another logic state (logic 1) during the non-calculation or TIGF latch / flip-flop update period. Has

The calculation cycle described with reference to the RCC computing system and the RCC hardware array is used to drive all primary inputs and the flip-flop / latch device transforms the simulation cycle at any time into a full user design. During propagation, the RCC system will wait until all signals in the system achieve a steady-state. After the user design is mapped and placed in the appropriate reconfigurable logic element (eg, FPGA chip) of the RCC array, the evaluation period is calculated. Therefore, the evaluation period is a design specific matter. That is, the evaluation period for one user design may be different from the evaluation period for another user design. This evaluation period should be long enough to ensure that all signals in the system propagate through the entire system and reach steady state before the next short trigger period.

The short trigger period occurs at a time adjacent to the evaluation period, as shown in FIG. In one embodiment of the invention, the short trigger period occurs after the evaluation period. Before this short trigger period, the input signal propagates through the hardware model structuring portion of the user-designed circuit during the evaluation period. The short trigger period indicated by the change in the logical state of the EVAL signal in accordance with one embodiment of the present invention allows all TIGF latches and flips in the user design to be updated with new values propagated from the evaluation period after the steady state is reached. Control the flop. The short trigger period is distributed throughout the low skew network and may be short enough to allow the reconfigurable logic element to allow proper operation (i.e., t ₀ as well as t ₃ at duration t _{2 shown} in FIG. 82). Duration of t ₁ ). During the short trigger period, a new primary input is sampled for every input stage of the TIGF latch and flip-flop, and previously stored values of the same TIGF latch and flip-flop are exposed to the next stage of the RCC hardware model of your design. . In the description below, a portion of the total trigger signal that occurs during a short trigger period will be represented as a TIGF trigger, a TIGF trigger signal, a trigger signal, or simply a trigger.

Fig. 80A shows the latch 2470 that was first shown in Fig. 18A. The latch operation is as follows.

if (#S), Q ← 1

else if (#R), Q ← 0

else if (en), Q ← D

else Q retains the previous value

Since this latch is level-sensitive and asynchronous, the output Q tracks the input D while the clock input is enabled and the latch enable input is enabled.

Figure 80 (B) shows a TIGF latch in accordance with an embodiment of the present invention. As shown in Fig. 80A, the TIGF latch has a D input, an enable input, a set S, a reset R, and an output Q. Thus, the TIGF latch has a trigger input. The TIGF latch has a D flip-flop 2471, a multiplexer 2472, an OR gate 2473, an AND gate 2474, and various interconnections.

D flip-flop 2471 receives input of D flip-flop 2471 from the output of AND gate 2474 via line 2476. The D flip-flop is also triggered on the clock input by the trigger signal on line 2477, which is entirely distributed by the RCC system according to a strict schedule based on the evaluation cycle. The output of D flip-flop 2471 is connected to one input of multiplexer 2472 via line 2478. The multiplexer is controlled by an enable signal on line 2484. The output of multiplexer 2472 is connected to the input of OR gate 2473 via line 2479. The other input of OR gate 2473 is connected to the set (S) input on line 2480. The output of OR gate 2473 is connected to reset R on AND gate 2474 via line 2481. The output on AND gate 2474 is fed back to the input of D flip-flop 2471 via line 2476 as mentioned above.

The operation of this TIGF latch in an embodiment according to the present invention will be described. In an embodiment of the TIGF latch, the D flip-flop 2471 maintains the current state of the TIGF latch (ie, the previous value). Line 2476 at the input of D flip-flop 2471 represents a new input value latched to the TIGF latch. The main input (D input) of the TIGF latch on line 2475 ultimately passes through OR gate 2473 from the input of multiplexer 2472 (which ultimately has the appropriate enable signal on line 2484 to be displayed). And finally pass on AND gate 2474 on line 2483 and return the new input signal of the TIGF latch to D flip-flop 2471 on line 2476, so that line 2476 has a new value. Indicates. The trigger signal on line 2477 updates the TIGF latch by clocking the new input value to D flip-flop 2471. Thus, the output on line 2478 of D flip-flop 2471 represents the current state of the TIGF latch (ie, the previous value), and the input on line 2476 represents the new input latched by the TIGF latch.

Multiplexer 2472 receives the current state from D flip-flop 2471 as well as from a new input value on line 2475. Enable line 2484 functions as a selector for multiplexer 2472. Since the TIGF latch is not updated until a trigger signal is provided on line 2477, the D input of the TIGF latch on line 2475 and the enable input on line 2484 may reach the TIGF latch in any order. Can be. The TIGF latch (and other TIGF latches in a user-designed hardware model) is a conventional latch, as described in Figures 76 (A) and 76 (B), where one clock signal arrives far behind another clock signal. If a situation arises that would normally cause a duration error of the circuit used in this TIGF latch would function properly by maintaining the appropriate previous value until a trigger signal is provided on line 2477.

The trigger signal is distributed through a low skew common clock network.

This TIGF latch also solves the clock glitch problem. Note that the clock signal is replaced with the enable signal in the TIGF latch. The enable signal on line 2484 often causes a crash during the evaluation period, but the TIGF latch will remain in its current state without error. The only mechanism by which the TIGF latch can be updated is via a trigger signal provided after the evaluation period of the present invention, which in one embodiment is provided after the evaluation period when the steady state is reached.

FIG. 81 (A) shows flip-flop 2490 shown first in FIG. 18 (B). Flip-flops work like this:

if (#S), Q ← 1

else if (#R), Q ← 0

else if (rising edge of CLK), Q ← D

else Q retains the previous value

Because this latch is edge-triggered, while the flip-flop enable input is enabled, the output Q tracks the input D on the rising edge of the clock signal.

81 (B) shows a TIGF-D flip-flop according to an embodiment of the present invention. Similar to the flip flop of Fig. 81A, the TIGF flip flop has a D input, a set S, and an output Q.

The TIGF flip-flop also has a trigger input. TIGF flip-flops have three D flip-flops 2491, 2492, 2496, multiplexer 2493, OR gate 2494, two AND gates 2495, 2497, and various interconnections.

Flip-flop 2491 receives a TIGF D input on line 2498, a trigger input on line 2499, and provides a Q output on line 2500. This output line 2500 also functions as one of the inputs of the multiplexer 2493. The other input of multiplexer 2493 comes from the output Q of flip-flop 2492 via line 2503. The output of multiplexer 2493 is connected to one of the inputs of OR gate 2494 via line 2505. The other input of OR gate 2492 is the set (S) signal on line 2506. The output of OR gate 2494 is connected to one of the inputs of AND gate 2495 via line 2507. The other input of AND gate 2495 is a reset (R) signal on line 2508. The output of AND gate 2495 (which is also the total TIGF output Q) is connected to the input of flip-flop 2492 via line 2501. Flip-flop 2492 also has a trigger input on line 2502.

Returning to the multiplexer 2493, the selector input of the multiplexer 2493 is connected to the output of the AND gate 2497 via line 2509. AND gate 2497 receives one of the inputs from the CLK signal on line 2510 and receives another input from the output of flip-flop 2496 via line 2512. Flip-flop 2496 also receives an input from the CLK signal on line 2511 and a trigger input on line 2513.

The TIGF flip-flop operation of the embodiment of the present invention will be described. In this embodiment, the TIGF flip-flop is three different points (D flip-flop 2491 via line 2499, D flip-flop via line 2502, and D flip-flop via line 2513). 2424), a trigger signal is received.

TIGF flip-flops store the input value only when the edge of the clock signal is detected. According to one embodiment of the invention, the required edge is the rising edge of the clock signal. To detect the rising edge of the clock signal, an edge detector 2515 is provided. Edge detector 2515 includes a D flip-flop 2496 and an AND gate 2497. Edge detector 2515 is also updated via the trigger signal on line 2513 of D flip-flop 2496.

D flip-flop 2491 retains the new input value of TIGF flip-flop and resists any change in D input on line 2498 until a trigger signal is provided on line 2499. Therefore, before the evaluation period of the TIGF flip-flop, a new value is stored on the D flip-flop 2491. Therefore, the TIGF flip-flop can avoid the holding time error by pre-storing a new value until the TIGF flip-flop is updated by the trigger signal.

D flip-flop 2492 holds the current value (or previous value) of the TIGF flip-flop until a trigger signal is provided on line 2502. This value is the state of the emulated TIGF flip-flop, where the TIGF flip-flop is updated and before the next evaluation period. The input of D flip-flop 2492 on line 2501 maintains a new value (which is the same value on line 2500 for significant duration of the evaluation period).

Multiplexer 2493 receives the new input value on line 2500 and the previous value stored in the TIGF flip-flop on line 2503. Based on the selector signal on line 2504, the multiplexer outputs either the new value (line 2500) or the old value (line 2503) as the output of the simulated TIGF flip-flop. In the user-designed hardware model, before the entire propagated signal reaches steady state, this output is changed according to any clock accident. Thus, an input on line 2501 will represent a new value stored in flip-flop 2491 at the end of the evaluation period. When the trigger signal is received by a TIGF flip-flop, flip-flop 2492 stores the new value present on line 2501 and flip-flop 2491 stores the next new value on line 2498. Therefore, the TIGF flip-flop according to the embodiment of the present invention is not adversely affected by the clock accident.

In addition, TIGF flip-flops also provide immunity to clock bursts. Those skilled in the art will appreciate that by replacing the flip-flops 2420, 2421, 2423 with the TIGF flip-flops of Figure 81 (B), the clock accident does not affect any circuit using this TIGF flip-flop. 77 (A) and 77 (B), because of the flip-flop 2423 clocked to the new value while not being clocked to the new value for the time between the times t ₁ and t ₂ , the clock accident is shown in FIG. 77. It adversely affects the circuit of (A). The skew nature of CLK1 and CLK2 causes the XOR gate 2422 to generate a logic 1 state during the time period between times t ₁ and t ₂ to drive the clock line of the next flip-flop 2423. In a TIGF flip-flop according to an embodiment of the present invention, the clock accident does not affect the clocking of the new value. If the flip-flop 2423 is replaced with a TIGF flip-flop, and the signal reaches a steady state during the evaluation period, the trigger signal during the short trigger period enables the TIGF flip-flop to flip the new value to the flip-flop 2491 (Fig. 91). (B)). Next, any clock rupture such as the clock rupture of Fig. 77 (B) during the time interval from the times t ₁ and t ₂ will not clock the new value. The TIGF flip-flop simply updates the trigger signal and the trigger signal does not appear on the TIGF flip-flop until after the evaluation period when signal propagation through the circuit has reached steady state.

In this particular embodiment, the TIGF flip-flop is a D flip-flop, but other flip-flops (eg, T. JK, SR) are possible within the present invention. Another form of edge trigger flip-flop can be derived from the D flip-flop by adding AND / OR logic before the D input.

Iii. Simulation server

Simulation server according to another embodiment of the present invention is provided such that multiple users access the same reconfigurable hardware unit to simulate and accelerate these or different user designs in a time shared manner. A high speed simulation scheduler and state swapping mechanism are used to provide a simulation server with an active simulation process resulting in high yield. The server is provided to multiple users or processes to access reconfigurable hardware units for acceleration and hardware state replacement purposes. Once acceleration is achieved or hardware state is accessed, each user or process is simulated only in software, thereby releasing control of the reconfigurable hardware unit to another user or process.

In the simulation server portion of this specification, terms such as "job" and "process" are used. In this specification, the terms "job" and "process" are generally used interchangeably. In the past, batch systems performed "jobs" and time sharing systems stored and executed "processes" or programs. In today's systems, these tasks and processes are similar. Thus, in this specification, the term "job" is not limited to batch type systems and "process" is not limited to time sharing systems. Rather, in the extreme case where a "process" is performed without any interruption in a time slice or by another time-sharing interrupter, the "task" is the same as the "process" and the "task" is completed. In other extreme cases, where a multi-time slice is required for this purpose, the "work" is a subset of the "process". Thus, if a "process" requires multiple time slices for completed execution due to the presence of other equal priority users / processes, the "process" is divided into "tasks". Also, if a "process" does not require multiple time slices for completed execution because the only high priority user or process is sufficient to complete within the time slice, the "process" is the same as the "task." Thus, a user may interact with one or more "processes" or programs executed and loaded in the simulation system, and each "process" may require one or more "tasks" to complete the time sharing system.

In one architecture of the present invention, multiple users via a remote terminal can access the same reconfigurable hardware unit and review / debug the same or different user circuit designs in the same microprocessor workstation in a non-network environment. You can use (workstation). In a non-network environment, the remote terminal can be connected to the primary computing system for access to operational functions. This non-network architecture allows multiple users to share access to the same user design for parallel debugging purposes. The access is achieved by a time sharing process in which a scheduler determines access priorities for multiple users, swap operations, and optionally lock hardware units among scheduled users. In other cases, multiple users may access the same reconfigurable hardware unit using separate, different user design servers of users for debugging purposes. In another architecture, multiple users or processes share multiple microprocessors within a workstation with an operating system. In another architecture, multiple users or processes within separate microprocessor-based workstations can access the same reconfigurable hardware unit to review / debug the same or different user circuit designs throughout the network. Similarly, the scheduler is achieved by a time sharing process that determines the priority of access for lock hardware unit access among multiple users, replacement jobs, and optionally scheduled users. In a networked environment, the scheduler listens for network requests through UNIX socket system calls. The operating system uses the socket to deliver commands to the scheduler.

As mentioned above, the simulation scheduler uses a preemptive multi-priority round robin algorithm. That is, the high priority user or process is serviced first until the user or process completes the task and terminates the session. Among the same priority users or processes, a preemptive round robin algorithm is used in which an operation is executed until the same time slice is assigned and completed for each user or process. The time slice is short enough that you do not have to wait long before multiple users or processes are serviced. The time slice is also long enough so that the scheduler of the simulation server can be replaced by interrupting one user or process and sufficient action is executed before executing a new user task. In one embodiment of the present invention, the default time slice is 5 seconds and is user settable. In one embodiment, the scheduler makes specific calls to the operating system's built-in scheduler.

Figure 45 illustrates a non-network environment with a multiprocessor workstation in an embodiment in accordance with the present invention. Figure 45 is a variant of Figure 1, therefore, the same reference numbers will be used for the same components / units. Workstation 1100 includes a local bus 1105, a host / PCI bridge 1106, a memory bus 1107, and a main memory 1108. Cache memory systems (not shown) may also be provided. Other user interface units (eg, monitors, keyboards) are also provided but are not shown in FIG. Workstation 1100 also includes multiple microprocessors 1101, 1102, 1103, 1104 connected to local bus 1105 via scheduler 1117 and connection / path 1118. As is known to those skilled in the art, operating system 1121 provides a user-hardware interface foundation for the entire computing environment for managing files and assigning various users, processes, and devices within the computing environment. Operating system 1121 and bus 1122 are shown for conceptual purposes. For operating systems, reference may be made to Abraham Silberschatz and James L. Peterson, OPERATING SYSTEM CONCEPTS (1988) and William Stallings, MODERN OPERATION SYSTEM (1996).

In one embodiment of the invention, workstation 1100 is a Sun Microsystems Enterprise 450 system utilizing an UltraSPARC II processor. Instead of accessing memory via the local bus, the Sun 450 system allows multiprocessors to access memory via the bus for memory through a crossbar switch. Reference is made to the specifications of the Sun 450 system and the Sun UltraSPARC Multiprocessor. The Sun Ultra 60 system allows only two processes, but could be an example of a microprocessor system.

Scheduler 1117 provides time sharing access to reconfigurable hardware unit 20 via device driver 1119 and connection / path 1120. The scheduler 1117 is typically implemented in software to interact with the operating system of the host computing system and partly in hardware to interact with the simulation server by supporting simulation job interrupts in internal / external simulation sessions. . Scheduler 1117 and device driver 1119 will be described in detail below.

Each microprocessor 1101-1104 may independently process other microprocessors in the workstation 1101. In one embodiment of the present invention, workstation 1100 operates under a UNIX-based operating system, while in other embodiments, workstation 1100 may operate under a Windows-based or Macintosh-based operating system. In UNIX-based systems, users have X-Windows for programs, tasks, and files as needed. For more information on UNIX operating systems, see Maurice J. Bach, THE DESIGN OF THE UNIX OPERATING SYSTEM (1986).

In FIG. 45, multiple users can be accessed to workstation 1100 using a remote terminal. At times, each user may be using a particular CPU to run a process. In other cases, each user uses a different CPU depending on resource limitations. Usually, operating system 1121 determines this access, and the operating system can jump from the CPU to another to complete the task. To handle the time sharing process, the scheduler listens for network requests through the socket system and makes system calls to the operating system 1121, which in turn generate interrupt signals by the device driver 1119 to the reconfigurable hardware unit 20. It deals with preemption by initiating. This interrupt signal generation becomes one of a number of steps to the scheduling algorithm that includes stopping the current task, storing state information about the currently interrupted task, replacing the task, and executing a new task. The server scheduling algorithm will be described below.

We will briefly describe socket and socket system calls. The UNIX operating system of one embodiment may operate in a time sharing mode. The UNIX kernel allocates the CPU to a process for a period of time (eg, a time slice) and at the end of the time slice, preempts the process and schedules the next for the next time slice. Processes preempted from the previous time slice are rescheduled for execution in the later time slice.

One structure for enabling and facilitating interprocess communication and for enabling the use of complex network protocols is sockets. The kernel contains three layers that operate within the scope of the client-server model. The upper layer, the socket layer, provides the interface between the system call and the lower layer (protocol layer and device layer). Typically, a socket has an end point that associates a client process with a server process. The socket endpoint may be another device. The middle layer, the protocol layer, provides protocol modules for communication such as TCP and IP. The lower layer, which is the device layer, includes device drivers for controlling the network devices. One example of a device driver is an Ethernet driver on an Ethernet based network.

The process communicates using a client-server model in which a server process listens for sockets at one endpoint and a client process listens for server processes on different sockets at different endpoints in a bidirectional communication path. The kernel maintains internal connections among the three layers of each client and server, and transfers data from the client to the server as needed.

The socket contains several system calls that include a socket system bean that forms an endpoint of the communication path. Many processes use socket descriptors for many system calls. The bind system call associates a name with a socket descriptor. Some other example systems include a connection system call request where the kernel connects to the socket, a close system call to close the socket, a shutdown system call to close the socket connection, and send and receive The call sends data through the connected socket.

46 illustrates another embodiment of the present invention in which multiple workstations share a single time-based, single simulation system over a network. Within the computing environment of the simulation system, a single CPU 11 is connected to the local bus 12 of the station 1110. Multiple CPUs can be provided to this system. As is known to those skilled in the art, an operating system 1118 is provided and all nearby processes and applications reside on top of the operating system. Operating system 1121 and bus 1122 are shown for conceptual purposes.

In FIG. 46, workstation 1110 includes a component / unit shown in FIG. 1, and a scheduler bus 1118 connected to local bus 12 via scheduler 1117 and operating system 1121. The scheduler 1117 controls time sharing access to the user stations 1111, 1112, 1113 by making a socket call to the operating system 1121. The scheduler 1117 is implemented mostly in software, in part in hardware.

In this figure only three users are shown and the simulation system can be accessed via a network. Of course, other system architectures may be provided for three or more users or fewer users. Each user accesses the system via remote station 1111, 112, or 1113. Remote user stations 1111, 112, and 1113 are connected to the scheduler 1117 via network connections 1114, 1115, and 1116, respectively.

As is known to those skilled in the art, a device driver 1119 is connected between the PCI bus 50 and the reconfigurable hardware unit 20. A connection or electroconductive path 1120 is provided between the device driver 1119 and the reconfigurable hardware unit 20. In this network multi-user implementation of the invention, the scheduler 1117 communicates with and controls the reconfigurable hardware unit 20 for hardware acceleration and simulation after hardware state recovery purposes via the device driver 1119 via the operating system 1121. ) And the interface.

In addition, in one embodiment of the invention, the simulation workstation 1100 is a Sun Microsystems Enterprise 450 system using an UltraSPARC II multiprocessor. Instead of accessing memory via the local bus, the Sun 450 system allows a multiprocessor to access memory through a crossbar switch via a bus for memory instead of tying up to the local bus.

47 illustrates a high level structure of a simulation server according to a network embodiment of the present invention. Here, the operating system is not explicitly shown, but as is known in the art, it is always present for file management and resource allocation purposes to service devices of various users, processes, and simulation computing environments. Simulation server 91130 includes a scheduler 1137, one or more device drivers 1138, and a reconfigurable hardware unit 1139. Although not explicitly shown as a single integrated unit in FIGS. 45 and 46, the simulation server includes a scheduler 1117, a device driver 1119, and a reconfigurable hardware unit 20. Returning to FIG. 47, the simulation server 1130 is connected to three workstations 1131, 1132, and 1133 (or users) via network connections / paths 1134, 1135, and 1136, respectively. As mentioned above, three or more or three or fewer workstations may be connected to the simulation server 1130.

The scheduler of the simulation server is based on a preemptive round robin algorithm. In essence, the round robin structure allows a lifetime of users or processes to run continuously to complete a cyclical performance. Thus, each simulation task (associated with a workstation in a network environment or a user / process in a multiprocessing non-network environment) is assigned to a priority level and a fixed time slice to be executed.

In general, high priority tasks are executed first for completion. In the extreme case, if different users each have a different priority, the user with the highest priority is served first until his work is completed, and the user with the lowest priority is serviced last. Here, no time slice is used because each user has a different priority and the scheduler simply serves the user according to the priority. This scenario is similar to having only one accessing simulation system to completion.

In extreme cases, different users have the same priority. Thus, the concept of time slice with a first-in first-out (FIFO) queue is used. Of the same priority jobs, each job runs first until either it is completed or until the end of a fixed time slice. Next, this job is placed at the end of the queue. If a saved simulation image exists, the next task is restored and executed on the next time slice.

High priority jobs can preempt low priority jobs. That is, tasks of the same priority are operated in a round robin fashion until executed over time slices for completeness. Next, lower priority tasks are run in a round robin fashion. If a high priority job is queued while a low priority job is running, the high priority job will preempt the low priority job until the high priority job is completed. If a low priority task has already started executing, the low priority task is no longer executed to complete until the high priority task is completed.

In one embodiment of the invention, the UNIX operating system provides a basic and basic preemptive round robin scheduling algorithm. The scheduling algorithm of the simulation server according to an embodiment of the present invention operates in conjunction with the scheduling algorithm of the operating system. In UNIX based systems, the preemptive nature of the scheduling algorithm is provided to allow the operating system to preempt a user defined schedule. To enable the time sharing architecture, the simulation scheduler uses a preemptive multi-priority round robin algorithm on top of the operating system's scheduling algorithm.

The relationship between multiple users and a simulation server according to an embodiment of the present invention follows a client-server model, where multiple users are clients and simulation servers are servers. Communication between the user client and the server takes place via socket calls. Referring to Figure 55, a client includes a client program 1109, a socket system call component 1123, a UNIX kernel 1124, and a TCP / IP protocol component 1125. The server includes a TCP / IP protocol component 1126, a UNIX kernel 1127, a socket system call component 1128, and a simulation server 1129. Multiple clients require simulation to be simulated on the server through UNIX socket calls from the client application program.

In one embodiment of the present invention, a typical series of events includes multiple clients that forward requests to the server via the UNIX socket protocol. For each request, the server acknowledges the request as to whether the command was executed successfully. For the request of the server queue status, the server can respond to the current queue status so that it can be properly displayed to the user. Table F below shows the relevant socket commands from the client.

Table F: Client Socket Commands

Command Explanation 0 Start simulation <design> One Stop simulation <design> 2 Simulation <design> Exit 3 Reassign Priorities to Simulation Sessions 4 Save Design Simulation State 5 Status queue

For each socket call, each instruction encoded as an integer may be followed by additional parameters, such as <design>, indicating the design name. If the command runs successfully, the response from the simulation server will be "0" and if the command fails, it will be "1". For command " 5 " requesting queue status, there is ASCII text terminated by " 0 " to be displayed on the user screen as one embodiment of the command's return response. In these system socket calls, the appropriate communication protocol signal is sent to or received from the reconfigurable hardware unit via the device driver.

48 shows an embodiment of a simulation server according to the present invention. As described above, multiple users or multiple processes can be serviced by a single simulation server for time-sharing simulation and hardware acceleration of user designs. Accordingly, users / processes 1147, 1148, and 1149 are connected to simulation server 1140 via each of the interprocess communication paths 1150, 1151, 1152. Interprocess communication paths 1150, 1151, and 1152 may exist at the same workstation or in a network for multiple workstations for multiprocessor architecture and operation. Each simulation session includes a software simulation state and a hardware state for communicating with the reconfigurable hardware unit. Interprocess communication during a software session provides the ability to have a simulation session on the same workstation with a UNIX socket or simulator plug-in card installed or connected via a TCP / IP network on a separate workstation. This is done using the provided system call. Communication with the simulation server is automatically initiated.

In FIG. 48, the simulation server 1140 includes a server monitor 1141, a simulation work queue table 1142, a priority sorter 1143, a job changer 1144, a device driver 1145, and reconfigurable hardware. Unit 1146. The simulation work queue table 1142, priority classifier 1143, and job changer 1144 constitute the scheduler 1137 shown in FIG.

Server monitor 1141 provides a user interface function for the administrator of the system. The user can monitor the simulation server status by instructing to display simulation jobs in the queue and scheduling priorities, usage history, and simulation job replacement efficiency. Other usage features include editing task priorities, deleting simulation tasks, and resetting the simulation server state.

The simulation work queue table 1142 holds a list of all outstanding simulation requests in the queue inserted by the scheduler. The table entries include job number, software simulation process number, software simulation image, hardware simulation image file, design structure file, priority number, hardware size, software size, cumulative time of simulation run, and owner identification. Work queues are implemented using first-in, first-out (FIFO) queues. Thus, when new work is required, it is placed at the end of the queue.

Priority classifier 1143 determines which jobs in the queue are to be executed. In one embodiment, the simulation task priority structure is user definable (ie, controllable and definable by the system administrator) to control which simulation process has priority over current execution. In another embodiment, the priority level is dynamic and may change during the simulation. In a preferred embodiment, the priority is based on the user ID. Typically, one user has a high priority and all other users have a low but equal priority.

The priority level can be set by the system administrator. The simulator server gets all user information from the UNIX machine in the UNIX user file called "/ etc / passwd". Adding new users is constant throughout the process of adding new users in a UNIX system. After all users have been defined, a simulation server monitor can be used to adjust the priority level for the user.

The work shifter 1144 temporarily replaces one simulation associated with one process or workstation with another simulation associated with another process or workstation based on prioritization programmed for the user. If multiple users simulate the same design, work shifts are shifted in the saved simulation state only during the simulation session. However, if multiple users simulate multiple designs, the work shifter loads into the hardware structural design before the alternation of the simulated state. In one embodiment, the work shift mechanism improves the performance of the time sharing implementation of the present invention since work shifts should only be done for reconfigurable hardware unit access. Thus, if one user needs software simulation for some time period, the server can alternate to other tasks for the other user so that the other user can access the reconfigurable hardware unit for hardware acceleration. The frequency of work shifts is user adjustable and programmable. The device driver also communicates with reconfigurable hardware units to alternate work.

To explain the operation of the simulation server. 49 shows a flowchart of the simulation server in operation. First, at step 1160, the system is idle. If the system is idle at step 1160, the simulation server does not need to be inactive and the simulation job is not running. An idle state can mean one of the following situations: (1) the simulation is not running; (2) only users / workstations are active in a single processor environment so no time sharing is required; Or (3) only one user / workstation is active but only one process is running. Thus, condition 2 and condition 3 above have only one job to be processed by the simulation server, so that no waiting, prioritization, and job replacements are required, and essentially, requests from other workstations or processes (events) (1161)), the simulation server is idle because it is not receiving.

If a simulation request is caused by one or more request signals from a workstation in a multi-user environment or from a microprocessor in a multiprocessor environment, the simulation server waits at step 1162 for the incoming simulation task or tasks. The scheduler maintains a simulation work queue and inserts a list of all outstanding simulation requests to insert all outstanding simulation requests into the queue. For batch simulation tasks, the server's scheduler waits for all incoming simulation requests and automatically processes tasks without human intervention.

The simulation server then sorts the jobs waiting to determine priority in step 1163. This step is particularly important for multiple tasks where the server must prioritize among the multiple tasks to provide access to the reconfigurable hardware unit. The priority classifier decides what jobs in the queue should be run. In one embodiment, the simulation task priority structure is user definable (i.e., controllable and definable by the system administrator) to control which processes have priority for current execution if there is a resource contention.

After the priority classification of step 1163, the next server replaces the simulation task at step 1164 as needed. This step temporarily replaces one simulation task associated with one process or one workstation with another simulation task associated with another process or workstation based on prioritization programmed for the server's scheduler. If multiple users simulate the same design, the job changer only replaces in the saved simulation state during the simulation session. However, if multiple users simulate multiple designs, the job changer first loads the designs before replacement in the simulated state. Here, the device driver also communicates with the reconfigurable hardware unit to replace the task.

In one embodiment, the task replacement mechanism improves the performance of the time sharing embodiment of the present invention because task replacement should only be done for reconfigurable hardware unit access. Thus, if a user needs software simulation for any period of time, the server will be replaced with another task for the other user so that the other user can access the reconfigurable hardware for hardware acceleration. For example, suppose two users, User1 and User2, are connected to a simulation server to access a reconfigurable hardware unit. At any time, user 1 can access the system so that debugging can be performed for his user design. If User 1 debugs only in software mode, the server releases the reconfigurable hardware unit so that User 2 can access the server. The server is replaced with a job for User2, and User2 can simulate software or accelerate hardware. Based on the priority between User 1 and User 2, User 2 can continue to access the reconfigurable hardware unit for a predetermined time, or if User 1 needs a reconfigurable hardware unit for acceleration, the server can By preempting the task for two, the task for user 1 can be replaced for hardware acceleration using the reconfigurable hardware unit. Reference is made to the preemption of simulator tasks based on multiple requests of the same priority for a given time. In one embodiment, the default time is 5 minutes, but the user can set the time between moves. Setting this five minutes represents one form of time-out timer. The simulation system of the present invention uses a timeout timer to suspend execution of the current simulation task, which is excessively time consuming and the system determines whether other progress tasks of the same priority should gain access to the reconfigurable hardware model. Because.

Upon completion of the task changeover step of step 1164, the device driver of the server locks the reconfigurable hardware unit so that only currently scheduled users or processes simulate and use the hardware model. The locking and simulation step occurs at step 1165.

Upon completion of the simulation or suspension of the current simulating session at event 1166, the server returns to priority classifier step 1163 to later determine the priority of the current simulation task and later replaces the simulation task if necessary. Similarly, to return the server to priority classifier state 1163, the server may preempt the operation of the active simulation job in conflict at event 1167. Preemption only occurs under certain conditions. One such condition is when high priority work is in progress. The other of these is when the system is currently running a simulation-intensive simulation job, in which case the scheduler can be programmed to preempt a job in progress to schedule jobs of the same priority using a timeout timer. . In one embodiment, if the timeout timer is set to 5 minutes and the current task is performed for 5 minutes, the system preempts the current task and replaces the ongoing task even if it is at the priority level.

50 is a flowchart of a job replacement process. The job change function is performed in step 1164 of FIG. 49 and is shown in the simulation server hardware as the job changer of FIG. In FIG. 50, if the simulation task needs to be replaced with another simulation task, the task changer sends an interrupt to the reconfigurable hardware unit in step 1180. If the reconfigurable hardware unit is not currently doing any work (i.e. when the system is idle or the user is operating in software simulation mode with only hardware acceleration intervention), the interrupt is immediately reconfigurable for task replacement. Prepare the hardware unit. However, if the reconfigurable hardware unit is currently executing a task and is executing a command or processing data, the interrupt signal is recognized but the reconfigurable unit executes the instruction currently in progress and processes the data for the current task. . If the reconfigurable hardware unit receives an interrupt signal and the current simulation task is not executing instructions or processing data, the interrupt signal essentially stops the operation of the reconfigurable hardware unit immediately.

In step 1181, the simulation system stores the current simulation image (ie, hardware and software state). By storing this image, the user can later restore the simulation run without rerunning the entire simulation to the stored point.

In step 1182, the simulation system configures the reconfigurable hardware unit with the new user design. This configuration step is only required if a new task has already been configured and loaded into the reconfigurable hardware unit and its execution is related to a user design different from the interrupted user design. After configuration, the stored hardware simulation image is reloaded in step 1183 and the stored hardware simulation image is reloaded in step 1184. If a new simulation task is associated with the same design, no additional configuration is required. In the case of the same design, since the simulation image for the new task is appropriately different from the simulation image for only the interrupted task, the simulation system performs the desired hardware simulation associated with the new simulation task for the same design in step 1183. Load the image. The details of the construction steps will be described. The relevant software simulation image is then reloaded at step 1184. After reloading the hardware and software simulation images, simulation can be initiated for this new task, but previously interrupted tasks can only proceed in software simulation mode because there is no access to reconfigurable hardware for the time being.

51 shows signals between the device driver and the reconfigurable hardware unit. Device driver 1171 provides an interface between scheduler 1170 and reconfigurable hardware unit 1172. The device driver 1171 also provides an interface between the entire computing environment (ie, workstation, PCI bus, PCI device) and the reconfigurable hardware unit 1172 as shown in FIGS. 45 and 46. Fig. 51 shows only the simulation server portion. The signal between the device driver and the reconfigurable hardware is a bidirectional communication handshake signal, one-way design configuration information from the computing environment to the reconfigurable hardware unit via the scheduler, information replaced with the simulation state, information replaced with the simulation state. And the interrupt signal from the device driver to the reconfigurable hardware unit can be replaced.

Line 1173 transmits a bidirectional communication handshake signal. These signal and handshake protocols will be described in more detail with reference to FIGS. 53 and 54.

Line 1174 sends unidirectional design configuration information from the computing environment to reconfigurable hardware unit 1172 via scheduler 1170. Initial configuration information will be sent to the reconfigurable hardware unit 1172 for modeling purposes on this line 1170. In addition, when a user models and simulates a different user design, the configuration information must be sent to the reconfigurable hardware unit 1172 during the time slice. If different users model the same user design, no design configuration is required, but rather different simulation hardware states associated with the same design will need to be sent to reconfigurable hardware unit 1172 for different simulation operations.

Line 1175 sends the information replaced with simulation state information to reconfigurable hardware unit 1172. Line 1176 is replaced in the simulation state information from the reconfigurable hardware unit to the computing environment (ie, usually memory). The information replaced with the simulation state includes previously stored hardware model state information and the hardware memory state in which the reconfigurable hardware unit 1172 needs to be accelerated. The replaced status information is transmitted at the beginning of time so that the scheduled current user can access the reconfigurable hardware unit 1172 for acceleration. The replaced state information includes memory state information that must be stored in memory at the end of the time slice in a reconfigurable hardware unit 1172 that receives an interrupt signal to move to the next time slice associated with a different user / process than the hardware model. do.

Line 1177 transmits an interrupt signal from device driver 1171 to a reconfigurable hardware unit so that the simulation task can be replaced. This interrupt signal is sent between time slices to ensure that it is replaced by the current simulation task in the current time slice and replaced by a new simulation task during the next time slice.

A communication handshake protocol according to an embodiment of the present invention will be described with reference to FIGS. 53 and 54. Figure 53 illustrates a communication handshake signal between a device driver and a reconfigurable hardware unit via a handshake logic interface. 54 is a state diagram of a communication protocol. 51 illustrates a communication handshake signal on line 1173. 53 is a detailed view of the communication handshake signal between the device driver 1171 and the reconfigurable hardware unit 1172.

In Figure 53, handshake logic interface 1234 is provided to reconfigurable hardware unit 1172. In addition, the handshake logic interface 1234 may be installed outside the reconfigurable hardware unit 1172. Four sets of signals are provided between the device driver 1171 and the handshake logic interface 1234. These signals are a 3-bit SPACE signal on line 1230, a single bit read / write signal on line 1231, a 4-bit COMAND signal on line 1232, and a single bit DONE signal on line 1233. The handshake logic interface includes logic circuitry that processes these signals so that they are placed in a reconfigurable hardware unit in an appropriate mode for the various operations in which they need to be performed. The interface is coupled to a CTRL_FPGA unit (or FPGA I / O controller).

For 3-bit SPACE signals, data transfer between the computing environment of the simulation system and the reconfigurable hardware units over the PCI bus is a software / hardware boundary--REG (register), CLK (software clock), and S2H (software to hardware). , And H2S (hardware to software)-for any I / O address space. As described above, the simulation system maps the hardware model into four address spaces of main memory according to different component types and control functions. The CLK space is designated as the software clock, the S2H space is designated as the output to the hardware model of the software test-bench component, and the H2S space is designated as the output of the software test-bench component of the hardware model. These dedicated I / O buffer spaces are mapped into the kernel's main memory space during system initialization.

The following table G describes each SPACE signal.

Table G: SPACE Signal

SPACE Explanation 000 Hardware (DMA wr) in total (or CLK) space and software 001 Register write (DMA wr) 010 From hardware to software (DMA wd) 011 Register read (DMA wd) 100 SRAM Write (DMA wr) 101 SRAM Read (DMA wd) 110 No use 111 No use

The read / write signal on line 1231 indicates whether the data transfer is read or written. The DONE signal on line 12330 indicates the completion of the DMA data transfer period.

The 4-bit COMMAND indicates whether the data transfer operation should be a read, write, configure new user design in a reconfigurable hardware unit, or interrupt the simulation. As shown in Table H, the COMMAND protocol is as follows.

Table H: COMMAND Signal

COMMAND Explanation 0000 Write to specified space 0001 Read from the designated space 0010 FPGA design configuration 0011 Simulation interrupt 0100 No use

A communication handshake protocol will be described below with reference to the state diagram of FIG. In state 1400, the simulation system of the device driver is idle. Unless a new command is displayed, the system is idle as indicated in path 1401. If a new command is displayed, the command processor processes the new command in state 1402. In one embodiment, the command processor is an FPGA I / O controller.

If COMMAND = 0000 OR COMMAND = 0001, the system writes to or reads from the designated space as indicated by the SPACE index in state 1403. If COMMAND = 0010, the system configures the FPGA in a reconfigurable hardware unit as a user design, or configures the FPGA as a new user design in state 1404. The system sequence configuration information for every FPGA models the part of the user design that can be modeled in hardware. However, if COMMAND = 0011, the system interrupts part of the user's design at state 1405 to interrupt the simulation system, because the time slice will time out for the new user / process to swap in the new simulation state. . Upon completion of this state 1403, 1404 or 1405, the simulation system proceeds to DONE state 1406 to generate a DONE signal and returns to state 1400 to wait for a new command to exist.

The time-sharing features of the simulation server, which deal with various tasks with different levels of priority, are now described. 52 illustrates one embodiment. Four tasks (Task A, Task B, Task C, Task D) are the input tasks of the simulation work queue. However, the priorities for these four tasks are different. That is, jobs A and B are assigned to high priority I and jobs C and D are assigned to low priority II. As shown in the time line chart of FIG. 52, the time division reconfigurable hardware unit performs according to the priority of the queued input task. At time 1190, the simulation begins with task A accessing reconfigurable hardware. At time 1191, task A is preempted by task B, because task B has the same priority as task A and the scheduler provides the same time division access to the two tasks. Task B now needs to access the reconfigurable hardware unit. At time 1192, task A preempts task B and task A is executed at time 1193. At time 1193, task B takes over and completes until time 1194. At time 1194, task C (which is next in the queue but of lower priority than tasks A and B) now accesses the reconfigurable hardware unit for execution. At time 1195, task D preempts task C for time division access, because task D has the same priority as task C. Task D now accesses up to time 1196 preempted by task C. Task C is completed at time 1197. At time 1197 task D takes over and completes until time 1198.

VIII. Memory simulation

Memory simulation or memory mapping according to one aspect of the present invention provides an efficient way for a simulation system to manage various memory blocks associated with a constituent hardware model of a user design. The user design is programmed into an array of FPGAs in a reconfigurable hardware unit. By implementing one embodiment of the present invention, the memory simulation scheme does not require any dedicated pins in the FPGA chip to handle memory access.

As used herein, the term "memory access" refers to a write access or a read access between an FPGA logic device in which a user design is implemented and an SRAM memory device that stores all memory blocks associated with the user design. Thus, the write operation transfers data from the FPGA logic device to the SRAM memory device, while the read operation transfers data from the SRAM memory device to the FPGA logic device. Referring to FIG. 56, an FPGA logic device includes 1201 (FPGA 1), 1202 (FPGA 2), 1203 (FPGA 3), and 1204 (FPGA 4). SRAM memory devices include memories 1205 and 1206.

The term "DMA data transfer" also refers to data transfer between a computing system and a simulation system in addition to the general meaning commonly used by those skilled in the art. The computing system is shown in Figures 1, 45, 46 as a complete PCI-based system with memory that supports the simulation system, residing in reconfigurable hardware units and software. In the selected device, the socket / system requesting to / from the operating system is also part of the simulation system that allows for proper interface with the reconfigurable hardware unit and the operating system. In one embodiment of the invention, the DMA read transfer transfers data from the FPGA logic device (and the FPGA SRAM memory device for initialization and memory content dump) to the host computing system.

The "FPGA data bus", "FPGA bus", "FD bus" and their analogy refer to the high bank bus FD [63: coupling an FPGA logic device and an SRAM memory device containing the configuration to be debugged and the user design programmed. 32] and low bank bus FD [31: 0].

The memory simulation system includes a memory state machine, an evaluation state machine, and associated logic for controlling and interfacing to the following devices: (1) the main computing system and associated memory system, and (2) coupling with the FPGA bus in the simulation system. An SRAM memory device, and (3) an FPGA logic device comprising a configuration to be debugged and a programmed user design.

The FPGA logic device side of the memory simulation system includes an evaluation state machine, an FPGA bus driver, and a logic interface for each memory block N for interfacing with a user's own memory interface in a user design that handles the following: ( 1) Data evaluation between FPGA logic devices, (2) Write / read memory access between FPGA logic device and SRAM memory device. With respect to the FPGA logic device side, the FPGA I / O controller side includes (1) the main logic system and the SRAM memory device and (2) the interface logic to handle the writing and reading of operations and DMA between the FPGA logic device and the SRAM memory device; It includes a memory state machine.

Operation of memory simulation according to an embodiment of the present invention is generally as follows. The simulation write / read cycle is divided into three cycles (DMA data transfer, evaluation, and memory access). The DATAXSFR signal represents the DMA data transfer period, where the computing system and the SRAM memory unit are each connected via an FPGA bus (high bank bus (FD [63:32]) 1212 and low bank bus (FD [31: 0]) 1213, respectively. Send data to another device.

During the evaluation cycle, the logic circuit of each FPGA logic device generates the appropriate software clock, input enable, and MUX enable signals for user design logic for data evaluation. Inter-FPGA logic device communication occurs in this period.

During the memory access period, the memory simulation system waits for the high and low bank FPGA logic devices to send each address and control signal to each FPGA data bus. If the operation is a write operation, address, control, and data signals are transferred from the FPGA logic device to each SRAM memory device. If the operation is a read operation, address, control, and data signals are provided to the designated SRAM memory device, and the data signal is sent from the SRAM memory device to each FPGA logic device. As a result, the desired memory block is accessed in all FPGA logic devices, the memory simulation write / read cycle is complete, and the memory simulation system waits until the next memory simulation write / read cycle is onset.

56 shows a high level block diagram of a memory simulation configuration in accordance with an embodiment of the present invention. Signals, connections, buses and the like that are not relevant to the features of the present invention are omitted. The CTRL_FPGA unit 1200 described above is connected to bus 1210 via line 1209. In one embodiment, CTRL_FPGA unit 1200 is a programmable logic device (PLD) in the form of an FPGA chip, such as an Altera 10K50 chip. Logic bus 1210 allows CTRL_FPGA unit 1200 to be connected to other simulation array boards and other chips (e.g., PCI controllers, EEPROMs, clock buffers) if available. Line 1209 carries a simulated DMA data transfer period and a DONE signal indicating completion.

56 illustrates another major functional block in the form of a logic device and a memory device. In one embodiment, the logic device is a programmable logic device (PLD) in the form of an FPGA chip such as an Altera 10K130 or 10K250 chip. Thus, instead of the embodiment described above with eight Altera FLEX 10K100 chips in the array, an embodiment with only four Altera FLEX 10K130 chips can be used. The memory device is a synchronous pipeline cache SRAM such as a Cypress 128Kx32 CY7C1335 or CY7C1336 chip. The SRAM chip includes a low bank memory device 1205 (L_SRAM) and a high bank memory device 1206 (H_SRAM).

These logic and memory devices are connected to CTRL_FPGA unit 1200 via high bank bus 1212 (FD [63:32]) and low bank bus 1213 (FD [31: 0]). Logic devices 1201 (FPGA 1) and 1202 (FPGA 2) are connected to high bank bus 1212 via bus 1223 and bus 1225, respectively, and logic devices 1203 (FPGA 1) and 1204 (FPGA 3) connect buses 1224 and 1226, respectively. Is connected to the low bank bus 1213. The high bank memory device 1206 is connected to the high bank bus 1212 via bus 1220 and the low bank memory device 1205 is connected to low bank bus 1213 via bus 1219. The dual bank bus structure allows the simulation system to access devices on the high bank and devices on the low bank in parallel with improved throughput rates. The dual bank data bus structure supports other signals, such as control and address signals, and allows the simulation write / read cycle to be controlled.

Referring again to FIG. 61, each simulation write / read cycle includes a DMA data transfer cycle, an evaluation cycle, and a memory access cycle. The combination of various control signals controls and directs which of the cycles the simulation system corresponds to. In a reconfigurable hardware unit, DMA data transfers between logic devices 1201 through 1204 and host computers can be transferred to PCI buses (eg, bus 50 in FIG. 46), local buses 1210 and 1236, and FPGA buses 1212 (FD [63:32]); Via 1213 (FD [31: 0]). Memory devices 1205 and 1206 cause DMA data transfers for initialization and memory content dump. Evaluation data transfer between logic devices 1201 through 1204 in the reconfigurable hardware unit is via interconnect and FPGA bus 1212 (FD [63:32]) and 1213 (FD [31: 0]).

Referring to FIG. 56, the CTRL_FPGA unit 1200 sends and receives many control and address signals to control the simulation write / read cycle. The CTRL_FPGA unit 1200 provides DATAXSER and EVAL signals on line 1211 to transmit to logic devices 1201 and 1203 via line 1221 and to logic devices 1202 and 1204 via line 1222. The CTRL_FPGA unit 1200 also provides a memory address signal MA [18: 2] over the buses 1229 and 1214 to the low bank memory device 1205 and the high bank memory device 1206, respectively. To control the mode of this memory device, the CTRL_FPGA unit 1200 provides a chip select write (and read) signal to the low bank memory device 1205 and the high bank memory device 1206 via lines 1216 and 1215. To indicate completion of the DMA data transfer, the memory simulation system may send and receive a DONE signal on line 1209 to the CTRL_FPGA unit 1200 and the computing system.

As described above in connection with FIGS. 9, 11, 12, 14, and 15, logic devices 1201 through 1204 are illustrated in FIG. 56 by two sets of SHIFTIN / SHIFTOUT lines (lines 1207, 1227, 1218 and lines 1208, 1228, 1217). Are connected to each other by a multiplexed cross chip address pointer chain. This set is initialized at the beginning of the chain by Vcc at lines 1207 and 1208. The SHIFTIN signal is sent from the previous FPGA logic device in the bank to initiate memory access for the current FPGA logic device. When the shift is completed over a given set of chains, the final logic device generates a LAST signal (ie, LASTL or LASTH) and sends it to CTRL_FPGA unit 1200. For the high bank, the logic device 1202 generates a LASTH shiftout signal on line 1218 and sends it to CTRL_FPGA unit 1200. For the low bank, the logic device 1204 generates a LASTL signal on line 1217 and sends it to CTRL_FPGA unit 1200. do.

With reference to FIG. 56 and the board implementation, one embodiment of the present invention provides components (eg, logic devices 1201-1204, memory devices 1205-1206, and CTRL_FPGA unit 1200) and buses (eg, FPGA buses 1212-1213 and local buses). 1210 is integrated on one board. These original boards are connected to the motherboard through motherboard connectors. Thus, four logic devices (two for each bank), two memory devices (one for each bank), and a bus are provided on one board. The second board includes a complementary logic device (typically four), a memory device (typically two), an FPGA I / O controller (CTRL_FPGA unit) and a bus. The inter-board connectors described above are provided between the boards so that logic devices on all boards can connect to each other and communicate during the evaluation period, and the local bus connects all these boards to each other. The FPGA bus FD [63: 0] is unique to each board and does not span multiple boards.

In the board implementation, the simulation system performs memory mapping between the logic device and the memory device on each board. No memory mapping is performed between the different boards. Thus, a logic device on board 5 maps a block of memory to a memory device on board 5 and does not map to a memory device on another board. However, in another embodiment of the present invention, the simulation system may map memory blocks from logic devices on one board to memory devices on another board.

Operation of the memory simulation according to an embodiment of the present invention is generally as follows. The simulation write / read cycle is divided into three cycles (DMA data transfer, evaluation, and memory access). To indicate completion of the simulation write / read cycle, the memory simulation system may send and receive a DONE signal on line 1209 for the CTRL_FPGA unit 1200 and the computing system. The DATAXSFR signal on bus 1211 indicates the occurrence of a DMA data transfer cycle, where computing systems and FPGA logic devices 1201 through 1204 are FPGA data buses, high bank buses (FD [63:32]) 1212 and low bank buses (FD [31). : 0]) Send data to another device through 1213. In general, DMA transfers occur between a host computing system and an FPGA logic device. For initialization and memory content dump, DMA transfers occur between the host computing system and the SRAM memory devices 1205 and 1206.

During the evaluation period, the logic circuits of each FPGA logic device 1201 through 1204 generate a software clock, input enable, and MUX enable signal suitable for the user design for data evaluation. Inter-FPGA logic device communication occurs during this period. CTRL_FPGA unit 1200 also operates an evaluation counter for the duration of the evaluation cycle. The number of counters, and thus the duration of the evaluation period, is set by the system by determining the longest path of the signal. The path length is related to a certain number of steps. The system uses the step information and calculates the number of counters needed to run the evaluation cycle during its completion.

During the memory access period, the memory simulation system waits for the high and low bank FPGA logic devices 1201-1204 to send address and control signals, respectively, on the FPGA data bus. This address and control signal is latched by CTRL_FPGA unit 1200. If the operation is a write operation, address, control, and data signals are sent from the FPGA logic devices 1201 through 1204 to the SRAM memory devices 1205 through 1206, respectively. If the operation is a read operation, address and control signals are sent from the FPGA logic devices 1201 through 1204 to the SRAM memory devices 1205 through 1206, respectively, and data signals are sent from the SRAM memory devices 1205 and 1206 into the FPGA logic devices 1201 through 1204, respectively. . On the FPGA logic device side, the FD bus driver places the address and control signals of the memory block on the FPGA data bus (FD bus). If the operation is a write operation, write data is located on the FD bus for the memory block. If the operation is a read operation, the double buffer latches data for the memory block on the FD bus from the SRAM memory device. This operation is performed sequentially for each memory block of each FPGA logic device. When all the desired memory blocks of the FGPA logic device have been accessed, the memory simulation system performs the next FPGA logic device in each bank and begins accessing the memory blocks of the FPGA logic device. After all desired memory blocks in all FPGA logic devices 1201 through 1204 have been accessed, the memory simulation write / read cycle is complete, and the memory simulation system waits until onset of other memory simulation write / read cycles.

57 shows a block diagram of a memory simulation in accordance with the present invention, including a more detailed structural diagram of each logic device associated with CTRL_FPGA unit 1200 and memory simulation. 57 shows CTRL_FPGA unit 1200 and logic device 1203 (which is structurally similar to other logic devices 1201, 1202, 1204). The CTRL_FPGA unit 1200 is a memory finite state machine (MEMFSM) 1240, AND gate 1241, evaluation (EVAL) counter 1242, low bank memory address / control latch 1243, low bank address / control multiplexer 1244, address counter 1245, high bank memory address / Control latch 1247, and high bank address / control multiplexer 1246. Each logic device, such as logic device 1203 shown in FIG. 57, includes an evaluation finite state machine (EVALFSMx) 1248, a data bus multiplexer (FDO_MUXx for FPGA 0 logic device 1203) 1249. The " x " indicated at the end of the EVALFSM represents the relevant specific logic device (FPGA 0, FPGA 1, FPGA 2, FPGA 3), and in this embodiment "x" is 0, 1, 2, 3. Thus, EVALFSM 0 is associated with FPGA 0 logic device 1203. In general, each logic device is associated with the same number x, and " x " represents 0 to N-1 when N logic devices are used.

In each logic device 1201-1204, various memory blocks are associated with the user design that is configured and mapped. Thus, in consumer logic, memory block interface 1253 provides a means for a computing system to access a desired memory block of an FPGA logic device. Memory block interface 1253 also provides memory write data on bus 1295 to be transmitted to FPGA data bus multiplexer (FDO_MUXx) 1249 and receives memory read data on bus 1297 from memory read data double buffer 1251.

Memory block data / logic interface 1298 is provided for each FPGA logic device. Each of these memory block data / logic interfaces 1298 is coupled to an FPGA data bus multiplexer (FDO_MUXx) 1249, an evaluation finite state machine (EVALFSMx) 1248, and an FPGA bus FD [63: 0]. Memory block data / logic interface 1298 is a memory readout data double buffer 1251, address offset unit 1250, memory model 1252, and memory block interface 1253 for each memory block N (mem_block_N) (these are all FPGAs given for each memory block N). Repeated for logic devices 1201-1204). Thus, for five memory blocks, five sets of memory block data / logic interface 1298 are provided. That is, five sets of memory read data double buffers 1251, address offset unit 1250, memory model 1252, and memory block interface 1253 for each memory block N (mem_block_N) are provided.

Like EVALFSMx, "x" in FDO_MUXx refers to the particular logic device involved (FPGA 0, FPGA 1, FPGA 2, FPGA 3), where "x" is 0, 1, 2, 3. The output of FDO_MUXx 1249 is provided on bus 1282, which is a high bank bus FD [63:32] or low depending on which chip (FPGA 0, FPGA 1, FPGA 2, FGPA 3) is associated with FDO_MUXx 1249. It is connected to bank bus FD [31: 0]. In FIG. 57, FDO_MUXx is FDO_MUX0, which is associated with low bank logic device FPGA0 1203. Thus, the output on bus 1282 is provided to low bank bus FD [31: 0]. Portion of bus 1283 is used to transfer read data from high bank FD [63:32] or low bank FD [31: 0] bus to read bus 1283 for input to memory read data double buffer 1251. Therefore, write data is transferred from the memory blocks of each logic device 1201 through 1204 via FDO_MUX0 1249 to the high bank FD [63:32] or low bank FD [31: 0] buses, and the read data is read through the read bus 1283. Memory read data is transferred from the high bank FD [63:32] or low bank FD [32: 0] buses to the double buffer 1251. The memory read data double buffer provides a double buffled mechanism to latch data in the first buffer, and is buffled again to obtain data latched at the same time to minimize skew. This memory read data double buffer 1251 will be described in more detail below.

Referring to memory model 1252, the memory model 1252 converts a user memory type into an SRAM type of a memory simulation system. Since the memory type of the user design can vary from one type to another, this memory block interface 1253 may also be unique for the user design. For example, the user's memory type may be DRAM, flash memory, or EEPROM. However, at all the various memory block interfaces 1253, memory address and control signals (eg, read, write, chip select, mem_clk) are provided. One embodiment of a memory simulation according to the present invention converts a user memory type into an SRAM type used in a memory simulation system. If your memory type is SRAM, conversion to SRAM type memory model is unique. Thus, memory address and control signals are provided on bus 1296 and sent to memory model 1252, which performs the translation.

Memory model 1252 provides memory block address information on bus 1293 and control information on bus 1292. The address offset unit 1250 receives address information for the various memory blocks and provides a modified offset address on the bus 1291 from the original address on the bus 1293. The offset is necessary because the addresses of any memory block can overlap each other. For example, one memory block may use space 0-2K and be present here, while another memory block may use space 0-3K and be present here. Since two memory blocks overlap in space 0-2K, individual addressing will be difficult without any addressing offset mechanism. Thus, the first memory block may use space 0-2K and be present here, while the second memory block may use and be here using spaces from 2K to 5K. The offset address from offset unit 1250 and the control signals on bus 1292 are combined and provided on bus 1299 and sent to FPGA bus multiplexer (FDO_MUXx) 1249.

The FPGA data bus multiplexer FDO_MUXx receives SPACE2 data on bus 1289, address / control signals on bus 1299, and memory write data on bus 1295. As mentioned above, SPACE2 and SPACE3 are specific space indices. The SPACE index generated by the FPGA I / O controller (reference numeral 327 in FIGS. 10 and 22) selects a particular address space (eg, REG read, REG write, S2H read, H2S write, and CLK write). Within this address, the system according to the invention selects a particular word to be addressed. SPACE2 refers to the memory space dedicated to the DMA read transfer of hardware-software H2S data. SPACE3 refers to a memory space dedicated to DMA read transfer of REGISTER_READ data. See Table G above.

FDO_MUXx 1249 outputs data on bus 1282 for a low bank or high bank bus. The selector signal is a select signal on line 1285 from EVALFSMx unit 1248 and an output enable signal on line 1284. The output enable signal on line 1284 enables (or disables) operation of FDO_MUXx 1249. For data access to the FPGA bus, the output enable signal is enabled to allow FDO_MUXx to function. A select signal on line 1285 is generated by EVALFSMx unit 1248 to output a predetermined number of outputs from SPACE2 data on bus 1289, SPACE3 data on bus 1290, address / control signals on bus 1299, and memory write data on bus 1295. Select. The generation of the selection signal by the EVALFSMx unit 1248 is described below.

The EVALFSMx unit 1248 is at the heart of the operation of each logic device 1201 through 1204 with respect to the memory simulation system. The EVALFSMx unit 1248 receives, as its input, a SHIFTIN signal on line 1279, an EVAL signal from CTRL_FPGA unit 1200 on line 1274, and a write signal wrx on line 1287. EVALFSMx unit 1248 selects SHIFTOUT signal on line 1280, read latch signal rd_latx on line 1286 for memory read data double buffer 1251, output enable signal on line 1284 for FDO_MUXx 1249, and on line 1285 for FDO_MUXx 1249 Signal and three signals for common logic (input_en, mux_en, clk_en) on line 1281.

The operation of FPGA logic devices 1201 through 1204 for a memory simulation system in accordance with the present invention is described. When the EVAL signal is logic 1, data evaluation is performed within the FPGA logic devices 1201-1204. Otherwise, the simulation system performs DMA data transfer or memory access. When EVAL = 1, EVALFSMx unit 1248 generates clk_en signal, input_en signal, mux_en signal, allowing user logic to evaluate the data, latch related data, and multiplex signal for the logic device, respectively. The EVALFSMx unit 1248 generates a clk_en signal to enable the second flip-flop of all clock edge registers in the user design (see FIG. 19). Otherwise, the clk_en signal will be a spotware clock. If the user's memory type is synchronous, the clk_en signal also enables the second clock of the memory read data double buffer 1251 of each memory block. The EVALFSMx unit 1248 generates an input_en signal for the user design to latch the input signal sent from the CPU to the user's logic by the DMA transfer. The input_en signal provides an enable input for the second flip-flop of the main clock register (see FIG. 19). Finally, the EVALFSMx unit 1248 generates a mux_en signal that turns on the multiplexing circuitry within each FPGA logic device to initiate communication with other FPGA logic devices in the array.

Thus, if FPGA logic devices 1201 through 1204 include at least one memory block, the memory simulation system waits for the selected data to be shifted to the selected FPGA logic device, and the address of memory block interface 1253 (mem_block_N) on the FD bus and Generates a select signal and an output_en signal for the FPGA data bus driver to transmit control signals.

If write signal wrx on line 1287 is enabled (ie, logic 1), the select signal and output_en signal are enabled to transfer write data onto a low bank or high bank bus depending on which bank the FPGA chip is connected to. . In FIG. 57, logic device 1203 is FPGA0 and is connected to low bank bus FD [31: 0]. If write signal wrx on line 1287 is disabled (ie, logic 0), the select signal and output_en signal are disabled, and the line for transfer to memory read data double buffer 1251 depending on which bank the FPGA chip is connected to. The read latch signal rd_latx on 1286 latches and double buffs selected data from the SRAM via a low bank or high bank bus. The wrx signal is a memory write signal sent from the memory interface of the user design logic. The wrx signal on line 1287 is obtained from memory model 1252 via control bus 1292.

This process for writing or reading data occurs at each FPGA logic device. After all of the memory blocks have been processed through the SRAM, the EVALFSMx unit 1248 generates a SHIFTPUT signal that allows the SRAM to be accessed by the next FPGA logic device in the chain. Memory accesses to devices on the high and low banks are performed in parallel. At times, memory access to one bank may be completed before memory access to another bank. For all such accesses, appropriate wait cycles are inserted, causing the logic to process the data only when the logic is ready and the data is available.

On the CTRL_FPGA unit 1200 side, MEMFSM 1240 forms the core of the memory simulation according to the present invention. It transmits and receives a number of control signals for controlling the activity of the memory simulation write / read cycles, whereby the cycles control various operations. The MEMFSM 1240 receives the DATAXSFR signal on line 1260 over line 1258. The signal is also provided to each logic device on line 1273. When DATAXSFR goes low (ie, logic low), the DMA data transfer cycle is complete, and the evaluation and memory access cycle begins.

The MEMFSM 1240 also receives a LASTH signal on line 1254 and a LASTL signal on line 1255 to indicate the selected word associated with the selected address space accessed between the computing system and the simulation system via the PCI bus and the FPGA bus. The MOVE signal associated with this shift out process is transmitted through each logic device (e.g., logic devices 1201 through 1204) until the desired word is accessed, and at the end of the chain the MOVE signal eventually results in a LAST signal (i.e. a high bank). LASTH for a row bank and LASTL for a low bank). In EVALFSM 1248 (ie, FIG. 57 shows EVALFSM0 for FPGA0 logic device 1203), the corresponding LAST signal is a SHIFTOUT signal on line 1280. Since the particular logic device 1203 is not the last logic device in the low bank chain as shown in FIG. 56 (logic device 1204 is the last device in the low bank chain in FIG. 56), the SHIFTOUT signal for EVALFSM0 is not a LAST signal. If EVALFSM 1248 corresponds to EVALFSM2 of FIG. 56, the SHIFTOUT signal on line 1280 is the LASTL signal provided on line 1255 for MEMFSM. Otherwise, the SHIFTOUT signal on line 1280 is provided to logic device 1204 (see FIG. 56). Similarly, the SHIFTIN signal on line 1280 represents Vcc for the FPGA0 logic device 1203 (see FIG. 56).

The LASTL and LASTH signals are input to AND gate 1241 through lines 1256 and 1257, respectively. The output of AND gate 1241 produces a DONE signal on line 1259, which is provided to the computing system and MEMFSM 1240. Thus, when both the LASTL and LASTH signals are logic high indicating the end of the shifted out chain, the process will bring the AND gate output to logic high.

MEMFSM 1240 generates a start signal on line 1261 for EVAL counter 1242. As the name suggests, the start signal triggers the start of the EVAL counter 1242 and is sent after completion of the DMA data transfer period. The start signal is generated when the DATAXSFR signal detects a transition from high to low (1 to 0). EVAL counter 1242 is a programmable counter that counts a predetermined number of clock cycles. The duration of the count programmed in EVAL counter 1242 determines the duration of the evaluation cycle. The output of EVAL counter 1242 on line 1274 has logic level 1 or 0 depending on whether the counter is counting or not counting. When the EVAL counter 1242 counts, the output of line 1274 is logic 1, which is provided to each FPGA logic device 1201 through 1204 via EVALFSMx 1248. When EVAL = 1, FPGA logic devices 1201 through 1204 perform inter FPGA communication to evaluate data in the user design. The output of the EVAL counter 1242 is fed back onto the line 1262 to the MEMFSM unit 1240 for its tracking purposes. At the end of the programmed count, the EVAL counter 1242 generates a logic 0 signal on lines 1274 and 1262 to indicate the completion of the evaluation period.

If no memory access is desired, the MEM_EN signal on line 1272 goes to logic 0 and is provided to MEMFSM unit 1240. In this case, the memory simulation system waits for another DMA data transfer cycle. If memory access is desired, the MEM_EN signal on line 1272 becomes logic one. In this case, the MEM_EN signal is a control signal from the CPU that enables the on-board SRAM memory device for accessing the FPGA logic device. Here, the MEMFSM unit 1240 waits for the FPGA logic devices 1201 through 1204 to place address and control signals on the FPGA buses FD [63:32] and FD [31: 0].

The remaining functional units and associated control signals and lines transfer address / control information to the SRAM memory device for data writing and reading. This unit includes a memory address / control latch 1243 for a low bank, an address control mux 1244 for a low bank, a memory address / control latch 1247 for a high bank, an address control mux 1246 for a high bank, and an address counter 1245. .

The memory address / control latch 1243 for the row bank receives the address and control signals and the latch signals on line 1263 from the FPGA bus FD [31: 0] that matches bus 1213. Latch 1243 generates a mem_wr_L signal on line 1264 and transmits the address / control signal received from FPGA bus FD [31: 0] to address / control mux 1244 over bus 1266. This mem_wr signal is the same as the chip select write signal.

The address / control mux 1244 receives, as input, address information and address and control information on the bus 1266 from the address counter 1245 over the bus 1268. Address / control mux 1244 outputs address / control information on bus 1276 and transmits to low bank SRAM memory device 1205. The select signal on line 1265 provides the appropriate select signal from MEMFSM unit 1240. The address / control information on the bus 1276 corresponds to the chip select read / write signals on the buses 1229 and 1216 and MA [18: 2] shown in FIG.

Address counter 1245 receives information from SPACE4 and SPACE5 over bus 1267. SPACE4 contains DMA write transfer information. SPACE5 includes DMA read transfer information. Thus, such DMA transfers occur between the computing system (cache / main memory via the workstation CPU) and the simulation system (SRAM memory devices 1205, 1206) over the PCI bus. The address counter 1245 provides its output to buses 1288 and 1268 to send to address / control mux 1244 and 1246. By providing an appropriate select signal on line 1265 for the low bank, address / control mux 1244 can be used as an address / control information or alternative on bus 1266 for read / write memory access between SRAM device 1205 and FPGA logic devices 1203 and 1204. DMA write / read transfer data from SPACE4 or SPACE5 on bus 1276 is provided on bus 1276.

During a memory access period, MEMFSM unit 1240 provides a latch signal on line 1263 for memory address / control latch 1243 to fetch input from FPGA bus FD [31: 0]. The MEMFSM unit 1240 extracts mem_wr_L control information from the address / control signal on the FD [31: 0] for further control. If the mem_wr_L signal on bus 1264 is logic 1, a write operation is desired, and an appropriate select signal on line 1265 is generated by MEMFSM unit 1240 and sent to address / control mux 1244 so that address / control signal on bus 1266 is transferred to bus 1276. Is transferred to the low bank SRAM on the top. Thereafter, write data transfer occurs from the FPGA logic device to the SRAM memory device. If the mem_wr_L signal on bus 1264 is logic 0, a read operation is desired, and the simulation system waits for data on the FPGA bus FD [31: 0] sent by the SRAM memory device. Once the data is ready, a read data transfer occurs from the SRAM memory device to the FPGA logic device.

Similar configurations and operations are provided for high banks. Memory address / control latch 1247 for the high bank receives address and control signals and latch signals on line 1270 from FPGA bus FDs [63:32] matching bus 1212. Latch 1270 generates a mem_wr_H signal on line 1271 and transmits an address / control signal coming into address / control mux 1246 from FPGA bus FD [63:32] over bus 1239.

Address / control mux 1246 receives address information and address and control information on bus 1239 as input from address counter 1245 over bus 1268. Address / control mux 1244 outputs address / control information on bus 1277 and transmits to high bank SRAM memory device 1206. The select signal on line 1269 provides the appropriate select signal from MEMFSM unit 1240. The address / control information on the bus 1277 corresponds to the chip select read / write signals on the buses 1214 and 1215 and MA [18: 2] shown in FIG.

The address counter 1245 receives information from SPACE4 and SPACE5 over bus 1267 as with the DMA write and read transfer described above. The address counter 1245 provides its output to buses 1288 and 1268 to send to address / control mux 1244 and 1246. By providing an appropriate select signal on line 1269 for the high bank, address / control mux 1246 can be used as an address / control information or alternative on bus 1239 for read / write memory access between SRAM device 1206 and FPGA logic devices 1201 and 1202. DMA write / read transfer data from SPACE4 or SPACE5 on bus 1267 is provided on bus 1277.

During the memory access period, MEMFSM unit 1240 provides a latch signal on line 1270 for memory address / control latch 1247 to fetch input from FPGA bus FD [63:32]. The MEMFSM unit 1240 extracts mem_wr_H control information from the address / control signal on the FD [63:32] for further control. If the mem_wr_H signal on bus 1271 is logic 1, a write operation is desired, and an appropriate select signal on line 1269 is generated by MEMFSM unit 1240 and sent to address / control mux 1246, so that the address / control signal on bus 1239 is bus 1277. Is transferred to the high bank SRAM. Thereafter, write data transfer occurs from the FPGA logic device to the SRAM memory device. If the mem_wr_H signal on bus 1271 is logic 0, a read operation is desired, and the simulation system waits for data on the FPGA bus FD [63:32] sent by the SRAM memory device. Once the data is ready, a read data transfer occurs from the SRAM memory device to the FPGA logic device.

As shown in FIG. 57, address and control signals are provided to the low bank SRAM memory device and the high bank memory device via buses 1276 and 1277, respectively. Bus 1276 for the low bank corresponds to the combination of buses 1229 and 1216 in FIG. Similarly, bus 1277 for high bank corresponds to the combination of buses 1214 and 1215 of FIG. 56.

The operation of the CTRL_FPGA unit 1200 for the memory simulation system according to the present invention is generally as follows. The DONE signal on line 1259 provided to the MEMFSM unit 1240 of the CTRL_FPGA unit 1200 and the computing system indicates the completion of the simulation write / read cycle. The DATAXSFR signal on line 1260 indicates the occurrence of the DMA data transfer period of the simulation write / read cycle. Memory address / control signals on FGPA buses FD [31: 0] and FD [63:32] are provided to memory address / control latches 1243 and 1247 for the high and low banks, respectively. For each bank, the MEMFSM unit 1240 generates a latch signal 1263 or 1269 to latch the address and control information. The information is then transferred to an SRAM memory device. The mem_wr signal is used to determine if a write or read operation is intended. If a write operation is desired, data is transferred from the FPGA logic devices 1201 through 1204 to the SRAM memory device via the FPGA bus. If a read operation is desired, the simulation system waits for the SRAM memory device to provide the requested data on the FPGA bus for transfer from the SRAM memory device to the FPGA logic device. For DMA data transfer of SPACE4 and SPACE5, the select signal on lines 1265 and 1269 selects the output of address counter 1245 when data is transferred between the SRAM memory device of the simulation system and the main computing system. For all such accesses, the appropriate wait cycle is inserted so that the logic processes the data only when the logic is ready and the data is available.

60 shows memory read data double buffer 1251 (FIG. 57) in more detail. Each memory block N in each FPGA logic device has a double buffer to latch related data that may come in at different times and to buffer this related latched data simultaneously. In FIG. 60, the double buffer 1391 for memory block 0 includes two D-type flip-flops 1340 and 1341. An output 1344 of the first D-type flip-flop 1341 is connected to an input of the second D-type flip-flop 1341. The output 1344 of the second D-type flip-flop 1341 is the output of the double buffer provided to the memory block N interface of the user design. The global clock input is provided to a first flip-flop 1340 on line 1393 and a second flip-flop 1341 on line 1394.

The first D flip-flop receives data input from the SRAM memory device on line 1342 via FPGA bus FD [63:32] for the high bank and FPGA bus FD [31: 0] and bus 1283 for the low bank. . The enable input is connected to line 1345 which receives the rd_latx (eg rd_lat0) signal from the EVALFSMx unit for each FPGA logic device. Thus, for a read operation (ie wrx = 0), the EVALFSMx unit generates an rd_latx signal to latch data on lines 1342 and 1343. The input data of all double buffers of all memory blocks come at different times, and the double buffer causes all data to be latched first. Once all data has been latched to D flip-flop 1340, a clk_en signal (ie, a software clock) is provided on line 1346 as the clock input for second D flip-flop 1341. Given the clk_en signal, the latched data on line 1343 is buffered onto D flip-flop 1341 on line 1344.

For the next memory block 1, another double buffer 1392 is provided which is substantially the same as the double buffer 1391. Data from the SRAM memory device is input on line 1396. The global clock signal is the input on line 1397. The clk_en (software clock) signal is input to the second D flip-flop (not shown) of the double buffer 1392 on line 1398. These lines are connected to the analog signal lines for the first double buffer 1391 for memory block 0 and all other double buffers for memory block N. Double buffered data outputs are provided on line 1399.

An rd_latx signal (e.g., rd_lat0) for the second double buffer 1392 is provided on line 1395 separately from other rd_latx signals for the other double buffer. More double buffers are provided for other memory blocks N.

Hereinafter, a state diagram of the MEMFSM unit 1240 according to an embodiment of the present invention will be described. 58 shows a state diagram of a finite state machine of the MEMFSM unit of the CTRL_FPGA unit. The state diagram of FIG. 58 is configured such that the three states in the simulation write / read cycle also have their corresponding states. Thus, states 1300-1301 correspond to DMA data transfer periods, states 1302-1303 correspond to evaluation periods, and states 1305-1314 correspond to memory access periods. See FIG. 57 in connection with FIG. 58 to be described below.

In general, signal sequences for DMA transfers, evaluations, and memory accesses are set. In one embodiment, the sequence is as follows: If possible, DATA_XSFR triggers DAM data transfer. LAST signals for the high and low banks are generated when the DMA data transfer is completed, triggering the DONE signal to indicate the completion of the DMA data transfer period. Then, the XSFR_DONE signal is generated and the EVAL cycle begins. When EVAL is completed, memory write / read starts.

Referring to FIG. 58, when the DATAXSFR signal is logic 0, the state 1300 always waits. This means that no DMA data transfer takes place. When the DATAXSFR signal is logic 1, the MEMFSM unit 1240 proceeds to state 1301. Here, the computing system requires DMA data transfer between the computing system (main memory of FIGS. 1, 45, 46) and the simulation system (FPGA logic devices 1201-1204 or SRAM memory device 1205 of FIG. 56). The appropriate wait cycle is inserted until the DMA data transfer is complete. When the DMA transfer is complete, the DATAXSFR signal is returned to logic zero.

When the DATAXSFR signal returns to logic 0, the generation of a start signal is triggered in the MEMFSM unit in state 1302. The start signal starts EVAL counter 1242, a programmable counter. The duration of the programmed count in the EVAL counter is equal to the duration of the evaluation cycle. While the EVAL counter is counting in state 1303, an EVAL signal indicates logic 1 and is provided to EVALFSMx in MEMFSM unit 1240 and the FPGA logic device. When the count is complete, the EVAL counter indicates that the EVAL signal is logic zero and sends it to EVALFSMx in the MEMFSM unit 1240 and the FPGA logic device. When MEMFSM unit 1240 receives a logic 0 EVAL signal, it turns on the EVAL_DONE flag in state 1304. The EVAL DONE flag is used by the MEMFSM to indicate that the evaluation cycle is complete and that the memory access cycle is in progress. The CPU checks EVAL_DONE and XSFR_DONE by reading the XSFR_EVAL register (see Table K below) to verify that the DMA transfer and EVAL completed successfully before the next DMA transfer.

However, in some cases, the simulation system may not want to perform the current memory access now. Here, the simulation system keeps the memory enable signal MEM_EN at logic zero. This disabled (logic 0) signal keeps the MEMFSM unit in idle state 1300, which waits for the MEMFSM unit to transfer DMA data and evaluate the data by the FPGA logic device. On the other hand, if the memory enable signal MEM_EN is logic 1, then the simulation system instructs to perform the desired memory access.

Under state 1304 in FIG. 58, the state diagram is subdivided into two sections running in parallel. One section includes states 1305, 1306, 1307, 1308, 1309 for low bank memory access. The other section includes states 1311, 1312, 1313, 1314, 1309 for high bank memory access.

In state 1305, the simulation system waits one cycle for the currently selected FPGA logic device to provide an address and control signal on the FPGA bus FD [31: 0]. In state 1306, the MEMFSM generates a latch signal on line 1263 and sends it to memory address / control latch 1243 to patch the input from FD [31: 0]. Data corresponding to this particular patched address and control signal is read from or written to the SRAM memory device. In order to determine whether the simulation system requires a read operation or a write operation, the memory write signal mem_wr_L for the low bank is extracted from the address and control signals. If mem_wr_L = 0, a read operation is requested. If mem_wr_L = 1, a write operation is requested. As described above, the mem_wr_L signal is equivalent to the chip select write signal.

In state 1307, an appropriate select signal for address / control mux 1244 is generated to transmit the address and control signal to the low bank SRAM. The MEMFSM unit checks the mem_wr signal and the LASTL signal. If mem_wr_L = 1 and LASTL = 0, a write operation is requested but the last data in the chain of FPGA logic devices is not yet shifted. Thus, the simulation system returns to state 1305, where the simulation system waits one cycle for the FPGA logic device to send more address and control signals on the FD [31: 0]. The process continues until the last data is shifted to the FPGA logic device. However, if mem_wr_L = 1 and LASTL = 1, the last data is shifted to the FPGA logic device.

Similarly, if mem_wr_L = 0 indicating a read operation, the MEMFSM proceeds to state 1308. In state 1308, the simulation system waits one cycle for the SRAM memory device to transfer data to the FPGA bus FD [31: 0]. If LASTL = 0, the last data in the chain of the FPGA logic device is not shifted yet. Thus, the simulation system returns to state 1305, where the simulation system waits one cycle for the FPGA logic device to send more address and control signals on the FD [31: 0]. The process continues until the last data is shifted to the FPGA logic device. The write operation (mem_wr_L = 1) and the read operation (mem_wr_L = 0) may be interleaved or otherwise repeated until LASTL = 1.

When LASTL = 1, MEMFSM proceeds to state 1309, where it waits until DONE = 0. If DONE = 1 and LASTL and LASTH are logic 1, the simulation write / read cycle is complete. The simulation system then proceeds to state 1300 where it waits for DATAXSFR = 0.

Similar processes can be applied for high banks. In state 1311, the simulation system waits one cycle for the currently selected FPGA logic device to send address and control signals on the FPGA bus FD [63:32]. In state 1312, MEMFSM generates a latch signal on line 1270 and sends it to memory address / control latch 1247 to patch the input from FD [63:32]. Data corresponding to this particular patched address and control signal is read from or written to the SRAM memory device. In order to determine whether the simulation system requires a read operation or a write operation, the memory write signal mem_wr_H for the high bank is extracted from the address and control signal. If mem_wr_H = 0, a read operation is requested. If mem_wr_H = 1, a write operation is requested.

In state 1313, an appropriate select signal for address / control mux 1246 is generated to transmit the address and control signal to the high bank SRAM. The MEMFSM unit checks the mem_wr signal and the LASTH signal. If mem_wr_H = 1 and LASTH = 0, a write operation is requested but the last data in the chain of FPGA logic devices is not yet shifted. Thus, the simulation system returns to state 1311, where the simulation system waits one cycle for the FPGA logic device to send more address and control signals on the FD [63:32]. The process continues until the last data is shifted to the FPGA logic device. However, if mem_wr_H = 1 and LASTH = 1, the last data is shifted to the FPGA logic device.

Similarly, if mem_wr_H = 0 indicating a read operation, the MEMFSM proceeds to state 1314. In state 1314, the simulation system waits one cycle for the SRAM memory device to transfer data to the FPGA bus FDs [63:32]. If LASTH = 0, the last data in the chain of the FPGA logic device is not shifted yet. Thus, the simulation system returns to state 1311, where the simulation system waits one cycle for the FPGA logic device to send more address and control signals on the FD [63:32]. The process continues until the last data is shifted to the FPGA logic device. The write operation mem_wr_H = 1 and the read operation mem_wr_H = 0 may be interleaved or alternately repeated until LASTL = 1.

When LASTH = 1, MEMFSM proceeds to state 1309, where it waits until DONE = 0. If DONE = 1 and LASTL and LASTH are logic 1, the simulation write / read cycle is complete. The simulation system then proceeds to state 1300 where it waits for DATAXSFR = 0.

Alternatively, high bank and low bank states 1309 and 1320 may be performed in accordance with another embodiment of the present invention. Thus, in the low bank, after passing through states 1308 (LASTL = 1) and 1307 (MEM_WR_L = 1 and LASTL = 1), the MEMFSM proceeds directly to state 1300. In the high bank, the MEMFSM proceeds directly to state 1300 after passing states 1313 (LASTH = 1) and 1313 (MEM_WR_H = 1 and LASTH = 1).

Hereinafter, a state diagram of the EVALFSM unit 1248 will be described according to an embodiment of the present invention. 59 shows a state diagram of the EVALFSMx finite state machine at each FPGA chip. Similar to FIG. 58, the state diagram of FIG. 59 is configured such that two periods in the simulation write / read cycle indicate their corresponding states. Thus, states 1320-1326A correspond to evaluation periods, and states 1326B-1336 correspond to memory access periods. See FIG. 57 in connection with FIG. 58 to be described below.

The EVALFSMx unit 1248 receives the EVAL signal on line 1274 from the CTRL_FPGA unit 1200 (see FIG. 57). When EVAL = 0, data evaluation by the FPGA logic device is not performed. Thus, in state 1320, EVALFSMx waits if EVAL = 0. When EVAL = 1, EVALFSMx proceeds to state 1321.

States 1321, 1322, and 1323 relate to inter-FPGA communication, where data is evaluated by a user design through an FPGA logic device. Here, EVALFSMx generates signals input_en, mux_en, clk_en (item 1281 of FIG. 57) and transmits them to the user's logic. In state 1321, EVALFSMx generates a clk_en signal that enables the second flip-flop of all clock edge register flip-flops in the user design logic in the cycle. Otherwise, the clk_en signal can be provided as software. If the user's memory type is synchronous, the clk_en signal may also enable the second clock of the memory read data double buffer 1251 in each memory block. The SRAM data output for each memory block is sent to user design logic in this cycle.

At state 1322, EVALFSMx generates an input_en signal for the user design logic to latch the input signal sent from the CPU to the user logic by the DMA transfer. The input_en signal provides an enable input to the second flip-flop (see FIG. 19) in the main clock register.

At state 1323, EVALFSMx generates a mux_en signal that turns on the multiplexing circuitry of each FPGA logic device to initiate communication with the FPGA logic device in the array. As noted above, inter-FPGA wire lines are sometimes multiplexed to effectively utilize limited pin resources within each FPGA logic device chip.

In state 1324, EVALFSM waits while EVAL = 1. When EVAL = 0, the evaluation cycle is complete, and state 1325 requests EVALFSMx to turn on mux_en signal.

If the number of memory blocks M (where M is an integer containing 0) is zero, EVALFSMx returns to state 1320 where it waits if EVAL = 0. In most cases, M> 0, EVALFSMx proceeds to state 1326A / 1326B. "M" is the number of memory blocks in the FPGA logic device. This is a constant from the user design that is mapped and implemented within the FPGA logic device. It does not count down. If M> 0, the right portion (memory access period) of FIG. 59 is implemented in the FPGA logic device. If M = 0, only the left part (EVAL period) of FIG. 59 is implemented.

State 1327 holds EVALFSMx on standby while SHIFTIN = 0. When SHIFTIN = 1, the previous FPGA logic device completes its memory access and the current FPGA logic device is ready to perform its memory access task. Alternatively, if SHIFTIN = 1, the current FPGA logic device is the first logic device in the bank and the SHIFTIN input line is connected to Vcc. Nevertheless, receipt of the SHIFTIN = 1 signal indicates that the current FPGA logic device is ready to perform a memory access. In state 1328, the memory block number N is set to N = 1. This number N is incremented with each loop, allowing memory accesses to specific memory blocks N to be performed. Initially, N = 1, EVALFSMx performs memory access to memory block 1.

In state 1329, EVALFSMx generates a select signal on line 1285 and an output_en signal on line 1284 to send the address and control signals of Mem_Block_N interface 1253 on the FPGA bus FD [63:32] or FD [31: 0]. Create and send to the FGPA bus driver FDO_MUXx 1249. If a write operation is requested, wr = 1. Otherwise, if read operation is requested, wr = 0. EVALFSMx receives one of its inputs, the wr signal on line 1287. Based on the wr signal, an appropriate selection signal is given on line 1285.

When wr = 1, EVALFSMx proceeds to state 1330. EVALFSMx generates select and output_en signals for the FD bus driver to provide the write data of Mem_Block_N 1253 on the FPGA bus FD [63:32] or FD [31: 0]. EVALFSMx then waits one cycle for the SRAM memory device to complete the write cycle. EVALFSMx then proceeds to state 1335, where the number N of memory blocks is increased by one. That is, N = N + 1.

However, if wr = 0, a read operation is requested and EVALFSMx proceeds to state 1332, where it waits for one cycle and proceeds to state 1333 to wait for another cycle. In state 1334, EVALFSMx generates an rd_latch signal on line 1286, causing memory read data double buffer 1251 of memory block N to patch the SRAM data onto the FD bus. EVALFSMx proceeds to state 1335, where memory block N is incremented by one. That is, N = N + 1. Thus, if N = 1 before increment state 1335, N will be 2, and a sequence memory access will be performed for memory block 2. FIG.

If the current number of memory blocks N is less than or equal to the total number of memory blocks M in the user design (i.e., N ≦ M), EVALFSMx proceeds to state 1329, based on whether the operation is a write operation or a read operation. Generate specific selection and output_en signals for the FD bus driver. Then, a write or read operation to the next memory block N is performed.

However, if the current number of memory blocks N is greater than the total number of memory blocks M in the user design (ie, N> M), EVALFSMx proceeds to state 1336, where the next FPGA logic device in the bank to access the SRAM memory device. Turn on the SHIFTOUT output signal to allow. EVALFSMx then proceeds to state 1320 where it waits until the simulation system requests data evaluation from the FPGA logic device (ie, EVAL = 1).

61 shows a simulation write / read cycle according to an embodiment of the present invention. FIG. 61 shows three cycles (DMA data transfer cycle, evaluation cycle, and memory access cycle) in the simulation write / read cycle at 1366. Although not shown. It is also implied that previous DMA transfers, evaluations, and memory accesses are also performed. Furthermore. The data transfer timing for the low bank SRAM will be different than the high bank SRAM. For simplicity, FIG. 61 illustrates one access time for an ideal low or high bank. The global clock GCLK 1350 provides a clocking signal for all components in the system.

DATAXSFR signal 1351 indicates the occurrence of a DMA data transfer period. When DATAXSFR = 1 in trace 1367, DMA data transfer is performed between the main computing system and the FPGA logic device or SRAM memory device. Thus, data is provided on FPGA high bank bus FD [63:32] 1359 and trace 1369 as well as on FPGA low bank bus FD [31: 0] 1358 and trace 1368. DONE signal 1364 transitions from logic signal 0 to 1 (e.g., trace 1390) to indicate completion of a memory access cycle, or else simulated recording with logic 0 (e.g., a combination of edge of trace 1370 and edge of trace 1390). Indicates the duration of the read cycle. During the DMA transfer period, the DONE signal is logic zero.

When the DMA transfer period is complete, the DATAXSFR signal transitions from logic 1 to logic 0, which triggers an onset of evaluation periods. Thus, EVAL 1352 is logic 1 as indicated by trace 1371. The duration of the EVAL signal in logic 1 can be predetermined and programmed. During this evaluation period, the data of the user design logic is clk_en signal 1353 (the signal is logic 1 as indicated by trace 1372), input_en signal 1354 (the signal is also logic 1 as indicated by trace 1373). ), And mux_en signal 1355 (the signal is also logic 1 and lasts longer than the clk_en and input_en signals, as indicated by trace 1374). Data is evaluated within this particular FPGA logic device. When the mux_en signal 1355 transitions from logic 1 to logic 0 at trace 1374 and at least one memory block is present in the FPGA logic device, the evaluation period is complete and the memory access period begins.

The SHIFTIN signal 1356 is given as logic 1 at trace 1375. This means that the previous FPGA has completed the evaluation and all desired data is accessed for this previous FPGA logic device. Now, the next FPGA logic device in the bank prepares for memory access.

In traces 1377-1386, they are named as follows. ACj_k means that the address and control signals are associated with FPGAj and memory block k. Here, j and k are integers containing 0. WDj_k means write data for FPGAj and memory block k. RDj_k means read data for FPGAj and memory block k. Thus, AC3_1 refers to the address and control signals associated with FPGA3 and memory block 1. Low bank SRAM access and high bank SRAM access 1361 are shown as trace 1387.

The following traces 1377-1387 illustrate how memory accesses are performed. A write or read operation is performed according to the logic level of the wrx signal for EVALFSMx and the logic level of the mem_wr signal for MEMFSM. If a write operation is desired, the memory model interfaces with the user memory block N interface (Mem_Block_N interface 1253 in FIG. 57) to provide wrx as one of the control signals. The control signal wrx is provided to the FD bus driver and the EVALFSMx unit. If wrx is logic 1, the appropriate select signal and output_en signal are provided to the FD bus driver to transfer memory write data on the FD bus. This same control signal now present on the FD bus can be latched by a memory address / control latch in the CTRL_FPGA unit. The memory address / control latch transfers the address and control signals to the SRAM via MA [18: 2]. Logic 1 wrx control signal is extracted from the FD bus, and since a write operation is requested, data associated with the address and control signal on the FD bus is transferred to the SRAM memory device.

Thus, as shown in FIG. 61, the next FPGA logic device (logic device FPGA0 in the low bank) sends AC0_0 on FD [31: 0] as indicated by trace 1377. The simulation system performs a write operation on WD0_0. AC0_1 is then transmitted on FD [31: 0]. However, if a read operation is requested, the presence of AC0_1 on FD bus FD [31: 0] will have some time delay before RD0_0 is present on the FD bus by the SRAM memory device instead of WD0_0 corresponding to AC0_0.

As indicated by trace 1383, the placement of AC0_0 on the MA [18: 2] / control bus is slightly delayed than the placement of address, control and data on the FD bus. This causes the MEMFSM unit to latch the address / control signal from the FD bus, extract the mem_wr signal, and generate an appropriate select signal to the address / control mux so that the address / control signal can be MA [18: 2] / control bus. This is because it requires time to be placed on the phase. In addition, after placing the address / control signal on the MA [18: 2] / control bus into the SRAM memory device, the simulation system must wait for corresponding data from the SRAM memory device to be placed on the FD bus. One example is the time offset between trace 1384 and trace 1381, where RD1_1 is placed on the FD bus after AC_1 is placed on the MA [18: 2] / control bus.

On the high bank, FPGA1 places AC1_0 on bus FD [63:32], followed by WD1_0. Thereafter, AC1_1 is disposed on bus FD [63:32]. This is indicated by trace 1380. When AC1_1 is placed on the FD bus, the control signal in this example indicates a read operation. Thus, as described above, when AC1_1 is placed on the MA [18: 2] / control bus as indicated by trace 1384, the appropriate wrx and mem_wr signals at logic 0 are addressed to the EVALFSMx and MEMFSM units / control signals. Is provided. Since the simulation system knows that this is a read operation, the write data will not be transferred to the SRAM memory device, but rather the read data associated with AC1_1 may not be sent to the SRAM for subsequent reading by the user design logic via the simulation memory block interface. Placed on the FD bus by the memory device. This is indicated by trace 1381 on the high bank. On the lower bank, it is placed on the FD bus as indicated by trace 1378 which is RD0_1, and then AC0_1 is placed on the MA [18: 2] / control bus (not shown).

Read operation by the user design logic via the simulation memory block interface is accomplished when EVALFSMx generates the rd_lat0 signal 1362 to the memory read data double buffer of the simulation memory block interface, as indicated by the trace 1388. This rd_lat0 signal is provided to both low bank FPGA0 and high bank FPGA1.

Thereafter, the next memory block for each FPGA logic device is placed on the FD bus. AC2_0 is placed on the low bank FD bus, while AC3_0 is placed on the high bank FD bus. If a write operation is required, WD2_0 is placed on the low bank FD bus and WD3_0 is placed on the high bank FD bus. AC3_0 is placed on the high bank MA [18: 2] / control bus as indicated by trace 1385. This process continues for the next memory block for write and read operations. Write and read operations for the low and high banks can occur at different times and speeds and FIG. 61 shows a particular example where the timing for the low and high banks is the same. Additionally, write operations for the low and high banks occur together, followed by read operations on both banks. This is not always the case. The presence of low banks and high banks enables parallel operation of the devices coupled to these banks. That is, activity on the low bank is independent of activity on the high bank. According to another scenario, the low bank performs a series of write operations in parallel when the high bank is performing a series of read operations.

Upon encountering the last data of the last FPGA logic device for each bank, the SHIFTOUT signal 1357 is assumed as indicated by trace 1376. For the read operation, it is assumed that the rd_lat signal 1363 corresponding to FPGA2 on the low bank and FPGA3 on the high bank read RD2_1 on trace 1379 and RD3_1 on trace 1382 as indicated by trace 1389. Since the last data for the last FPGA unit was accessed, the completion of the simulation write / read cycle is indicated by the DONE signal 1264 as indicated by trace 1390.

Table H, below, lists the various components on the simulation system board and their corresponding registers / memory, PCI memory addresses, and local addresses.

Table H: Memory Map

The data format for the configuration file is shown in Table J below in accordance with one embodiment of the present invention. The CPU sends one word through the PCI bus each time to set one bit in parallel for all on-board FPGAs.

Table J: Configuration Data Format

Table K below lists the XSFR_EVAL register. It resides on every board. The XSFR_EVAL register is used by the host computing system to program the EVAL period, control the DMA read / write, and read the status of the EVAL_DONE and XSFR_DONE fields. The host computing system also uses these registers to allow memory to access them. The operation of the simulation system associated with these registers is described below with respect to FIGS. 62 and 63.

Table K: XSFR_EVAL REGISTER for all six boards (local address: 0h)

Table L below lists the contents of the CONFIG_JTAG [6: 1] register. The CPU sets up the FPGA logic device and executes a boundary scan test of the FPGA logic device through these registers. Each board has one dedicated register.

Table L: CONFIG_JTAG [6: 1] REGISTER

62 and 63 show timing diagrams for another embodiment of the present invention. Figure 2 shows the operation of the simulation system with respect to the XSFR_EVAL register. The XSFR_EVAL register is used by the host computing system to program the EVAL period, control the DMA read / write, and read the status of the EVAL_DONE and XSFR_DONE fields. The host computing system also uses these registers to allow memory to access them. One of the main differences between the two figures is the state of the WAIT_EVAL field. In the case of Fig. 62, the WAIT_EVAL field is set to " 0 ", and the DMA read transfer starts after CLK_EN. In the case of FIG. 63, the WAIT_EVAL field is set to "1", and the DMA read transfer starts after EVAL_DONE.

In FIG. 62, both WR_XSFR_EN and RD_XSFR_EN are set to "1". These two fields enable DMA write / read transfers and may be cleared by XSFR_DONE. Since the two fields are set to "1", the CTRL_FPGA unit automatically executes the DMA write transfer first and then the DMA read transfer. However, the WAIT_EVAL field is set to " 0 " indicating that the DMA read transfer starts after the assertion of CLK_EN (and after completion of the DMA write operation). As such, in FIG. 62, the DMA read operation occurs almost immediately after completion of the DMA write operation as soon as the CLK_EN signal (software clock) is detected. The DMA read transfer operation does not wait for the completion of the EVAL period.

At the beginning of the timing diagram, the EVAL_REQ_N signal experiences competition when multiple FPGA logic devices compete for attention. As previously described, the EVAL_REQ_N (or EVAL_REQ #) signal is used to begin the evaluation cycle if any FPGA logic device assumes this signal. At the end of the data transfer, the evaluation cycle begins with the operation of the address pointer initialization and software clock to facilitate the evaluation process.

The DONE signal generated at the end of the DMA data transfer period also experiences competition when a number of LAST signals (which come from the shift-in and shift-out signals at the output of each FPGA logic device) are generated and provided to the CTRL_FPGA unit. When all LAST signals are received and processed, a DONE signal may be generated to begin a new DMA data transfer operation. The EVAL_REQ_N signal and the DONE signal use the same wire on a time-shared basis in the manner described below.

The system first starts a DMA write transfer as shown by the WR_XSFR signal at time 1409. The beginning of the WR_XSFR signal includes some overhead associated with the PCI controller (in one embodiment PCI 9080 or PCI 9060). The host computing system then performs a DMA write operation with the FPGA logic device coupled to the FPGA bus FD [63: 0] via the local bus LD [31: 0] and the FPGA bus FD [63: 0].

At time 1412, the WR_XSFR signal loses activity, indicating completion of the DMA write operation. The EVAL signal is activated for a predetermined time from time 1412 to time 1410. The duration of EVALTIME is programmable and is initially set to 8 + X, where X comes from the longest signal trace path. The XSFR_DONE signal is also activated for a short time to indicate the completion of this DMA transfer operation whose current operation is a DMA write.

Also, at time 1412, the competition between the EVAL_REQ_N signals is stopped and the wire carrying the DONE signal now passes the EVAL_REQ_N signal to the CTRL_FPGA unit. For three clock cycles, the EVAL_REQ_N signal is processed via the wire carrying the DONE signal. After three clock cycles, the EVAL_REQ_N signals are no longer generated by the FPGA logic device and the EVAL_REQ_N signal that was previously delivered to the CTRL_FPGA unit will be processed. The maximum time for which the EVAL_REQ_N signal is no longer generated by the FPGA logic device for the gated clock is approximately 23 clock cycles. EVAL_REQ_N signals longer than this period will be ignored.

At time 1413, i.e., approximately two clock cycles after time 1412 (at the end of the DMA write operation), the CTRL_FPGA unit performs a PCI write address strobe WPLX ADS_N signal to initiate a DMA read transfer. Send it to the controller. At a time after about 24 clock cycles from time 1413, the PCI controller will begin the DMA read transfer process and a DONE signal is also generated. At time 1414, prior to the start of the DMA read process by the PCI controller, the RD_XSFR signal is activated to enable DMA read transfer. First, some PLX overhead data is transmitted and processed. At time 1415, while this overhead data is being processed, DMA read data is placed on the FPGA bus FD [63: 0] and local bus LD [31: 0]. At the end of 24 clock cycles from time 1413 and at the time of activation of the DONE signal and generation of the EVAL_REQ_N signal from the FPGA logic devices, the PCI controller is deactivated from the FPGA bus FD [63: 0] and local bus LD [31: 0]. Process the DMA read data by transferring the data to the host computer system.

At time 1410, the DMA read data may continue to be processed, while the EVAL signal will lose activity and the EVAL DONE signal will be activated to indicate the completion of the EVAL cycle. Competition between FPGA logic devices also begins when they generate the EVAL_REQ_N signal.

At time 1417, just before the completion of the DMA read period at time 1416, the host computer system polls the PLX interrupt register to determine if the end of the DMA cycle is close. The PCI controller knows how many cycles are needed to complete the DMA data transfer process. After a predetermined number of cycles, the PCI controller will set a specific bit in the interrupt register. The CPU of the host computer polls these interrupt registers of the PCI controller. If the bit is set, the CPU knows that the DMA period is nearly performed. The CPU of the host system does not always poll the interrupt register because the interrupt register will interrupt the PCI bus in read cycles. Thus, in one embodiment of the present invention, the CPU of the host computer system is programmed to wait for a certain number of cycles before polling the interrupt register.

After a short time, the end of the DMA read period occurs at time 1416 when RD_XSFR becomes inactive and the DAM read data is no longer on FPGA bus FD [63: 0] or local bus LD [31: 0]. do. The XSFR_DONE signal is also activated at time 1416 and competition between LAST signals for the generation of the DONE signal begins.

During the entire DMA period from the generation of the WR_XSFR signal at time 1409 to time 1417, the CPU of the host computer system does not access the simulation hardware system. In one embodiment, the duration of this period is determined by (1) overhead time for PCI controller time 2, (2) number of words in WR_XSFR and RD_XSFR, and (3) host computer system (eg, Sun ULTRASpace). The sum of the PCI overhead. The first access after the DMA period occurs at time 1419 when the CPU polls the interrupt register of the PCI controller.

At time 1411, three clock cycles after time 1416, the MEM_EN signal is activated to enable the on-board SRAM memory device so that memory access between the FPGA logic device and the SRAM memory devices can begin. Memory access continues until time 1418, and in one embodiment requires 5 clock cycles per access. If no DMA read transfer is needed, then memory access can be started earlier at time 1410 instead of time 1411.

While memory access occurs between the FPGA logic device and the SRAM memory device across the FPGA bus FD [63: 0], the CPU of the host computer system is configured to local bus LD [31: 0] from time 1418 to time 1429. It can communicate with the PCI controller and the CTRL_FPGA unit via. This happens after the CPU has completed polling the interrupt registers of the PCI controller. The CPU writes data into several registers in preparation for the next data transfer. The duration of this period is greater than 4 ms. If the memory access is shorter than this period, the FPGA bus FD [63: 0] will not experience any collision. At time 1429, the XSFR_DONE signal loses activity.

In FIG. 63, the timing diagram is somewhat different from FIG. 62 in that the WAIT_EVAL field is set to "1". In other words, the DMA read transfer period starts after the EVAL_DONE signal is activated and almost complete. It waits near the completion of the EVAL period instead of starting immediately after completion of the DMA write operation. The EVAL signal is activated for a preset time from time 1412 to time 1410. At time 1410, the EVAL DONE signal is activated to indicate the completion of the EVAL period.

In FIG. 63, after a DMA write operation at time 1412, the CTRL_FPGA unit does not generate a write address strobe signal WPLX ADS_N to the PCI controller until time 1420, which time 1420 is about 16 of the end of the EVAL period. It is before the clock cycle. The XSFR_DONE signal also extends to time 1423. At time 1423, the XSFR_DONE field is set and then a WPLX ADS_N signal can be generated to begin the DMA read process.

At time 1420 before about 16 clock cycles of activation of the EVAL_DONE signal, the CTRL_FPGA unit sends a write address strobe WPLX ADS_N signal to a PCI controller (eg, PLX PC19080) to initiate a DMA read transfer. After about 24 clock cycles from time 1420, the PCI controller will begin a DMA read transfer and a DONE signal will also occur. At time 1421, prior to the start of the DMA read process by the PCI controller, the RD_XSFR signal is activated to enable DMA read transfer. Certain PLX overhead data is first delivered and processed. At time 1422, during the time such overhead data is processed, DMA read data is placed on FPGA bus FD [63: 0] and local bus LD [31: 0]. At the end of 24 clock cycles at time 1424, the PCI controller processes the DMA read data by transferring data from the FPGA bus FD [63: 0] and the local bus LD [31: 0] to the host computer system. The rest of the timing diagram is the same as in FIG. 62.

As such, the RD_XSFR signal of FIG. 63 is activated later than FIG. 62. The RD_XSFR signal in FIG. 63 is present after almost completion of the EVAL period, and delays the DMA read operation. The RD_XSFR signal in FIG. 62 is present after the detection of the CLK_EN signal after completion of the DMA write transfer.

IX. COVERIFICATION SYSTEM

The coverage system of the present invention can accelerate design / development by providing designers with the flexibility of software simulation and the faster speeds obtained by using hardware models. Both hardware part design and software design can be verified prior to ASIC fabrication and there are no limitations of emulator-based coverage tools. Debugging characteristics can be improved and overall debugging time can be significantly reduced.

Conventional coverage tool with ASIC as device-under-test

64 illustrates a typical final design implemented as a PCI add-on card, such as video, multimedia, Ethernet, or SCSI card. This card 2000 includes a direct interface connector 2002 that enables communication with other peripheral devices. Connector 2002 is coupled to bus 2001 for transmitting video signals from a VCR, camera, or television tuner, video and audio outputs to a monitor or speaker, and signals to a communications or disk drive interface. Depending on the user design, one skilled in the art can anticipate other interface requirements. The placenta of the design function resides on chip 2004 and the chip 2004 is connected to interface connector 2002 via bus 2003 and local oscillator 2005 via bus 2007 for generating a local clock signal. ) Is coupled to memory 2006 via bus 2008. Add-on card 2000 also includes a PCI connector 2009 for coupling with PCI bus 2010.

Prior to implementing the design as an add-on card as shown in FIG. 64, the design is reduced to ASIC form for testing purposes. A conventional hardware / software coverage tool is shown in FIG. 65. The user design is implemented in the form of an ASIC labeled with the device under test (or “DUT”) in FIG. 65. In order to obtain stimulus from various sources designed to interface, the device under test 2024 is placed in a target system 2020, which targets the central computing system 2021 on the motherboard and It is a combination of several peripherals. Target system 2020 includes a central computing system 2021 that includes a CPU and memory, and operates under a predetermined operating system such as Solaris of Microsoft Windows or Sun Microsystems for executing many applications. As is known in the art, Sun Microsystems' Solaris is a set of software products that are operating environments and support the Internet, intranets, and enterprise-wide computing. The Solaris operating environment is based on industry standard UNIX system distribution version 4, is designed for client-server applications in distributed networking environments, provides adequate resources for smaller workgroups, and is required for electronic commerce. To provide.

A device driver 2022 for the device under test 2024 is included in the central computing system 2021 to enable communication between the operating system (and any application) and the device under test 2024. As is known in the art, device drivers are specific software that controls hardware components or peripherals of a computer system. Device drivers include interrupt handlers to access the device's hardware registers and often to handle interrupts generated by the device. Device drivers often form part of the lowest level of the operating system kernel, and device drivers are linked with the kernel when the kernel is configured. More modern systems have loadable device drivers that can be installed from files after the operating system is executed.

The device under test 2024 and the central computing system 2021 are coupled to the PCI bus 2023. Other peripheral devices of the target system 2020 are connected via the bus 2036 and 2035, the Ethernet PCI add-on card 2025 and the bus 2036 and 2035 used to couple the target system to the network 2030 via the bus 2034. SCSI PCI add-on card 2026 coupled to drives 2027 and 2031, VCR 2028 coupled to device under test 2024 via bus 2032 (if required for design of device 2024 under test) ) And a monitor and / or speaker 2029 (if necessary for designing the device under test 2024) coupled to the device under test 2024 via the bus 2033. As is known in the art, "SCSI" stands for "Small Computer Systems Interface" and can be used for intelligent devices such as hard disks, floppy disks, CD-ROMs, printers, scanners and many other devices. processor independent standard for system-level interfacing between intelligent devices and computers.

In this target system environment, the device under test 2024 may be tested with various stimuli from a central computing system (ie, operating system, application) and peripherals. If time is not a consideration and designers are just looking for simple pass / fail testing, the coverage tool should be adequate to meet their needs. In most situations, however, design projects are subject to strict budget constraints and scheduled prior to product release. As mentioned earlier, this particular ASIC-based coverage tool is unsatisfactory because there are no debugging features (the designer cannot pinpoint the cause of a "failed" test without sophisticated techniques, and "corrects" all detected bugs). The number of countries cannot be predicted at the beginning of the project, and thus the schedule and budget cannot be predicted).

Conventional coverage tool with emulator as device under test

66 shows a conventional coverage tool with an emulator. Unlike the setup-up shown in FIG. 64 and described above, the device under test is programmed with an emulator 2048 coupled with the target system 2040 and certain peripheral and test workstations 2052. Emulator 2048 includes an emulation clock 2066 and a device under test programmed with the emulator.

Emulator 2048 is coupled to target system 2040 via PCI bus bridge 2044 and PCI bus 2057 and control line 2056. Target system 2040 includes a central computing system 2041 on the motherboard and a combination of several peripheral devices. Target system 2040 includes a central computing system 2041 that includes a CPU and memory, and operates under certain operating systems, such as Solaris of Microsoft Windows or Sun Microsystems, to execute multiple applications. The device driver 2042 of the device under test is included in the central computing system 2041 to enable communication between the operating system (and any application) and the device under test of the emulator 2048. As with other devices that are part of this computing environment, the central computing system 2041 is coupled with the PCI bus 2043 to communicate with the emulator 2048. Other peripheral devices of the target system 2040 are via an Ethernet PCI add-on card 2045 used to couple the target system to the network 2049 via the bus 2058, and via the buses 2060 and 2059. And a SCSI PCI add-on card 2046 coupled to SCSI drives 2047 and 2050.

Emulator 2048 is also coupled to the test workstation via bus 2062. Test workstation 2052 includes a CPU and a memory to perform its functions. Test workstation 2052 also includes data case 2061 and device model 2068 for other devices that are modeled but not physically coupled to emulator 2048.

Finally, emulator 2048 is coupled to other peripheral devices such as a frame buffer or data stream record / play system 2051 via bus 2061. This frame buffer or data stream record / play system 2051 may also connect to a communication device or channel 2053 via a bus 2063, to a VCR 2054 via a bus 2064, and to a bus 2065. Via a monitor and / or speaker 2055.

As is known in the art, the emulation clock runs at a much slower speed than the actual target system speed. Thus, the shaded portions of FIG. 66 operate at the emulation speed and the remaining shaded portions operate at the actual target system speed.

As mentioned above, such coverage tools with emulators have various constraints. When using a logic analyzer or sample-and-hold device to obtain the internal state information of the device under test, the designer compiles his design and consequently investigates the relevant signals of interest while investigating for debugging purposes. Is provided on the output pin for sampling. If the designer wants to debug a different part of the design, he must make sure that part has an output signal that can be sampled by a logic analyzer or sample-and-hold device, otherwise this signal is placed on the output pin for sampling purposes. It is necessary to recompile its design as it exists in emulator 2048 to be provided. This recompile time can take days or weeks, which can overdue the time-sensitive design / development schedule. In addition, since such coverage tools use signals, sophisticated circuitry must be provided to convert such signals into data or to provide some signal-to-signal timing control. In addition, the need to use multiple wires 2061 and 2062 for each signal required for sampling increases debug setup burden and time.

Simulation with Reconfigurable Computing Array

As a brief review, FIG. 67 illustrates a high level configuration of a single engine reconfigurable computing (RCC) array system of the present invention previously described herein. This single engine RCC system will be integrated into the coverage system according to one embodiment of the invention.

In FIG. 67, RCC array system 2080 includes an RCC computing system 2081, a relocatable computing (RCC) hardware array 2084, and a PCI bus 2089 that couples them together. Importantly, RCC computing system 2081 includes a full model of user design of software, and RCC hardware array 2084 includes a hardware model of user design. The RCC computing system 2081 includes the CPU, memory, operating system, and software necessary to run the single engine RCC system 2080. The software clock 2082 is provided to seamlessly control the software model of the RCC computing system 2081 and the hardware model of the RCC hardware array. Test bench data 2083 is also stored in the RCC computing system 2081.

The RCC hardware array system 2084 includes a PCI interface 2085, an RCC hardware array board set 2086, and various buses for interface purposes. The set of RCC hardware array boards 2086 includes at least a portion of a user design modeled in hardware (hardware model 2087) and memory for test bench data. In one embodiment, different parts of this hardware model are distributed among a plurality of relocatable logic elements during deployment time. As more relocatable logic elements are used, more boards may be required. In one embodiment, four relocatable logic elements are provided on one board. In another embodiment, eight relocatable logic elements are provided on one board. Repositionable logic elements on 4-chip boards may have significantly different capacities and capabilities than repositionable logic elements on 8-chip boards.

The bus 2090 provides various clocks for the hardware model from the PCI interface 2085 to the hardware model 2087. The bus 2091 provides other I / O data between the PCI interface 2085 and the hardware model 2087 via the connector 2093 and the internal bus 2094. The bus 2092 functions as a PCI bus between the PCI interface 2085 and the hardware model 2087. Test bench data may also be stored in the memory of hardware model 2087. The hardware model 2087 includes other structures and functions that are different from the user-designed hardware model required to enable the hardware model to interface with the RCC computing system 2081 as described above.

The RCC system 2080 may be provided as one workstation or alternatively may be coupled to a network of workstations where each workstation is provided to access the RCC system 2080 on a time sharing basis. In fact, the RCC array system 2080 functions as a simulation server with a simulation scheduler and a state swapping mechanism. The server allows each user at the workstation to access the RCC hardware array 2084 for high speed acceleration and hardware state swapping purposes. After acceleration and state swapping, each user can locally simulate the user design of the software while releasing control of the RCC hardware array 2084 to other users at different workstations. This network model will also be used in the cover repetition system described below.

The RCC array system 2080 can simulate the entire design to the designer and accelerate a portion of the test points during a selected cycle via a hardware model of the relocatable computing array and virtually internal to any portion of the design at any point in time. It provides the power and flexibility to obtain status information. Indeed, a single-engine relocatable computing array (RCC) system can be roughly described as a hardware-accelerated simulator, which includes the following tasks in a single debug session: (1) simulation, (2) user initiated, It can be used to perform simulations, (3) post-simulation analysis, and (4) in-circuit emulation with hardware accelerations that can examine the internal state of the design at any point in time, at hypothesis, and at any point in time. have. Since both software and hardware models are under tight control of a single engine via a software clock, the hardware model of the relocatable computing array is tightly coupled to the software simulation model. This allows designers to cycle-by-cycle debug and accelerate and decelerate hardware models through multiple cycles to gain valuable internal state information. Moreover, since these simulation systems handle data instead of signals, no complicated signal-to-data conversion / timing circuitry is required. In addition, the hardware model of the relocatable computing array does not need to be recompiled if the designer wants to examine a different set of nodes, unlike a typical emulation system. Please refer back to the above description for more details.

Coverage system without external I / O

One embodiment of the invention is a coverage system that uses no actual physical external I / O devices and target applications at all. Thus, the coverage system according to one embodiment of the present invention integrates the RCC system with other functions to debug the software and hardware portions of the user design without using any real target systems or I / O devices. Can be. Instead, the target system and external I / O devices are modeled in software of the RCC computing system.

Referring to FIG. 68, the coverage system 2100 includes an RCC computing system 2101, an RCC hardware array 2108, and a PCI bus 2114 that couples them together. Importantly, RCC computing system 2101 includes a full model of user design of software and relocatable computing array 2108 includes a hardware model of user design. The RCC computing system 2101 includes a CPU, memory, an operating system, and software necessary to run the single engine coverage system 2100. The software clock 2104 is provided to fully control the software model of the RCC computing system 2101 and the hardware model of the relocatable computing array 2108. Test case 2103 is also stored in RCC computing system 2101.

According to one embodiment of the invention, RCC computing system 2101 is also labeled 2106 with a target application 2102, a driver 2105 of a hardware model of a user design, a model of a device (e.g., a video card) and 2106. A driver of the model of software, and a model of another device (eg, a monitor) and also of the model of software labeled 2107. Essentially, the RCC computing system 2101 includes as many device models and drivers as necessary for the actual target system and other I / O devices to be delivered to the user-designed software and hardware models that are part of this computing environment.

RCC hardware array 2108 includes a PCI interface 2109, a set 2110 of RCC hardware array boards, and various buses for interface purposes. The set 2110 of RCC hardware array boards includes at least a portion of a user design modeled with hardware 2112 and memory 2113 for test vent data. As mentioned above, each board includes a plurality of relocatable logic elements or chips.

Bus 2115 provides various clocks for hardware models from PCI interface 2109 to hardware model 2112. Bus 2116 provides I / O data between PCI interface 2109 and hardware model 2112 via connector 2111 and internal bus 2118. The bus 2117 functions as a PCI bus between the PCI interface 2109 and the hardware model 2112. Test bench data may also be stored in the memory of hardware model 2113. As noted above, the hardware model includes other structures and functions that are different from the user-designed hardware model required to enable the hardware model to interface with the RCC computing system 2101.

In order to compare the coverage system of FIG. 68 with a conventional emulator-based coverage system, FIG. 66 illustrates a target system 2040, a predetermined I / O device (eg, a frame buffer or data stream record / play system). 2021), and an emulator 2048 coupled to the workstation 2052. This emulator configuration presents the designer with many problems and setup issues. The emulator requires a logic analyzer or sample-and-hold device to measure the internal state of the user design modeled by the emulator. Logic analyzers and sample-and-hold devices require signals, requiring complex signal-to-data conversion circuits. In addition, a complex signal to signal timing control circuit is also required. The number of wires required for all signals, which will be used to measure the internal state of the emulator, burdens the user during setup. During a debug session, the user must recompile the emulator each time he wants to examine a different set of internal logic circuits, so that the appropriate signal from the logic circuit is measured and measured by the logic analyzer or sample-and-hold device. It is provided as an output for recording. Long recompiles are very expensive.

In the coverage system of the present invention in which no external I / O devices are combined, the target system and other I / O devices are modeled in software so that no actual physical target system and I / O devices are physically needed. Since the RCC computing system 2101 processes the data, no complicated signal to data change circuit or signal to signal timing control circuit is needed. Also, the number of wires is not equal to the number of signals, so the setup is relatively simple. In addition, debugging different parts of the logic circuitry in the hardware model of the user design does not require recompilation because the coverage system only processes data and not signals. Since the RCC computing system controls the RCC hardware array with a software control clock (ie, software clock and clock edge detection circuit), starting and stopping the hardware model is facilitated. It is also easy to read data from the hardware model because a model of the entire user design is present in the software and the software clock allows synchronization. Thus, the user can debug by means of a single software simulation, accelerate all or part of the hardware, go through various desired test points every cycle, and internal state of the software and hardware model (e.g. , Registers, and coupling logic states) can be examined. For example, a user can simulate a design with some test bench data, then download internal state information to a hardware model, and use various test bench data with the hardware model to accelerate the design. And the resultant internal state values of the hardware model by register / join logic regeneration and the values loaded into the software model from the hardware model, and the user can finally use the results of the hardware model acceleration process to You can simulate the part.

However, as mentioned above, workstations are still needed for debug session control purposes. In a network configuration, the workstation can be remotely coupled with the coverage system to remotely access debug data. In a non-network configuration, the workstation may be locally coupled to the coverage system, or in some other embodiments, the workstation may internally couple the coverage system so that debug data may be locally accessed. Can be fresh.

Covertification System with External I / O

In FIG. 68, various I / O devices and target applications have been modeled with the RCC computing system 2101. However, if too many I / O devices and target applications are running in the RCC computing system 2101, the overall speed is slow. Using only one CPU of the RCC computing system 2101, more time is required to process the various data from all device models and target applications. To increase data throughput, real I / O devices and target applications (instead of software models of such I / O devices and target applications) may be physically coupled to the coverage system.

One embodiment of the present invention is a coverage system using actual and physical external I / O devices and target applications. Thus, the coverage system may incorporate other functionality into the RCC system to debug the software and hardware portions of the user design while using the actual target system and / or I / O devices. For testing, the coverage system may use both test bench data from software and stimuli from external interfaces (eg, target systems and external I / O devices). The test bench data can be used to provide test data to the pin-out of the user design, as well as to provide test data to internal nodes of the user design. The actual I / O signal from the external I / O device (or target system) can only be directed to the pin out of the user design. As such, one major difference between test data from external interfaces (e.g., target systems or external I / O devices) and test bench processes in software is that test bench data can be pinouted and applied to internal nodes. While it can be used to test a user design, the target system or external I / O device can only be applied to the user design via a pin out (or a node of the user design representing the pin out). In the following description, the structure of the coverage system and the placement of such coverage in relation to the target system and external I / O devices will be provided.

Compared to the system arrangement of FIG. 66, the coverage system according to one embodiment of the present invention replaces the structure and function of the items in dotted line 2070. In other words, FIG. 66 shows an emulator and workstation inside the border of dashed line 2070, while one embodiment of the present invention is a coverage system 2140 inside dashed line 2070 as shown in FIG. 69. Coverage system 2140 (and associated workstations).

Referring to FIG. 69, a coverage system configuration according to an embodiment of the present invention provides a target system 2120, a coverage system 2140, certain optional I / O devices, and controls for coupling them together. / Data buses 2131 and 2132. Target system 2120 includes a central computing system 2121, which includes a CPU and memory, and runs Microsoft Windows to run multiple applications 2122 and test cases 2123. Or run under certain operating systems such as Sun Microsystems' Solaris. Device drivers 2124 for hardware models of user designs are included in the central computing system to enable communication between the operating system (and any application) and the user designs. In order to communicate with other devices and coverage that are part of this computing environment, the central computing system 2121 is coupled to the PCI bus 2129. Other peripheral devices in the target system 2120 are Ethernet PCI add-on cards 2125 used to couple the target system to the network, SCSI PCI add-ons coupled to the SCSI drive 2128 via the bus 2130. On card 2126 and PCI bus bridge 2127.

The coverage system 2140 includes an RCC computing system 2141, an RCC hardware array 2190, an external interface 2139 in the form of an external I / O expander, and an RCC computing system 2141 and an RCC hardware array ( 2190 includes a PCI bus 2171 that couples together. The RCC computing system 2141 includes the CPU, memory, operating system, and software needed to run the single engine coverage system 2140. Importantly, RCC computing system 2141 includes a full model of user design of software and RCC hardware array 2190 includes a hardware model of user design.

As mentioned above, the single engine of the coverage system gains its power and flexibility from the main software kernel residing in the main memory of the RCC computing system 2141 and controls the overall operation and execution of the coverage system 2140. As long as any test bench process is active or any signal from the outside world is provided for coverage, the kernel evaluates the active test bench component, evaluates the clock component, registers, memory and propagates the combined logic data. The clock edge is detected and the simulation time is taken to update. This main software kernel provides for the tightly coupled nature of RCC computing system 2141 and RCC hardware array 2190.

The software kernel generates a software clock signal from the RCC hardware array 2190 and a software clock source 2142 provided to the outside world. The clock source 2142 can generate multiple clocks at different frequencies depending on the purpose of this software clock. In general, software clocks wrap registers present in the hardware model of the user's design in synchronous evaluation with the system clock without violating any hold-time. The software model can detect clock edges of software that affect the hardware model register values. Thus, the clock detection mechanism ensures that clock edge detection of the main software model can be translated to clock detection of the hardware model. See Figures 17-19 and accompanying text of this patent specification for more details on software clock and clock edge detection logic.

In accordance with one embodiment of the invention, RCC computing system 2141 may also include one or more models of multiple I / O devices, although other actual physical I / O devices may be coupled to the coverage system. Can be. For example, RCC computing system 2141 includes a model of a device (eg, a speaker) with a driver and test bench data of software labeled 2143, and test vent data of a driver and software labeled 2144. It may include a model of one another device (eg, a graphic accelerator). The user determines which devices (and their associated driver and test bench data) can be modeled and integrated into the RCC computing system 2141 and which devices will actually be combined with the coverage system.

The coverage system includes (1) between RCC computing system 2141 and RCC hardware array 2190, (2) between an external interface (coupled to the target system and external I / O devices) and RCC hardware array 2190. It includes control logic to provide traffic control. Certain data is transferred between the RCC hardware array 2190 and the RCC computing system 2141 because certain I / O devices can be modeled in an RCC computing system. In addition, the RCC computing system 2141 includes a model of the overall software design, including the user design portion modeled by the RCC hardware array 2190. As a result, the RCC computing system 2141 must also have access to all data passed between the external interface and the RCC hardware array 2190. Control logic ensures that RCC computing system 2141 has access to this data. Control logic will be described in more detail below.

The RCC hardware array 2190 includes a plurality of array boards. In this particular embodiment shown in FIG. 69, the hardware array 2190 includes boards 2145-2149. Boards 2146-2149 include most of the deployed hardware models. Board 2145 (or board m1) is a relocatable computing element (eg, FPGA chip) 2153 and an external interface (target system and I / O) that the coverage system can use to form at least part of a hardware model. O I) and an external I / O controller 2152 that sends traffic and data between the coverage system 2140. The board 2145 is via an external I / O controller to allow the RCC computing system 2141 to access all data transferred between the external world (ie, target system and I / O system) and the RCC hardware array 2190. To be able. This access is important because the RCC computing system 2141 of the coverage system includes a model of the entire user design in software and the RCC computing system 2141 can also control the functionality of the RCC hardware array 2190. Do.

If the stimulus from the external I / O device is provided to the hardware model, the software model should also have access to this stimulus as well, so that the user of the coverage system can optionally control the next debug step, The debug phase includes examining the value of the internal state of the design as a result of this applied addition. As described above in connection with the board layout and interconnect overview, the first and last boards are included in the hardware array 2190. Thus, board 1 (labeled as board 2146) and board 8 (labeled as board 2149) are included in an 8-board hardware array (excluding board m1). Unlike such boards 2145-2149, board m2 (not shown in FIG. 69, see FIG. 74) may also be provided with chip m2. This board m2 is similar to board m1 except that board m2 does not have any external interface and can be used for expansion purposes if additional boards are needed.

The contents of this board will be described below. Board 2145 (board m1) includes PCI controller 2151, external I / O controller 2152, data chip m1 2153, memory 2154, and multiplexer 2155. In one embodiment, this PCI controller is PLX 9080. The PCI controller 2151 is coupled to the RCC computing system 2141 via the bus 2171 and to the tri-state buffer 2179 via the bus 2172.

The primary traffic controller present in the coverage system between the external world (target system 2120 and I / O devices) and the RCC computing system 2141 is the external I / O controller 2152 (FIGS. 69, 71, and 73). (Also known as " CTRLXM "), the controller is coupled to the RCC computing system 2141, other boards 2146-2149 of the RCC hardware array, the target system 2120, and the actual external I / O device. Of course, the primary traffic controller between the RCC computing system 2141 and the RCC hardware array 2190 is always the individual internal I / O controllers (eg, I / O) of each array board 2146-2149 as described above. O controllers 2156 and 2158 and a combination of PCI controller 2151. In one embodiment, these individual internal I / O controllers, such as controllers 2156 and 2158, are shown in Figure 22 (unit 700) and in Figure 56. FPGA I / O controller described and illustrated in an example figure (unit 1200).

External I / O controller 2152 is coupled to tri-state buffer 2179 to enable the external I / O controller to interface with RCC computing system 2141. In one embodiment, the tri-state buffer 2179, in some examples, prevents data from the local bus from being passed to the RCC computing system 2141 while passing data from the RCC computing system 2141 to the local bus 2180. In another example, data may be transferred from the local bus 2180 to the RCC computing system 2141.

The external I / O controller 2152 is also connected to the chip m21 2153 and the memory / external buffer 2154 via the data bus 2176. In one embodiment, chip m1 2153 is a reconfigurable computing element such as an FPGA chip that can be used to construct at least a portion of a hardware model of a user design (or any hardware model if the user design is small enough). . External buffer 2154 is a DRAM DIMM in one embodiment and may be used by chip 2153 for various purposes. External buffer 2154 provides more memory capacity than each individual SRAM memory device locally coupled to a reconfigurable logic element (eg, reconfigurable logic element 2157. This large memory capacity allows RCC computing systems to test bench Allows storing large amounts of data such as data, implementation code for the microcontroller (if the user design is a microcontroller), and a large lookup table of one memory device.The external buffer 2154 also includes hardware, as described above. Essentially, this external buffer 2154 has more memory, but for example other high described and illustrated above in FIG. 56 (SRAM 1205, 1206). Or function similarly in part to a low bank SRAM memory device. The data may be used by a coverage system to store data received from the target system 2120 and external I / O devices such that the data may be retrieved by the RCC computing system 2141. Chip m1 2153 And external buffer 2154 also includes the memory mapping logic described herein under the section “Memory Simulation”.

To access the desired data in the external buffer 2154, the chip 2153 and the RCC computing system 2141 (via the external I / O controller 2152) may pass the address for the desired data. The chip 2153 provides an address on the address bus 2182 and an external I / O controller 2152 provides an address on the address bus 2177. These address buses 2182 and 2177 are inputs to the multiplexer 2155 providing a selected address on the output line 2178 coupled to the external buffer 2154. The select signal for the multiplexer 2155 is provided by an external I / O controller 2152 over line 2181.

External I / O controller 2152 is also connected to other boards 2146-2149 via bus 2180. In one embodiment, the bus 2180 is a local bus described and shown in the above exemplary diagrams of FIGS. 22 (local bus 708) and 56 (local bus 1210). In this embodiment, only five boards (including board 2145 (board m1)) are used. The actual number of boards is determined by the complexity and size of the user design to be modeled in hardware. The hardware complexity of the user design, which is the media complexity, requires less boards than the hardware model of the user design, which is of high complexity.

To enable scalability, the boards 2146-2149 are substantially identical to each other except for certain intra-board interconnect lines. This interconnect line is a portion of the hardware model of the user design in one chip (eg, chip 2157 of board 2146) and another chip (eg, chip 2161 of board 2148). To communicate with another part of the hardware model of the same user design physically located at For simplicity, reference is made to FIG. 74 for interconnect structures for such cover systems, as well as FIGS. 8 and 36-44 and drawings in the specification.

Board 2148 is a representative board. Board 2148 is the third board of this four-board layout (except board 2145 (board m1)). Thus, it is not an end-board that requires proper termination of the interconnect line. Board 2148 includes internal I / O controller 2158, various reconfigurable logic elements (e.g., FPGA chips) 2159-2166, high bank FD bus 2167, low bank FD bus 2168, high A bank memory 2169 and a row bank memory 2170. As described above, in one embodiment the internal I / O controller 2158 is the FPGA I described and shown above with exemplary views in FIGS. 22 (unit 700) and 56 (unit 1200). / O controller. Similarly, high and low bank memory devices 2169 and 2170 are, for example, SRAM memory devices described and shown above in FIG. 56 (SRAMs 1205 and 1206). In one embodiment, the high and low bank FD buses 2167 and 2168 are shown in Figure 22 (FPGA buses 718 and 719), Figure 56 (FD buses 1212 and 1213) and Figure 57 (FD buses 1282). The FD bus or FPGA bus described and illustrated in the exemplary figures in FIG.

In order to couple the cover system 2140 to the target system 2120 and other I / O devices, an external interface 2139 in the form of an external I / O expander is provided. On the target system side, an external I / O expander 2139 is connected to the PCI bridge 2127 via a secondary PCI bus 2132 and a control line 2131 that are used to carry a software clock. On the I / O device side, an external I / O expander 2139 is connected to various I / O devices via bus 2136-2138 for pin-out data and control lines 2133-2135 for the software clock. The number of I / O devices that can be coupled to I / O expander 2139 is determined by the user. In some cases, as many data buses and software clock control lines are provided to the external I / O expander 2139, it is necessary to connect to many I / O devices in the cover system 2140 to execute a successful debug session.

On the cover system 2140 side, an external I / O expander 2139 is connected to an external I / O controller through a data sub 2175, a software clock control line 2174, and a scan control line 2173. The data bus 2175 is used to transfer pin-out data between the external device (target system 2120 and external I / O device) and cover system 2140. Software clock control line 2174 is used to transfer software clock data from RCC computing system 2141 to an external device.

Software clocks present on control lines 2174 and 2131 are generated by the main software kernel of RCC computing system 2141. RCC computing system 2141 includes PCI bus 2171, PCI controller 2151, bus 2171, three-phase buffer 2179, local bus 2180, external I / O controller 2152, and control line 2174. Pass the software clock to the external I / O expander (2139). From the external I / O expander 2139, a software clock is provided as a clock input to the target system 2120 (via the PCI bridge 2127) and other external I / O devices via the control line 2133-2135. . Since the software clock serves as the main clock source, the target system 2120 and the I / O device run at a slower rate. However, data provided to the target system 2120 and external I / O devices are synchronized at the same software clock rate as the software model of the RCC computing system 2141 and the hardware model of the RCC hardware array 2190. Similarly, data from target system 2120 and external I / O devices are delivered to cover system 2140 synchronized with a software clock.

Thus, the I / O data transferred between the external interface and the cover system is synchronized with the software clock. In essence, the software clock synchronizes the operation of the external I / O device with the target system with the cover system (RCC system and RCC hardware array) each time data is transferred. The software clock is used for both data input and data output operations. For data entry operations, when the pointer (discussed later) latches the software clock from the RCC computing system 2141 to the external interface, another pointer is selected from the external interface in the hardware model of the RCC hardware array 2190. Will latch these I / O data inputs. In one unit, a pointer will latch the I / O data input during this cycle when a software clock is delivered to the external interface. Once all the data is latched, the RCC computing system can generate another software clock to relatch more data in other software clock cycles if desired. For data output operations, the RCC computing system may deliver a software clock to an external interface, and subsequently control data gating to the external interface with the aid of a pointer from an internal node of the hardware model of the RCC hardware array 2190. have. Again, as a unit, the pointer will gate the data from the internal node to the external interface. If more data needs to be transferred to the external interface, the RCC computing system can generate another software clock cycle and then output the data. Drive the selected pointer to gate to the external interface. The generation of the software clock is tightly controlled so that the cover system synchronizes the data transfer, and the data evaluation between the cover system and any external I / O device is connected to the external interface.

The scan control line 2173 is used to allow the cover system 2140 to scan the data buses 2132, 2136, 2137, 2138 for certain data that may be present. The logic of the external I / O controller 2151 that supports the scan signal is pointer logic in which multiple inputs are provided as outputs for a specific time period before moving to the next input via the MOVE signal. This logic is similar to the manner shown in FIG. Effectively, the scan signal functions similarly to the select signal for the multiplexer, except for selecting multiple inputs to the multiplexer in round robin order. Thus, in one time period, the scan signal on the scan control line 2173 samples the data bus 2132 for data that may occur from the target system 2120. In the next time period, the scan signal on the scan control line 2173 samples the data bus 2136 for data that may occur in an external I / O device that may be connected. In the next time period, data bus 2137 is sampled such that cover system 2140 can receive and process all pin-out data generated from target system 2120 or external I / O device during this debug session. . Certain data received by the cover system 2140 from the data buses 2132, 2136, 2137, and 2138 is transmitted to the external buffer 2154 through the external I / O controller 2152.

The configuration shown in FIG. 69 assumes that the target system 2120 includes a primary CPU and the user design is any peripheral device such as a video controller, network adapter, graphics adapter, mouse or any other supporting device, card or logic. do. Thus, target system 2120 includes a target application (including an operating system) coupled to primary PCI bus 2129, and cover system 2140 includes a user design and is coupled to secondary PCI bus 2132. The configuration may vary considerably depending on the conditions of the user design. For example, if the user design is a CPU, the target system 2120 will no longer include a central computing system 2121 while the target application will run on the RCC computing system 2141 of the cover system 2140. In addition, bus 2132 may be a primary PCI bus and bus 2129 may be a secondary PCI bus. Effectively, instead of the user design being one of the peripherals supporting the central computing system 2121, the user design is the main computing center and all other peripherals support the user design.

Control logic for transferring data between the external interface (external I / O expander 2139) and cover system 2140 is installed on each board 2145-2149. The primary portion of the control logic is formed in the external I / O controller 2152, while the other portion is comprised of several internal I / O controllers (eg, 2156, 2158) and reconfigurable logic elements (eg, FPGA chip 2159). , 2165). For educational purposes, it is necessary to show only a portion of this control logic instead of the same repeating logic structure for every chip on every board. The portion of cover system 2140 in dashed line 2150 of FIG. 69 includes one subset of control logic. Such control logic will be discussed in more detail with respect to FIGS. 70-73.

The elements of a particular subset of control logic are external I / O controller 2152, three-phase buffer 2179, internal I / O controller 2156 (CTRL 1), reconfigurable logic element 2157 (chip of board 1). Chip0_1 representing zero) and portions of various bus and control lines connected to the device. Specifically, FIG. 70 shows some of the control logic used during the data input cycle, with data from the external interface (external I / O expander 2139) and RCC computing system 2141 being RCC hardware array 2190. Is sent to. 72 shows a timing diagram of a data input cycle. 71 shows a portion of the control logic used in the data output cycle, with data from the RCC hardware array 2190 being sent to the RCC computing system 2141 and an external interface (external I / O expander 2139). 73 shows a timing diagram of a data output cycle.

Data entry

Data input control logic in accordance with one embodiment of the present invention is responsible for processing data transmitted from an RCC computing system or an external interface to an RCC hardware array. One particular subset 2150 of data input control logic (see FIG. 69) is shown in FIG. 70 and includes an external I / O controller 2200, a three phase buffer 2202, an internal I / O controller 2203, and a reconfiguration. Possible logic elements 2204 and various bus and control lines to allow data transfer. An external buffer 2201 is also shown for this data input embodiment. This subset shows the logic required for the data input operation, with data from the external interface and the RCC computing system being sent to the RCC hardware array. The data input control logic of FIG. 70 and the data input timing diagram of FIG. 72 will be discussed together.

Two types of data cycles are used in this data input embodiment of the present invention (global cycle and software-to-hardware (S2H) cycle). Global cycles are used for certain data delivered to all chips in the RCC hardware array, such as some other S2H data, clocks, and resets that are delivered at different nodes of the RCC hardware array. For this subsequent "global" S2H data, it is more feasible to send this data output through a global cycle rather than sequential S2H data.

The software-to-hardware cycle is used to transfer data from one chip to another chip on all boards sequentially from the test bench process of the RCC computing system to the RCC hardware array. Because the hardware model of your design is distributed across multiple boards, test bench data must be provided on every chip for data evaluation. Thus, data is sequentially transmitted to one internal node at a time, to each internal node of each chip. Sequential transmission allows the specific data pointed out for a particular internal node to be processed by all the chips in the RCC hardware array because the hardware model is distributed among multiple chips.

For this data evaluation, the covering provides two address spaces S2H and CLK. As described above, S2H and CLK space are the primary inputs from the kernel to the hardware model. The hardware model maintains all the register elements and coupling elements of the user circuit design. In addition, the software clock is modeled in software and provided in the CLK I / O address space to interface with the hardware model. The kernel increases simulation time, searches for active test bench devices, and evaluates clock devices. If a certain clock edge is detected by the kernel, the registers and memory are updated and the values propagated through the coupling element. Thus, the change in the value of this space will trigger the hardware model to change the logic state once the hardware acceleration mode is selected.

During data transfer, the DATA_XSFR signal is at logic "1". During this time, the local buses 2222-2230 may include: (1) global data from the RCC computing system to the RCC hardware array and CLK space; (2) global data from the external interface to the RCC hardware array and external buffer; And (3) a cover system to transfer data in a data cycle, such as S2H data from the RCC computing system to the RCC hardware array, one chip at a time on each board. Thus, the first two data cycles are part of the global cycle and the final data cycle is part of the S2H cycle.

For the first part of the data input global cycle when global data from the RCC computing system is sent to the RCC hardware array, the external I / O controller 2200 reads the CPU_IN signal on logic line 2255 as logic " 1 ". Enable it. Line 2255 is connected to the enable input of three-phase buffer 2202. With logic "1" on line 2255, three-phase buffer 2202 allows data on local bus 2222 to transfer to local bus 2223-2230 on the other side of three-phase buffer 2202. In this particular example, local buses 2223, 2224, 2225, 2226, 2227, 2228, 2229, 2230 are LD3, LD4 (from external I / O controller 2200), and LD6 (external I / O controller 22O0, respectively). ), LD1, LD6, LD4, LD5, and LD7.

Global data proceeds from this local bus line to the bus lines 2231-2235 of the internal I / O controller 2203 and then to the FD bus lines 2236-2240. In this example, the FD bus lines 2236, 2237, 2238, 2239, and 2240 correspond to the FD bus lines FD1, FD6, FD4, FD5, and FD7, respectively.

These FD bus lines 2236-2240 are connected to the inputs to the latches 2208-2213 of the reconfigurable logic element 2204. In this example, the reconfigurable logic element corresponds to chip0_1 (ie chip 0 of board 1). FD bus line 2236 is also connected to latch 2208, and FD bus line 2237 is connected to latches 2209 and 2211. FD bus line 2238 is connected to latch 2210, FD bus line 2239 is connected to latch 2212, and FD bus line 2240 is connected to latch 2213.

The enable input for each of these latches 2208-2213 is coupled to several global pointers and software-to-hardware (S2H) pointers. The enable input for latch 2208-2211 is connected to the global pointer and the enable input for latch 2212-2213 is connected to the S2H pointer. Some exemplary global pointers include GLB_PTR0 on line 2241, GLB_PTR1 on line 2242, GLB_PTR2 on line 2243 and GLB_PTR3 on line 2244. Some exemplary S2H pointers include S2H_PTR0 on line 2245 and S2H_PTR1 on line 2246. Because the enable input for this latch is connected to this pointer, each latch cannot latch data in the designated destination mode of the hardware model of the user's design without an appropriate pointer signal.

These global and S2H pointer signals are generated by data input pointer state machine 2214 on output 2254. Data input pointer state machine 2214 is controlled by DATA_XSFR and F_WR on line 2253. Internal I / O controller 2203 generates DATA_XSFR and F_WR on line 2253. DATA_XSFR is in a logic "1" state whenever a data transfer is desired between the RCC hardware array and the RCC computing system or external interface. In contrast to the F_RD signal, the F_WR signal is in logic " 1 " whenever a write to the RCC hardware array is desired. Reading through the F_RD signal requires data transfer from the RCC hardware array to one of the RCC computing system and external interface. If both the DATA_XSFR and F_WR signals are in logic "1", the data input pointer state machine can generate the appropriate global or S2H pointer signal in the appropriate programmed sequence.

The outputs of these latches 2247-2252 are connected to various internal nodes of the hardware model of the user design. Some of the internal nodes correspond to the input pin-outs of your design. User designs generally have other internal nodes that cannot be accessed through pin-out, but these non-pin-out internal nodes stimulate multiple internal nodes in the user design whether or not they are input pin-outs. It is for other debugging purposes to provide flexibility for designers who want it. For the stimulus to provide an external interface to the high hardware model of the user design, this internal node corresponding to data-in logic and input-pin-out is performed. For example, if the user design is a CRTC 6845 video controller, some input pin-outs are as follows:

LPSTPB-Light Pen Strobe Pins

~ RESET-low level signal for resetting the 6846 controller

RS-Register Selection

E-Enable

CLK-Clock

~ CS-Chip Selection

Other input pin-outs can also be used in these video controllers. Based on the number of input pin-outs that interface with the outside world, the number of latches and pointers can be quickly determined. Some hardware models configured within the RCC hardware array have 30 separate latches associated with each of GLB_PTR0, GLB_PTR1, GLB_PTR2, GLB_PTR3, S2H_PTRO and S2H_PTR1, for a total of 180 latches (= 30x6), for example. In other designs, more global pointers such as GLB_PTR4 to GLB_PTR30 may be used as needed. Similarly, more S2H such as S2H_PTR2 to S2H_PTR30 can be used as needed. These pointers and their corresponding latches are based on the requirements for the hardware model of each user design.

70 and 72, the data on the FD bus line builds itself on these internal nodes as long as the latch is enabled with the appropriate global pointer or S2H pointer signal. Otherwise, these internal nodes are not driven by any data on the FD bus. When F_WR is the first half-cycle design logic "1" of CPU_IN = 1 time period, GLB_PTR0 becomes logic "1" to drive data on FD1 to its internal node via line 2247. If there are other latches that depend on GLB_PTR0 for enabling, these latches will latch their data to that internal node. CPU_IN = 1 time note In the next half cycle, F_WR triggers GLB_PTR1 to be incremented to logic "1" and goes to logic "1". This drives data on FD6 to an internal node connected to line 2248. It also sends a software signal on line 2223 to be latched on line 2216 by latch 2205 and transmits a GLB_PTR1 signal on enable line 2215. The software clock is passed to the peripheral clock input, target system, and other external I / O devices. Since GLB_PTR0 and GLB_PTR1 are used only as the first part of the data-in global cycle, CPU_IN returns to logic "0", which completes the transfer of global data from the RCC computing system to the RCC hardware array.

The second part of the data-in global cycle will be described where global data from the external interface is passed to the RCC hardware array and external buffer. Again, several input pin-out signals from the target system or external I / O devices that are directed to the user's design must be provided to the hardware model and the software model. This data is passed to the hardware model by using the appropriate pointers and latched to drive internal nodes. Such data can be passed to the software model by first storing them in an external buffer 2201 for later retrieval by the RCC associative system to update the internal state of the software model.

CPU_IN is logic "0" and EXT_IN is logic "1". Thus, the tri-state buffer 2206 in the external I / O controller 2200 is enabled to load data onto the PCI bus lines as bus lines 2217 and 2218. This PCI bus line is also connected to FD bus line 2219 for storage in external buffer 2201. In the first half period of the time period when the EXT_IN signal is logic "1", GLB_PTR2 is logic "1". This latches the data on FD4 to latch internal nodes in the hardware model connected to line 2249 (via bus lines 2217, 2224 and local bus line 2228 (LD4)).

For the next half period of the time period when the EXT_IN signal is logic "1", GLB_PTR3 is logic "1". This latches the data on FD5 to latch internal nodes in the hardware model connected to line 2250 (via bus lines 2218, 2225 and local bus line 2227 (LD6)).

As described above, such data from a target system or some other external I / O device may be stored first in an external buffer 2201 for later retrieval by the RCC computing system to update the internal state of the software model. Can be delivered. This data on bus lines 2217 and 2218 is provided to FD bus FD [63: 0] for external buffer 2201. The specific memory address where each data is stored in external buffer 2201 is provided by memory address counter 2201 via bus 2220 to external buffer 2201. To enable such storage, a WR_EXT_BUF signal is provided to the external buffer 2201 via line 2221. Before the external buffer 2201 is filled, the RCC computational system will read the contents of the external buffer 2201 so that an appropriate update can be made to the software model. Any data passed to various internal nodes of the hardware model in the RCC hardware array will cause some internal state change in the hardware model. Since the RCC computing system has a model of the overall user design in software, this internal state change in the hardware model must be reflected in the software model. This concludes the data-in global cycle.

The S2H cycle will be described below. S2H cycles are used to transfer test bench data from the RCC computing system to the RCC hardware array, and then sequentially move data from one chip to the next for each board. While the CPU-IN signal is a logic "1", the EXT_IN signal goes to a logic "0" indicating that data transfer is between the RCC computing system and the RCC hardware array. The external interface is not relevant. The CPU_IN signal also enables three-phase buffer 2202 to allow data to be passed from the local bus 2222 to the inner I / O controller 2203.

At the start of CPU_IN = 1 time period, S2H_PTR0 latches data on FD5 (via local bus 2222, local bus line 2229, bus line 2234, and FD bus 2239) to be latched to an internal node in the hardware model connected to line 2251. Go to logic "0". In the first part of the CPU_IN = 1 time period, S2H_PTR1 sends data on FD7 (via local bus 2222, local bus line 2230, bus line 2235 and FD bus 2240) to be latched to an internal node in the hardware model connected to line 2252. Go to the logic "1" to latch. During sequential data evaluation, the data from the RCC computing system is transferred first to chip m1 and then to chip 0_1 (i.e. chip 0 on board 1), chip 1) 1 (i.e. chip 1 on board 1). The chip is then transferred to the last chip on the last board, chip 7_8 (ie chip 7 on board 8). If chip m2 is available, data can be moved to this chip.

At the end of the data transfer, DATA_XSFR returns to logic "0". I / O data from the external interface is considered global data and processed during the global cycle. This concludes the result of the data-in control logic and data-in cycle.

Data-out

A data-out control logic embodiment of the present invention is described below. Data-out control logic in accordance with an embodiment of the present invention is responsible for processing data transferred from the RCC hardware array to the CC computing system and the external interface. During the processing of the data in response to a stimulus (external or otherwise), the hardware model generates specific output data for which the target application or some I / O device is used. Such output data may be independent data, addresses, control information or other relevant information that other applications or devices need for their processing. This output data for the RCC computing system (with a model of other external I / O devices in software), targets, systems or external I / O devices are provided to several internal nodes. As described above for the data-in logic, some of these internal nodes correspond to the output pin-out of the user design. User designs have other internal nodes that are not normally accessed through pin-out, but these non-pin-out internal nodes read stimulus responses from multiple internal nodes in the user design, whether they are output pin-out or not. It is for other debugging purposes that will give flexibility to the designer who wants to analyze it. From the high hardware model of the user's design to the stimulus provided to the RCC computational system (with a model of another I / O device in software) or to an external interface, this internal node corresponding to the data-out logic and output pin-out is performed. do.

For example, if your design is a CRTC 6845 video controller, some output pin-outs are:

MA0-MA13-memory address

D0-D7-data bus

DE-display enable

CURSOR-Cursor Position

VS-Vertical Sync

HS-Horizontal Sync

Other output pin-outs can be used with these video controllers. Based on the number of output pin-outs that interface with the outside world, the number of nodes and thus the number of gating logic and pointers can be quickly determined. Thus, the output pin-out MA0-MA13 on the video controller provides the memory address for the video RAM. The VS output pin-out provides a signal for vertical synchronization, thus causing a vertical retrace on the monitor. Output pin-outs D0-D7 are eight terminals that form a bidirectional data bus for accessing internal 6945 registers by the CPU in the target system. This output pin-out corresponds to a specific inner node in the hardware model. Of course, the number and characteristics of these internal nodes vary depending on the user design.

Since the RCC computational system contains a model of the entire user design in software, these output pin-out internal nodes must be provided to the RCC computational system, so that any changes that occur within the software model and the software model can be made. Communicate In this way, the software model will have information that matches the hardware model. In addition, the RCC computing system has a device model of an I / O device that is a user or designer dedicated to the model in software, except that the actual device is connected to one of the ports on the external I / O extension. For example, the user determines whether it is easier and more efficient to model a monitor or speaker in software except by plugging the actual monitor or speaker into the external I / O expander port. Moreover, data from these internal nodes in the hardware model must be provided to the target system and other external I / O devices. In order for these output pin-out internal nodes to be communicated to RCC computational systems and target I / O devices other than the target system, data-out control logic in accordance with one embodiment of the present invention is provided within the co-authentication system.

The data-out control logic uses a data-out cycle that includes data transfer from RCC hardware 2190 to RCC computing system 2141 and an external interface (external I / O expander 2139). In FIG. 69, control logic for data transfer between the external interface (external I / O expander 2139) and co-authorization 2140 is shown on each board 2145-2149. While the main part of the control logic is shown in the external I / O controller 2152, the other part is shown in several internal I / O controllers (e.g. 2156 and 2158) and reconfigurable control elements (e.g. FPGA chips 2159 and 2165). . Again, for mechanical purposes, it is only necessary to show some of this control logic instead of the same repeating logic structure for every chip in every board. Co-authentication system portion 2140 in thick line 2150 of FIG. 69 includes a subset of control logic. This control logic will be described generally with respect to FIGS. 71 and 73. 71 shows the control logic used in the data-out cycle. 73 shows a timing diagram of a data-out cycle.

A particular subset of the data-out control logic is shown in FIG. 71 and includes an external I / O controller 2300, a three phase buffer 2301, an internal I / O controller 2302, a reconfigurable logic element 2303 and several buses and control lines. It allows data transfer between them. This subset illustrates the logic required for the data-out operation in which data from the external interface and the RCC computing system is passed to the RCC hardware array. The data-out control logic of FIG. 71 and the data-out timing diagram of FIG. 73 will be described together.

Compared to two types of data-out cycles, the data-out cycle includes only one type of cycle. Data from the RCC hardware model needs to be passed sequentially to (1) the RCC computing system and (2) to the RCC computing system and external interfaces (target system and external I / O device). In particular, the data-out cycle ensures that data from an internal node of a hardware model in an RCC hardware array is delivered first to the RCC computing system and then one chip at a time within each board to the RCC computing system and an external interface within each chip. And to be passed on to one board next.

Like data-out control logic, a pointer will be used to select (or gate) data from an internal node to the RCC computing system and an external interface. In the embodiment shown in FIGS. 71 and 73, the data-out pointer state machine 2319 generates five pointers H2S_PTR [4: 0] on the bus 2359 for both hardware-hardware data and hardware-external interface data. The data-out pointer state machine 2319 generates the DATA_XSFR and F_RF signals on line 2358. DATA_XSFR is always a logic "1" whenever data transfer between the RCC hardware array and the RCC computing system or external interface is required. The F_RD signal is a logic "1" every time a read from the RCC hardware array is required, compared to the F_WR signal. If DATA_XSFR and F_RD are logical " 1 ", then the data-out pointer state machine 2319 can generate the appropriate H2S pointer signal in the appropriate programmed sequence. Other embodiments may use more pointers (or fewer pointers) needed for user design.

This H2S pointer signal is provided to the gating logic. Input sets 2353-2357 to the gating logic are directed to several AND gates 2314-2318. The other input sets 2348-2352 are connected to internal nodes of the hardware model. Thus, AND gate 2314 has an input 2348 from an internal node and an input 2357 from H2S_PTR0; AND gate 2315 has an input 2349 from an internal node and an input 2354 from H2S_PTR1; AND gate 2316 has input 2350 from internal node and input 2355 from H2S_PTR2; AND gate 2317 has an input 2351 from an internal node and an input 2356 from H2S_PTR3; AND gate 2318 has an input 2352 from an internal node and an input 2357 from H2S_PTR3. Without the proper H2S_PTR pointer signal, the inner node cannot be driven from either the RCC computing system or the external interface.

Individual outputs 2343-2347 of the AND gates 2314-2318 are coupled to OR gates 2310-2313. Thus, AND gate output 2343 is coupled to the input of OR gate 2310; AND gate output 2344 is coupled to the input of OR gate 2311; AND gate output 2345 is coupled to the input of OR gate 2312; AND gate output 2346 is coupled to the input of OR gate 2313. It is noted that output 2344 of AND gate 2315 is not coupled at unassigned OR gate, but output 2344 is coupled to OR gate 2311 coupled to output 2345 of AND gate 2316. . The other inputs 2236-2366 to the OR gates 2310-2313 are coupled to the output of another AND gate (not shown) which is itself coupled to another internal node and the H2S_PTR pointer. The use of the OR gates and their specific inputs is based on user designed and configured hardware models. Thus, in other designs, more pointers and outputs 2344 from AND gate 2315 that can be used are coupled to different OR gates rather than OR gate 2311.

Outputs 2339-2342 of OR gates 2310-2313 are coupled to FD bus lines FD0, FD3, FD1, and FD4. In a particular example of a user design, only four output pinout signals will be delivered at the RCC computing system and external interface. Thus, FD0 is coupled to the output of the OR gate 2310; FD3 is coupled to the output of OR gate 2311; FD1 is coupled to the output of OR gate 2312; FD4 is coupled to the output of the OR gate 2313. The FD bus line is coupled to a local bus line 2330-2333 through an internal line 2334-2338 of an internal I / O controller 2302. In this embodiment, local bus line 2330 is LD0, local busline 2331 is LD3, local busline 2332 is LD1, and local busline 2333 is LD4.

The local busline is coupled to the tri-state buffer 2301 to allow data from the local buslines 2330-2333 to be delivered to the RCC computing system. In the normal state, the tri-state buffer 2301 allows data to pass from the local busline 2330-2333 to the local bus 2320. In contrast, during data-in, data is allowed to pass through the RCC hardware array from the RCC computing system only when the CPU_IN signal is provided to the tri-state buffer 2301.

Lines 2321-2324 are provided to allow data from the local buslines 2330-2333 to be delivered to an external interface. Line 2321 is coupled to any latch (not shown) in line 2330 and external I / O controller 2300; Line 2232 is coupled to any latch (not shown) in line 2331 and external I / O controller 2300; Line 2323 is coupled to latch 2305 at line 2332 and external I / O controller 2300; Line 2324 is coupled to latch 2306 at line 2333 and external I / O controller 2300.

Each input of the latches 2305 and 2306 is coupled to an external interface that is coupled to an appropriate output pin-out or external I / O of the buffer and target system. Thus, the output of latch 2305 is coupled to buffer 2307 and line 2327. In addition, the output of latch 2306 is coupled to buffer 2308 and line 2328. Another output of another latch (not shown) may be coupled to line 2329. In the above example, lines 2327-2329 match wire 1, wire 4, and wire 3, respectively, of the target system or any external I / O device. Finally, while transferring data from the hardware model to the external interface, the hardware model of the user design has an internal node connected to the line 2350 corresponding to the wire 3 on the line 2329 and the line ( An internal node connected to 2351 corresponds to a wire 1 on line 2327 and an internal node connected to line 2352 is configured to correspond to a wire 4 on ain 2328. Similarly, streamline 3 corresponds to KD3 on line 2331, streamline 1 corresponds to LD1 on line 2332, and streamline 4 corresponds to LD4 on line 2333.

Lookup table 2309 is connected to inputs to these latches 2305 and 2306. The lookup table 2309 is controlled by the F_RD signal on line 2367 which triggers the operation of lookup table address counter 2304. As each counter increments, the pointer enables a particular column of lookup table 2309. If the entry (or bit) in the particular column is logic " 1 ", then the LUT output line connected to the particular entry in the lookup table 2309 enables its corresponding latch and enables the data to occur. It is driven by an external interface and finally driven to the desired point of the target system or a constant external I / O device. For example, LUT output line 2325 is connected to an enable input to latch 2305 and LUT output line 2326 is connected to an enable input to latch 2306.

In the above example, columns 0-3 of lookup table 2309 are programmed for enabling latches corresponding to the output pin-out wires for the inner node of chip m1. Similarly, columns 4-6 are programmed for enabling latches corresponding to the output pin-out wires for the internal node of chip 0_1 (ie, chip 0 of board 1). In column 4, the bit 3 is logic "1". In column 5, bit 1 is logic " 1. " In column 6, bit 4 is logic " 1 ". All other entries and bit positions are logic "0". For any given bit position in the lookup table, only one entry is logic "1" because a single output pin-out wireline cannot drive multiple I / O devices. In other words, in the hardware model, the output pin-out internal node provides data only to a single wire connected to the external interface.

As mentioned above, the data-out control logic is such that data of each configurable logic component of each chip in the RCC hardware model is sequentially (1) the RCC computing system and (2) the RCC computing system. And to be delivered together to the external interface (the target system and the external I / O device). The RCC computing system requires the data because it has a model of a certain I / O device in software, and for the data that is not directed to one of the modeled I / O devices, the RCC computing system has an internal state of its own. It is necessary to monitor them in order to correspond to that of the hardware model of the RCC hardware array. In the example described in Figures 71 and 73, only seven internal nodes will be driven with output to the RCC computing system and an external interface. Two of the internal nodes are on chip m1 and the other five internal nodes are on chip 0_1 (ie chip 0 of board 1). Of course, other internal nodes and chips among them may be required to understand the specific user design, but Figures 71 and 73 illustrate only seven nodes.

During data transmission, the DATA_XEFR signal is logic "1". During this time, the local buses 2330-2333 will be used in a conventional system to sequentially transmit data from each chip of each board in the RCC hardware array to the RCC computing system and the external interface. The DATA_XSFR and F_RD signals control the operation of the data output pointer state machine to generate the appropriate pointer signal H2S_PTR [4: 0] to the appropriate gate that is directed to the output pin-out internal load. The F_RD signal also controls the lookup table address counter 2304 to send internal node data to the external interface.

The internal node on chip m1 is adjusted for the first time. If F_RC is generated with logic "1" in the data transfer cycle, H2S_PTR0 in chip m1 goes to logic "1". This drives data in the internal node of chip m1 based on H2S_PTR0 to the RCC computing system via tri-state buffer 23010 and local bus 2320. Look-up table address counter 2304 is counted and lookup Pointing to row 0 of table 2309 is latched from the appropriate data of chip m1 to the external interface. When the F_RD signal returns to logic " 1 ", the data at internal nodes that can be driven by H2S_PTR1 is Is passed to the RCC calculation system and internal interface H2S_PTR1 proceeds to logic " 1 " and in response to the second F_RD signal, lookup table address counter 2304 counts and indicates row 1 of lookup table 2309; Is latched into the external interface at the appropriate data of chip m1.

Reconstruction logic element 2303 (ie, chip 0_1, or chip 0 on board 1) will now be processed. In this example, two internal nodes associated with H2S_PTR0 and H2S_PTR2 will only be passed to the RCC calculation system. Data from three internal nodes associated with H2S_PTR2, H2S_PTR3, and H2S_PTR4 will be passed to the RCC calculation system and external interface.

When F_RD becomes logic "1", H2S_PTR0 of chip 2303 becomes logic "1". This drives these internal nodes in chip 2303 that rely on H2S_PTR0 to the RCC computation system via a tri-state buffer 2301 and local bus 2320. In this example, an internal node associated with line 2348 is coupled with line 2348 depending on H2S_PTR0 on line 2353. When the F_RD signal becomes logic " 1 " again, data at internal nodes that can be driven by H2S_PTR1 is passed to the RCC calculation system. Here, the internal node coupled with line 2349 is affected. This data is driven to LD3 on lines 2331 and 2322.

When the F_RD signal becomes logic " 1 " again, H2S_PTR2 becomes logic " 1 " and data at the internal node associated with line 2350 is provided at LD3. This data is provided to both the RCC calculation system and the external interface. The tri-state buffer 2301 allows data to be delivered to the local bus 2320 and then to the RCC calculation system. For the external interface, this data is driven to LD3 on lines 2331 and 2322 by enabling the H2S_PTR2 signal. In response to the F_RD signal, look-up table address counter 2304 is counted and directs look-up table 2309 to row 4 so that lines 2350-line 2329 (wire 3) at the external interface are connected. From these internal nodes combined they are latched in the appropriate data.

When the F_RD signal becomes logic " 1 " again, H2S_PTR3 becomes logic " 1 " and data at the internal node coupled with line 2351 is provided at LD1. This data is provided to both the RCC calculation system and the external interface. The tri-state buffer 2301 allows data to be delivered to the local bus 2320 and then to the RCC calculation system. For the external interface, this data is driven to LD1 on lines 2332 and 2323 by enabling the H2S_PTR3 signal. In response to the F_RD signal, the look-up table address counter 2304 counts and directs the look-up table 2309 low 5 so as to connect lines 2351-line 2327 (wire 1) at the external interface. From these internal nodes combined they are latched in the appropriate data.

When the F_RD signal becomes logic " 1 " again, H2S_PTR4 becomes logic " 1 " and data at the internal node coupled with line 2352 is provided at LD4. This data is provided to both the RCC calculation system and the external interface. The tri-state buffer 2301 allows data to be delivered to the local bus 2320 and then to the RCC calculation system. For the external interface, this data is driven to LD4 on lines 2333 and 2324 by enabling the H2S_PTR4 signal. In response to the F_RD signal, the look-up table address counter 2304 counts and directs the look-up table 2309 to low 6 so as to connect lines 2322-2323 (wire 4) at the external interface. From these internal nodes combined they are latched in the appropriate data.

This process of driving data at the internal node of chip m1 with the RCC calculation system and then to the RCC calculation system and external interface continues sequentially for the other chips. First, the internal node of chip m1 is driven. Secondly, the internal node of chip 0-1 (chip 2303) is driven. Next, if present, the internal node of chip 1-1 will run. This continues until the last node drives on the last chips of the last board. Thus, if present, the second node of chip 7-8 will run. Finally, if present the internal node of chip m2 will be driven.

Although Figure 71 only shows the data output control logic to drive an internal node of chip 2303, other chips also have internal nodes that need to be driven by the RCC computing system and the external interface. have. Regardless of the number of internal nodes, the data output logic will drive the data from the internal node on one chip to the RCC computing system, and in another cycle, will have different sets of internal nodes on the same chip. Powered by the RCC computing system and external interface. The data output control logic moves to the next chip, performs the same two-step operation of driving data designated to the RCC computing system and then driving data designated to the external interface to the RCC computing system and internal interface. do. Although the data is directed to the external interface, the RCC computing system must have internal state information corresponding to the internal state information of the hardware model in the RCC hardware array, the model for the entire user design in software. Since the RCC computing system must have information about the data.

Board layout

The board layout of the coverage system corresponding to one embodiment of the present invention will be described with reference to FIG. The boards may be installed in the RCC hardware array. The board layout is similar to that described in Figures 8 and 36-44 and as described below.

In one embodiment, the RCC hardware array includes six boards. Board m1 is connected to board 1 and board m2 is connected to board 8. Devices and connections of boards 1, 2, 3 and 8 have been described with reference to FIGS. 8 and 36-44.

Board m1 includes chip m1. For other boards, the interconnect structure of the board m1 is connected with a south interconnection of chip m1 to chip 0, chip 2, chip 4 and chip 6 of the board 1. Similarly, board m2 includes chip m2. For other boards the interconnect structure of the board m2 is a chip m2 connected in south interconnection with chip 0, chip 2, chip 4 and chip 6 of the board 8.

Yes

To illustrate the operation of one embodiment of the present invention, a hypothetical user circuit design will be used. In a structured register send level (RLT) HDL code, the exemplary user circuit design is as follows.

module register (clock, reset, d, q);

input clock, d, reset;

output q;

reg q;

always @ (posedge clock or negedge reset)

if (~ reset)

q = 0;

else

q = d;

endmodule

module example;

wire d1, d2, d3;

wire q1, q2, q3;

reg sigin;

wire sigout;

reg clk, reset;

register reg1 (clk, reset, d1, q1);

register reg1 (clk, reset, d2, q2);

register reg1 (clk, reset, d3, q3);

assign d1 = sigin ^ q3;

assign d2 = q1 ^ q3;

assign d3 = q2 ^ q3;

assign sigout = q3;

?? a clock generator

always

begin

clk = 1;

# 5;

clk = 1;

# 5;

end

// a signal generator

always

begin

# 10;

sigin = $ random;

end

// initialization

initial

begin

reset = 0;

sigin = 0;

#One;

reset = 1;

# 5;

$ monitor ($ time, "% b,% b," sigin, sigout);

# 1000 $ finish;

end

end module

The code is reproduced in FIG. Certain functional details of the circuit design are not necessary to understand the present invention. However, the reader should understand that the user generates the HDL code to design the circuit for the simulation. The circuit represented by the code performs a certain function designed by the user in response to an input signal and generates an output.

FIG. 27 shows a circuit diagram of the HDL code described in FIG. In most cases, the user actually generates a circuit diagram of the nature before presenting the nature on the HDL form. Certain schematic capture tools allow generating the useful code after the schematic circuit diagram has been entered and processed.

As shown in FIG. 28, the simulation system performs component type analysis. The HDL code is currently analyzed, as shown in Figure 26, which represents the original circuit design of the original user. The first few lines of code (ie, the part identified by reference numeral 900) starting with "module register (clock, reset, d, q)" and ending with "endmodule" are register definition sections.

The next few lines of code, reference number 907, indicate wired interconnect information. Wireline parameters of HDL, known to those skilled in the art, are used to represent physical connections between structural entities such as gates. Because HDL is primarily used to model digital circuits, wired variables require variables. Usually, "q" (e.g. q1, q2, q3) represents the output wired line and "d" (e.g. d1, d2, d3) represents the input wired line.

Reference numeral 908 shows the test-bench output "sigin". Register number 909 shows the test bench input "sigout".

Reference numeral 901 shows register components S1, S2, and S3. Reference numeral 902 denotes coupling components S4, S5, S6, S6. It should be noted that coupling components S4-S7 have output variables d1, d2, d3 which are inputs to register components S1-S3. Reference numeral 903 shows the clock component S8.

The code line numbers in the next series show the test bench components. Reference numeral 904 denotes a test bench component (driver) S9. Reference numeral 905 shows a test bench component (initialization) S10, S11. Reference numeral 904 shows a test bench component (monitoring) S12.

The component type analysis is summarized in the following table.

Component type S1 register S2 register S3 register S4 Combination S5 Combination S6 Combination S7 Combination S8 Clock S9 Test-Bench (Driver) S10 Test-Bench (Initialize) S11 Test-Bench (Initialize) S12 Test-Bench (Inspection)

Based on the component type analysis, the system generates a software model for the entire circuit and a hardware model for the registers and coupling components. S1-S3 are register components and S4-S7 are coupling components. These components can be modeled in hardware to allow a user of a simulation system to simulate the entire circuit in software or to simulate in software and optionally in hardware. In addition, the user can emulate the circuit by the target system while maintaining software control to start, stop, examine values, and enter input values between.

29 illustrates signal network analysis of the same structured RTL level HDL code. As shown, S8, S9, S10, S11 are modeled or provided in software. S9 is essentially the test-bench process that generates sine signals and S12 is essentially the testbench monitoring process that receives the sigout signal. In this example, S9 generates a random sign to simulate the circuit. However, registers S1 to S3 and coupling components S4 to S7 are modeled in hardware and software.

At the boundary between the hardware and the software, the system allocates memory space for the various residual signals used to interface the software model to the hardware model (ie q1, q2, q3, CLK, sign, sigout). . The memory space allocation is shown in the table below:

signal Memory address space q1 REG q2 REG q3 REG clk CLK sign S2H sigout H2S

Figure 30 shows the hardware / software partial results in the circuit design example above. 30 is a more realistic illustration of the hardware / software portion. The software side 910 is connected to the hardware side 912 via the software / hardware boundary 911 and the PCI bus 913.

The software side 910 includes and is controlled by the software kernel. In general, the Kernel is the main control loop that controls the overall operation of the SE emulation system. While a constant test bench process is active, the Kernel emulates the active test-bench component, emulates a clock component, propagates combined logic data, as well as clocks to update registers and memory. Search the edges and proceed with the simulation time. Even if the kernel is present on the software side, some of its operations and instructions may operate in hardware because a hardware model exists for those instructions and operations. Thus, the software controls both software and hardware models.

The software side 910 includes a full model of the user circuit including S1-S12. The software / hardware boundary portion of the software side includes an I / O buffer or address space S2H, CLK, H2S and REG. A driver test-bench process S9 is connected to the S2H address space, a monitoring test bench process S12 is connected to the H2S address space, and the clock generator S8 is connected to the CLK address space. . The registers S1-S3 output signals q1-q3 may be allocated to the REG space.

The hardware model 912 has a model of coupling components S4-S7, which components are on the pure hardware side. At the software / hardware boundary portion of the hardware model 912, sigout, sigin, register outputs q1-q3 and the software clock 196 are implemented.

In addition to the model of the user circuit design, the system generates a software clock and an address pointer. The software clock provides signals to an enable input to registers S1-S3. As described above, the software clock corresponding to the present invention eliminates race conditions and hold-time violation issues. When a clock edge is searched in software by the main clock, the search logic triggers the corresponding search logic in hardware. In time, the clock edge register 916 generates an enable signal to gate a register enable input with data remaining on the input to the register.

The address pointer 194 is also shown for illustrative and conceptual description. Address pointers are practically implemented on each FPGA chip, allowing the data to be sent selectively and successively to its destination.

The coupling elements S4-S7 are also connected to the register elements S1-S3, sign and sigout. These signals travel on and from the I / O bus 915 to the PCI bus.

Before mapping, settling, and routing of the steps, a complete hardware model is shown in FIG. 31 except for the address pointer. The system does not map the model to a particular chip. The registers s1-S3 are provided for not being connected to the I / O bus and the coupling component S4-S6. Coupling component S7 is the output q3 of register S3. The sigin, sigout and software clock 920 are also modeled.

Once the hardware model is determined, the system is mapped, settled, and routes the model to one or more chips. This particular example may actually be implemented in a single Altera FLEX 10K, but for educational purposes it may be conceivable that this requires two chips to implement the hardware model. Figure 32 shows chip part results for one particular hardware model from the above example.

In Fig. 32, a perfect model is shown by the chip boundaries represented by dashed lines (except fraudulent I / O and clock edge registers). The result is produced by the compiler of the SE emulation system before the final structure file occurs. Thus, the hardware model requires at least three wires between the two chips for wired lines 921, 922 and 923. In order to minimize the number of pins / wires required between the two chips (chip 1, chip 2), another model-chip part must be generated or a multiplexing structure must be used.

In analyzing the particular partial result shown in Fig. 32, the number of wires between the two chips can be reduced by removing the sigin wired line 923 from chip 2 to chip 1. 33 shows this portion. Although the particular part of FIG. 33 appears to be a better part than that of FIG. 32 based on tens of thousands of wires, the example would be considered that the SE emulation system selected FIG. 32 after performing the mapping, fixation and operational routing. Can be. The result portion of Figure 32 may be used as the basis for generating the rescue file.

Figure 34 shows the logic patching operation for the same hypothetical example in which the final realization of two chips is shown. The system used the partial results of FIG. 32 to generate the rescue file. However, the address pointers are not shown for simplicity. The two FPGA chips 930 and 940 are shown. Chip 930 includes divided parts of the user circuit design, TDM unit 931, receiver side, the software clock 932 and I / O bus 933 among other components. Chip 940 includes, among other components, divided portions of the user circuit design, a TDM unit 941 for the transmit side, the software clock 942 and an I / O bus 943. The TDM units 931 and 941 have been described with reference to Figs. 9A, 9B and 9C.

The chips 930 and 940 have interconnect wires 944 and 945 connecting the fraudulent hardware model together. These two interconnect wires are the interconnect portion shown in FIG. Referring to Figure 8, the interconnect is an interconnect 611 located on chip F32 and chip F33. In one embodiment, the maximum number of wires / pins for each interconnect is 44. In Figure 34, the modeled circuit requires only two wires / pins between chips 930 and 940.

The chips 930 and 940 are connected to the bank bus 90. Since only two chips are implemented, the two chips may be in the same bank or each may be in a different bank. Ultimately, one chip is connected to one bank bus and another chip is connected to different banks so that the output at the FPGA interface is the same as the output of the PCI interface.

The foregoing preferred embodiments of the invention are presented for purposes of illustration and description and are not intended to limit the invention to the precise form disclosed. Clearly, those skilled in the art can make many modifications and variations. Those skilled in the art can make various modifications of the present invention without departing from the scope and spirit of the invention. Accordingly, the invention is limited only by the appended claims below.

Claims (20)

In a method for generating a custom modeled design VCD file, Selecting a simulation session range starting at simulation time t0 and ending at simulation time t3; Selecting a simulation target range starting at simulation time t1 and ending at simulation time t2, wherein simulation time t1 is equal to or greater than simulation time t0 and simulation time t2 is equal to or less than simulation time t3; Generating a VCD file of the modeled design for a selected simulation target range; And Accessing a VCD file directly from simulation time t1 to debug the modeled design. The method of claim 1, Providing primary inputs to the modeled design for evaluation; And A method of generating a VCD file, further comprising the step of recording a simulation history during a simulation session scope. The method of claim 2, Processing the simulation history; And And evaluating the processed simulation history from simulation time t0 to simulation time t2 in the modeled design. The method according to claim 3, The VCD file generation step Generating evaluated results from a modeled design based on the processed simulation history; And And storing the evaluated results during the simulation target range in the VCD file. The method of claim 4, wherein Compressing the primary inputs; And And recording the compressed key inputs as a simulation history. The method of claim 4, wherein The processing step Decompressing the compressed primary inputs; And Providing the decompressed key inputs to the modeled design for evaluation as a processed simulation history. The method of claim 4, wherein The recording step A method of generating a VCD file comprising recording key inputs as a simulation history. The method of claim 1, Storing state information of the modeled design at a simulation time t0 in a first file; And And storing state information of the modeled design at a simulation time t3 in a second file. In electrical design automation system for verifying user design, A computing system including a memory and a central processing unit for modeling a user design in software; An internal bus system coupled to the computing system; Reconfiguration hardware logic coupled to the internal bus system and for modeling at least a portion of a user design in hardware; Control logic coupled to the internal bus system for controlling data transfer between the reconstruction hardware logic and a computation system; And On-demand VCD logic for recording simulation history for the selected simulation session range and dumping state information from the hardware model to the VCD for the selected simulation target range, the target simulation range being an electrical design within the simulation session range. Automation system. The method of claim 9, The custom VCD logic unit A first range selection logic for selecting a simulation session range starting at simulation time t0 and ending at simulation time t3; A second range selection logic for selecting a simulation target range starting at simulation time t1 and ending at simulation time t2, wherein simulation time t1 is greater than or equal to simulation time t0, and simulation time t2 is less than simulation time t3. Second range selection logic; A dump logic section for generating a VCD file of a hardware-modeled design for the selected target range; And Electrical design automation system further comprising a connection logic for accessing the VCD file directly from the simulation time t1 to debug the user design. The method of claim 10, VCD logic on demand A test bench process providing key inputs to the hardware-modeled design for evaluation; And And a recording logic in a calculation system for recording simulation history for the simulation session range. The method of claim 11, VCD logic on demand Process logic in a calculation system for processing the simulation history; And And an evaluation logic in reconstruction hardware logic for evaluating the processed simulation history in a hardware-modeled design from simulation time t0 to simulation time t2. The method of claim 12, And a dump logic dumps evaluation results from the hardware-modeled design into a VCD file according to the processed simulation history during a simulation target range. The method of claim 13, The recording logic section Compression logic for compressing primary inputs; And And further include a write logic for recording the compressed key inputs as a simulation history. The method of claim 14, The processing logic section Decompression logic to decompress the compressed primary inputs; And And a data transfer logic that passes the decompressed primary inputs into a hardware-modeled design as the processed simulation history for evaluation. The method of claim 13, And the write logic further comprises a write logic to record the key inputs as a simulation history. The method of claim 9, An electrical design automation system further comprising a state storage logic for storing state information of the hardware-modeled design at simulation time t0 in the first file and storing state information of the hardware-modeled design at simulation time t3 in the second file. . In a custom VCD system for providing evaluated information for a selected simulation target range of simulation times, the evaluation takes place in the modeled design, A first logic section for selecting a simulation session range starting at simulation time t0 and ending at simulation time t3; A second logic unit for selecting a simulation target range starting at simulation time t1 and ending at simulation time t2, wherein simulation time t1 is greater than or equal to simulation time t0 and simulation time t2 is less than or equal to simulation time t3; Logic section; A generation logic section for generating a VCD file of the evaluated information for the selected simulation target range; And On-demand VCD system including connection logic to access the VCD file directly from simulation time t1 to debug the modeled design. The method of claim 18, A compression logic for receiving and compressing the main input data during the simulation session range period; And A custom VCD system comprising decompression logic that decompresses the compressed main input data and passes the uncompressed main input data into a modeled design for evaluation. The method of claim 19, The generation logic section And a dump circuit for dumping the evaluated information into the VCD file, wherein the evaluated information is generated by evaluating key inputs decompressed by the modeled design.