KR100928134B1 - Custom DCC Systems and Methods - 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 selected simulation target ranges. Each of these attributes will be described in detail. When the user selects a simulation session range, the RCC system writes a highly compressed version of the primary 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, primary 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}

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 relates generally to Electronic Design Automation (EDA). More specifically, the present invention relates to a value change dump (VCD) improvement for accelerating design debug sessions.

In general, electronic design automation (EDA) is a computer-based tool implemented at various workstations to provide designers with automatic or semi-automatic tools for designing and verifying user's custom circuit designs. EDA is commonly used to create, analyze, and compile any electronic design for simulation, emulation, prototyping, execution, or computing purposes. EDA technology can also be used to develop systems that use user-designed subsystems or components (ie, target systems). The end result of an EDA is a modified and complementary design, usually in the form of an independent integrated or printed circuit board, that improves the original design while maintaining the original design category.

The value of software that simulates circuit designs after hardware emulation is recognized in many industries that use EDA technology and take 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, in every one debug / test session, a user can simulate or debug a circuit design using software simulation for a portion of the time, use their results to accelerate the simulation process using a hardware model for another time, and then Return to software simulation in time. In addition, because the internal registers and combinational logic values change as the simulation time progresses, 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 cumbersome nature of using two separate and independent pure software simulation processes and pure emulation / acceleration processes, making the overall system more user friendly. However, co-simulation still has many drawbacks: (1) a co-simulation system requires manual partitioning, (2) co-simulation uses two small-combination engines, and (3) The co-simulation speed is as slow as the software simulation speed, and (4) the co-simulation system collides with the race condition.

First of all, the division between software and hardware is performed manually rather than automatically, which is more burdensome for the user. In essence, co-simulation requires the user to split the design (start at the operating level, then the RTL, and gate level) and test the model itself with a very large functional block of software and hardware. This restriction requires some degree of intelligence from the user.

Secondly, the co-simulation system utilizes two small coupled independent engines, which causes internal-engine synchronization, coordination, and flexibility issues. Co-simulation 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 can be used for inspection and loading. The values within the circuit and the combinational logic levels modeled in the registers cannot be used for easy inspection and downloading from one side to the other, thus limiting the use of these co-simulation systems. Typically, when a user switches from software simulation to hardware acceleration, the entire design may need to be re-simulated. Thus, if a user wants to switch between software simulation and hardware emulation during a single debug session while checking registers and combinatorial logic values, the co-simulation system does not provide this capability.

Third, the co-simulation speed is as slow as the simulation speed. Co-simulation 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 synchronization between software and hardware deters the overall performance at a rate as slow as software simulation. The additional burden of coordinating the operation of these two engines adds to the slow speed of the co-simulation system.

Fourth, co-simulation systems cause setup, hold time and clock glitch issues due to race conditions between clock signals. Co-simulation uses a hardware driven clock that can be input to different logic elements at different times due to different wire lengths. If these logic elements are to evaluate the data together, some logic elements evaluate the data in any time period and other logic elements evaluate the data in another time period, resulting in an uncertain level of evaluation results.

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

A typical ASIC chip designer uses a simulator to debug a design: that is, the designer can simulate the design using a test bench process to observe their response to various stimulus among others. Test it. Based on the examination of some key nodes and outputs 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 (e.g., over millions of gates), the simulator must go through steps of millions of simulation time periods 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, the actual bug must be specifically located 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 late (eg t1000000)? Also, is there a problem where calibration can be provided (ie physical location of the circuit design)? Initially, the designer does not know exactly where the bug occurred (simulation time step), but can make reasonable estimates. The designer can have several ways to proceed to the exact simulation time at which the problem is thought to be located. The simulator can assist the designer in this task by providing a VCD (Value Change Dump) file through one of two conventional methods—full VCD and optional VCD.

In the full VCD method, the simulator stores the entire simulation as a VCD file from simulation time t0 to the end of the simulation. This VCD file is then analyzed by the designer to isolate the bug. The designer can make a reasonable estimate of the general position and analyze the position with some elaborate stepping: if the designer somewhat suspects that the bug occurred somewhere between simulation times t350 and t400, like simulation time t345 As a result, we will proceed to the simulation time that is located just before the suspected simulation time. The designer will then check very carefully for these suspected areas (ie, t345 to t400).

However, to reach this simulation time, the designer must return the entire simulation from the beginning with the VCD file (ie t0), regardless of where the bug occurred. If the initial estimate of the bug's location is wrong, you'll have to make another estimate and return the simulation from the beginning. For designs with more than one million gates and more than one million simulation time steps, this debugging process of returning a simulation from the start is a very time consuming process resulting from false 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 full VCD file of approximately 100 GB is common. These VCD files are too large in most file systems. Moreover, these large VCD files are too large for most waveform viewers to handle.
In addition, the simulation process is three times slower in full VCD. After each simulation time (or when the value changes), the full VCD requires that state values be recorded. This process of accessing storage requires time, and as a result, simulation must be stopped until the storage operation ends at a given simulation time. Today, the full 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 designer's need to return the entire simulation from the start. Initially, the designer runs the simulation and must observe problems with the design. Then, estimate where the problem is located. If the designer assumes that a 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 much disk space because the entire simulation is not stored. 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 a system or method that corrects problems caused by currently known simulation systems, hardware emulation systems, hardware accelerators, co-simulation, and co-coverage systems.

One embodiment of the present invention is to provide a custom VCD file without a simulation return. On-demand VCD features are incorporated into an RCC system that includes an RCC computing system and an RCC hardware accelerator. An RCC computing system includes the computing resources necessary for a user to simulate a user's entire software-modeled software design with software and to control hardware acceleration of the hardware-modeling design portion. RCC hardware accelerators include logic elements (eg, FPGAs) in a reconfigurable array that allow at least a portion of the user hardware design to be modeled to allow the user to accelerate 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." The VCD file will be created during this narrow "simulation target range". After the selection of "simulation session range", the RCC system quickly provides a primary input to the hardware model in the RCC hardware accelerator for evaluation in the test bench process, thereby rapidly simulating the design for the entire period 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 beginning of the simulation session range, the RCC system stores the hardware state information of the design at this point so that the user can perform an offline simulation if necessary. At the end of the simulation session scope, the RCC system can quickly return to the point left off to simulate beyond this simulation session range at any time without rewinding the simulation to the hardware state information of the design at that point. Save it.

When the user selects the "simulation target range", the RCC system decompresses the compressed primary input of the simulation history file and provides this decompressed primary input to the evaluation RCC hardware accelerator, thereby initializing the simulation target range. Simulate quickly. In the simulation target range, the RCC system dumps the primary output or evaluation results from the hardware model to 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 observe the VCD file in more detail through the waveform viewer to debug the design. This is accomplished without restarting the simulation. If the bug is not within this 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 is isolated and cleaned up, the user can continue to simulate beyond the current simulation session to the next simulation. The stored hardware state information at the end of the current simulation session scope is loaded into the RCC system. The user can then launch the simulation. The custom VCD feature is available both online and offline.

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

1 shows a high level 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 illustrates one embodiment of a 4x4 FPGA array and their internal access,

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 diagram of clock / data network analysis critical to 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 finite state machine for controlling the clock edge detection logic of FIG. 19 in accordance with an embodiment of the present invention.

21 illustrates internal access, 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,

35A-35D illustrate "hops" and the internal access principle in two examples,

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

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

38 (A)-(B) show side views of an FPGA board access in accordance with one embodiment of the present invention,

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

40 (A) and 40 (B) show the FPGA internal board internal access configuration,

41A to 41F show top views of the board internal access connector,

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

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

44 illustrates a direct-naver and one-hop dual board internal access layout of an FPGA array in accordance with 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 illustrates 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 device.

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 is 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 illustrates a more detailed logic diagram of the control logic internal data according to an embodiment of the present invention.

71 illustrates a more detailed logic diagram of the 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 to explain the retention time and clock glitch 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.

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

FIG. 77 (B) shows a timing diagram of the logic circuit of FIG. 77 (A) for explaining the clock glitch 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, FIG. 80 (B) shows the latch without glitches, without being affected by timing, in accordance with one embodiment of the present invention,

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

FIG. 82 illustrates a timing diagram of a trigger mechanism of latches and flip-flops that are not affected by timing and which are not affected by timing according to an embodiment of the present invention.

These drawings 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 on-demand VCD operation in accordance with one embodiment of the present invention.

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 present invention within such systems through a system referred to as a "SEmulator" or "SEmulation" system. Throughout the specification, the terms "SEmulator system", "SEmulator" or simply system may be used. These terms refer to various apparatus and method embodiments according to the present invention for any combination of four modes of operation: (1) software simulation, (2) simulation with hardware acceleration, (3) circuit-internal emulation ( ICE), and (4) post-simulation analysis comprising their respective setup or pre-processing steps. 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 system", or "RCC computing system" include simulation / co-verification, including the main processor, the software kernel of the user design, and the software model. Represents a system part. Terms such as “reconfigurable hardware array” or “RCC hardware array” refer to a 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.

delete

delete

In addition, the present specification refers to "user" and "circuit design" or "electronic design" of the user. The "user" is the person using the SEmulation system through that interface and may be the designer of a circuit or test / debugger that participates little or no 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 test / debug purposes in software or hardware. In many cases, the "user" has also designed "circuit design" 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 Implementation Means
E. Simulation Server

delete

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 implementation means

A. Overview

B. Address Pointer

C. Gate Data / Clock Network Analysis

D. FPGA Array and Control

 E. Optional Embodiments Using High Density FPGA Chips

F. TIGF Logic Devices

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 of 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 coupled component regeneration (5) dual buffer clock modeling by software clock and gate clock / data logic to avoid race conditions, and (6) re-simulate or hardware accelerate the user's circuit design from randomly chosen points within an elapsed simulation session.ability. The end result is a flexible and fast simulator / emulator system and method with full HDL functionality and emulator execution performance.

A. Simulation / Hardware Acceleration Mode

Automated component type analysis allows the SEmulator system to model custom circuit designs in software and hardware. The entire user circuit design is modeled in software, while the evaluation component (ie, register component, coupling component) is 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, acts 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 is running, the kernel evaluates active test bench components, evaluates clock components, detects clock edges, sends combinatorial logic data, updates registers and memory, and simulates them. Advance time. This software kernel provides a hardware acceleration engine for the closely coupled simulator 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 switch between four modes of operation selectively. 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 simulates the circuit in software over a period of time, accelerates the simulation through hardware modeling, and returns back to the software simulation mode.

In general, SEmulation systems provide users with the ability to "see" all modeled components, whether modeled in software or hardware. For various reasons, the coupling component is not as visible as a register, and thus obtaining the coupling component data is difficult. One reason is that instead of the actual coupling component, the coupling component, typically 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 and regenerates the coupling component. This regeneration process is not always performed, but rather only at the request of the user, as there is a cost to regenerate the combined component.

Since the software kernel resides on the software side, a clock edge detection mechanism is provided to trigger the generation of a so-called software clock that drives the enable input to various registers in the hardware model. The timing is tightly controlled through the double buffer circuit implementation so that the 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 synchronously to ensure that all data values are gated together without any risk of holding time violations.

Software simulation is also fast because the system logs all input values and selected register values / states, thus minimizing overhead by reducing the number of I / O operations. The user can optionally select a 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 these modes so that the user has the option to initiate, abort, generate values, go through a single step, and switch from one mode to another.

C. Post-Simulation Analysis Mode

The log provides the user with a historical 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 every N cycles). During the post-simulation phase, if the user wants to examine various data near the X point in the simulation session that he just ended, the user has one of the logged points, i.e. the logged point that is closest to and temporarily located before point X. Go to Y The user then simulates from the logged point Y selected from the selected point X to obtain the simulation result.

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

D. Hardware Implementation Means

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 a model of a large circuit that is extended over all of these sixteen chips. The interconnect means allows each chip to access two "jumps" or other chips within the link.

Each FPGA chip implements an address pointer for each of the I / O address spaces (ie, REG, CLK, S2H, H2S). All combinations of address pointers associated with a particular address space are linked together. Thus, during data transfer, the word data of 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 of each chip in the selected address space. Selected sequentially until accessed. This sequential selection of word data is accomplished by the transfer of word selection signals. This word select signal propagates through the address pointer in the chip, 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 in the reconfigurable board operates at twice the bandwidth of the 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 follow the throughput of the PCI bus system so that performance is not compromised 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. Examples of such high density chips are Altera 10K130V and 10K250V chips. The use of these chips allows the board design to be modified so that only four FPGA chips (Altera 10K 100) are used per board instead of eight low-density FPGA chips.

The FPGA array of the simulation system is provided on the motherboard through a specific board interconnect structure. Each chip may have eight sets of interconnects, where the interconnects are direct neighbor interconnects (ie, N [73: 0], W [73: 0], E [73: 0]), and one-hop neighbor interconnects (i.e., NH [27: 0], SH [27: 0], XH [36: 0], excluding local bus connections on one single board and on the other board as a whole) , XH [72:37]). Each chip may be interconnected directly to adjacent neighboring chips, or may be interconnected in one hop with 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.

The interconnect can couple with logic elements and other components within a single board. However, an internal board connector may be used to join these boards and interconnects together for (1) a PCI bus through the motherboard and the array board, and (2) any other array board to transfer signals between any two array boards. Is provided.

Motherboard connectors connect the board to motherboard mode, which connects to the PCI bus, power, and ground. On some boards, motherboard connectors are not used for direct connections to the motherboard. In a six board configuration, only boards 1, 3, and 5 are directly accessed 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 interconnects of these boards are joined together through internal board connectors arranged on the solder side or component side. PCI signals are routed through only one board (usually the first board). Power and ground are applied to other motherboard connectors for the 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 for one network, or multiple users / processes in a non-network environment, may access the same server-based reconfigurable hardware unit to review / debug the same or different user circuit designs. Can be. The access is achieved through a time sharing process where the scheduler determines access priorities for multiple users, swaps jobs, and optionally locks hardware model access among the scheduled users. In one scenario, each user can access a server for the first time to map each user design to a reconfigurable hardware model, in which case the system compiles the design to generate software and hardware models, and clustering operations. Reconfigure the FPGA chip of the reconfigurable hardware unit to perform place-and-route operations, generate bitstream configuration files, and model the hardware portion of your design. do. If one user accelerates the design using a hardware model and hardware state downloaded to his memory during software simulation, the hardware unit can be opened for access by another user.

The server provides multiple users or processes to access the reconfigurable hardware unit for acceleration and hardware state swapping purposes. 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 swapper. The restore 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 can be reproduced or debugged. Can be restored for cycle-by-cycle stepping.

F. Memory Simulation

The memory simulation or memory mapping embodiment of the present invention provides an effective approach for a simulation system to manage various memory blocks associated with a user-configured hardware model programmed with an FPGA chip array in a reconfigurable hardware unit. In the memory simulation embodiment of the present invention, a number of memory blocks associated with a user design are mapped to SRAM memory elements of the simulation system instead of inside the logic element, which is used to construct and model the user design. The memory simulation system comprises logic that interoperates with the memory state machine, evaluation state machine, and control: (1) the main computing system and its associated memory system, (2) an SRAM memory device coupled to the FPGA bus within the simulation system, And (3) FPGA logic elements that include a debugged configured and programmed user design. 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 cycles-DMA data transfer, evaluation and memory access.

The FPGA logic element 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) between FPGA logic elements Data evaluation, (2) coordinates write / read memory access between FPGA logic devices and SRAM memory devices. In conjunction with the FPGA logic element side, the FPGA I / O controller side may include (1) the main computing system and the SRAM memory element, and (2) the memory state to handle DMA, write and read operations between the FPGA logic element and the SRAM memory element. It includes machine and interface logic.

G. Joint Coverage System

One embodiment of the present invention is a co-verification system that includes 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 devices 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 include an RCC computing system and an RCC hardware array along with other functionality to debug the software and hardware portions of the user design, and may use actual target systems and / or I / O devices.

The RCC computing system also includes clock logic (for edge detection and software clock generation), test bench processes for testing user designs, and any I that decides to model in software instead of using a real physical I / O device. Contains device model for / 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 such software clocks provides the synchronization necessary to process the input and output 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 includes (1) an RCC computing system and an RCC hardware array, and (2) a control logic that provides traffic control between an RCC hardware array and an external interface (coupled to a target system and an external I / O device). . Since the RCC computing system has a model of the overall design in software, including user-designed parts that are modeled on the RCC hardware array, the RCC computing system must also have access to 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. Workstation 10 is coupled to reconfigurable hardware model 20 and emulation interface 30 via PCI bus system 50. 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 internal-circuit emulation setup 70, including the emulation interface 30 and the target system 40 (indicated by the dashed boxes), allows the emulation of the user circuit design in the target system environment during a particular test / debug session. If not required, it is not provided for this setup. Without the internal-circuit emulation setup 70, the reconfigurable hardware model 20 communicates with the workstation 10 via the PCI bus 50.

In conjunction with the internal-circuit emulation setup 70, the reconfigurable hardware model 20 emulates or simulates a 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, the input and output signals between the target system 40 and the modeled electronic subsystem are converted into a reconfigurable hardware model 20 for evaluation. Should be provided. Thus, input and output signals from target system 40 to / from reconfigurable hardware model 20 pass through emulation interface 30 and PCI bus 50 to cable 60. Is passed through. Optionally, input / output signals of the target system 40 may be communicated 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 executes a software kernel that needs to access (write / read) the reconfigurable hardware model 20.

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

As is already known to those skilled in the art, after the operating system is loaded into the memory of the workstation 10 by the initial firmware, control passes its initialization code to set up the necessary data structures to load and initialize the device driver. Control is then passed to the command line interpreter CLI to instruct the user to execute the program. 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 starts running.

One embodiment of the present invention is a specific application of SEmulation. During its execution, an 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 interfacing with displays / keyboards / mouses.

Workstation 10 has a suitable user interface that allows a user to enter circuit design data, compile 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 user-accessible menu-driven option and a set of commands that can be viewed with a monitor and entered with a keyboard and mouse. Typically, a user uses computing system 80 with keyboard 90.

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 in order to partition the 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 some 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 the 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 circuit design. Return to the simulation section, and return to hardware acceleration until the test / debug process is performed. The ability to switch between every cycle and between user arbitrarily software simulation and hardware acceleration is one of the important features of this embodiment. This feature is particularly useful in the debug process because it allows the user to quickly go to a specific point or cycle using hardware acceleration mode and then use software simulation to examine various points and debug the circuit design. Moreover, the SEmulation system allows the user to see all components whether the internal implementation of the components is hardware or software. The SEmulation system accomplishes this by reading the register value from the hardware model when the user requires such a read, and then reconstructing the coupling 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. 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 Peripheral Circuit 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 devices may be coupled to the PCI bus at the same level or at different levels, such as workstation 10, reconfigurable hardware model 20, and emulation interface 30. Like PCI bus 52, each PCI bus at another level is connected to another PCI bus level, such as PCI bus 50, through PCI-to-PCI bridge 51, if all present. In the PCI bus 52, two PCI devices 53, 54 may be combined.

delete

delete

The reconfigurable hardware model 20 is programmable and configured to design the hardware portion of the user's electronic system design and includes a reconfigurable field-programmable gate array (FPGA) chip array. In this embodiment, the hardware model is reconfigurable; In other words, the hardware can be reconfigured to suit a particular calculation or user circuit design directly. 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 within the system. In this way, the system can be optimized to perform specific calculation or logic operations. The reconfigurable system is flexible, allowing the user to address a few hardware defects that occur during manufacturing, testing, or use. In one embodiment, the reconfigurable hardware model 20 includes a two dimensional array of computing elements including FPGA chips to provide computing 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 invention may be implemented using application specific integrated circuit (ASIC) technology. 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. Although such an ASIC or custom IC is already manufactured and readily available, it may be more desirable to emulate a chip that is not actually 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 the end user 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 stimulus, such as the input signal, the designer can verify the accuracy of the circuit through the simulation 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 a logic low, "01" is a logic high, "10" is a "z" and "11" is a "x"-to provide a four-state value for the 2- 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" so that the reset sequence that changes depending on the particular applicable code resets all register values to "0" or "1".

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 step 115 directs the user to step 160.
After the abort, if the user wants to check the combined component value, the system kernel rereads the state of the hardware register component to regenerate the entire software model containing 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. As shown in the flowchart, step 115 branches to the abort / value check routine. 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 branches to step 115. Here, the user can continue the simulation and stop / 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 compilation process, the SEmulation system is partially mapped into the hardware model. Here, if hardware acceleration is required, the system moves registers and coupling 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 periods of time at an accelerated rate. The kernel writes test-bench outputs to the hardware model, updates the software clock, and then reads 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 coupling component and regenerating the coupling component with the register value. Because of the need for software intervention to recreate this coupling 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. This description will be discussed in the Combined Component Regeneration Processor.

delete

delete

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 can stop the hardware accelerated simulation process at any time, check the values resulting from the simulation process, or the user can continue the hardware-accelerated simulation process. The stop / value checking routine branches 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 post-simulation analysis features. The system logs all input 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 a logging frequency of 1 / 10,000 writes / cycle, the output value is written 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. This post-simulation analysis method can be linked to any simulation waveform viewer for post-simulation. It will be discussed in more detail below.
In step 145, the user can select to emulate a simulated circuit design within the target system environment. If step 145 determines no, the algorithm terminates and the SEmulation process ends at step 155. If emulation with the target system is required, the algorithm proceeds to step 150. These steps include emulation interface board activation, plugging cables and chip pin adapters into the target system and executing the target system to obtain system I / O from the target system. System I / O from the target system includes 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, interrupt to modify the circuit design, or proceed with integrated circuit fabrication based on the valid circuit design, as disclosed in step 135.

delete

delete

delete

delete

III. Simulation / Hardware Acceleration Mode

In accordance with one embodiment of the present invention, a high level block diagram of software compilation or hardware configuration during compile time and run time is shown 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 to a form that can be used by the SEmulation system. The system creates a source design database for preprocessing 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. Fullman, PRINCIPLE, THEHNIQUE AND TOOLS (1988), which may be incorporated by reference herein.

Compilation time is represented by process 225, and execution time is represented by process / device 230. During compile 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 combined 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 assigned to 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 final result is a so-called "bitstream" configuration file 220.

In preparation of the execution time, the software model in code form is stored in a main memory in which an application program linked with a SEmulation program according to an embodiment of the present 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 general purpose 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 includes 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. Data between the 235 and the reconfigurable hardware board 250 is passed. 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 reconfigurable hardware board 250 via the processor / workstation 240 and the data bus 245.

4 shows a flow diagram of a compilation process according to one embodiment of the invention. The compilation process is processes 205 and 210 shown in FIG. The compilation 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 writing the code directly. The SEmulation system parses the HDL file (ASCII format) into binary format so that the operation 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 parsed HDL code.

Step 302 performs component type analysis by classifying the HDL component into a combined component, a register component, a clock component, a memory component, and a test-bench component shown as component type resource 303. The SEmulation system creates a hardware model for registers and coupling components, with the exceptions discussed below. Test-bench and memory components are mapped to software. Some clock components (e.g., derived clocks) are modeled in hardware, while other components reside within software / hardware boundaries (e.g., software clocks).

Coupling 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 coupling components include source gates (eg, AND, OR, XOR, NOT), selectors, adapters, multiplexers, shifters, and bus drivers.

Register components are simple storage elements. The state transition of a register is controlled by a 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-detect latches.

The clock component is a device that sends a periodic signal to the logic device to control the operation of the logic device. Typically the clock signal controls the updating of registers. 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, 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 monitors simulation by checking for value changes, executing value change dumps, checking signal value relational constraints, writing output test vectors to disk / memory, and 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 joining components. The primitive 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 the 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 a latch type register. (3) If a net driven in a process is defined in all possible execution paths, the net is a binding component.

A process with a single event control without multiple net drives is 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 stylus 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 a hardware register model of the SEmulation system 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 main 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 performs 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. This is due to component types, hardware resource limitations (i.e. floating point operations and many multiplication operations in software), simulation and communication overhead (i.e. test-bench processes in software, and test-bench processes in software). Small bridge logic between monitored signals), and user selection. 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 the 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 in 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 compilation process. The PCI interface unit allows the 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. These control circuits include I / O address pointers and data bus logic (discussed below in connection with FIGS. 11, 12, and 14) for communicating with the DMA engine to the simulator, and hardware state transitions and wire multiplexing (FIGS. 19 and 20). Evaluation control logic) to control). As is known to those skilled in the art, a direct memory access (DMA) unit provides additional data channels between the peripheral and main memory, which peripherals can access (ie, read, write) directly with the main memory without CPU intervention. Can be. Address pointers within each FPGA chip allow data to be moved between software and hardware models according to bus size limitations. Evaluation control logic is a finite state machine that ensures that the clock can enter the input into a register before the clock and data inputs enter these registers.

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 particular cell or gate level component within 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. Compilation ends at step 311.

As described above with respect to FIG. 4, the software kernel code is generated 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 execution of software simulations and hardware emulations. Because the kernel is located in the center of the hardware model, the simulator is integrated into 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, when decision 339 is reached, the control loop begins and the cycle repeats until the system fails to observe the active test-bench process, in which case the simulation or emulation session ends. 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 to generate. 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 then after 5 simulation times, a logic "1" signal will be generated. This clock generation process continues the cycle until interrupted by the user. This simulation time is run by the kernel.

Decision step 334 asks if any active clock edges have been detected, and some sort of logic evaluation occurs in software and possibly hardware models (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 the process proceeds to step 335 of updating the register and memory and to propagating the coupling 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 coupling component and stabilizes, the kernel proceeds to step 337.

Note that registers and coupling components are modeled in hardware, so the kernel controls the emulator portion of the SEmulation system. Indeed, the kernel may accelerate the evaluation of the hardware model at steps 334 and 335 whenever any active clock edge is detected. Therefore, unlike the prior art, the SEmulation system according to an embodiment of the present invention can accelerate the hardware emulator through the software kernel based on the component type (eg, register, combination). Moreover, the kernel controls the execution of software and hardware models every cycle. Essentially, the emulator hardware model can be characterized as a simulation coprocessor of a general purpose processor running a simulation kernel. The coprocessor speeds up the simulation.

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 terminated. 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, updates the registers and memory, detects clock edges, and simulates time to propagate combinational logic data. Proceed.
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 implementation process involves three independent tasks: mapping, deployment, and routing. The tools are generally referred to as "place-and-route" tools. Design tools used may 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 logic functions, such as combinatorial logic, must be implemented in logic blocks using mapping algorithms. The user can generally choose a mapping for optimal density or optimal performance.
Placement tasks involve taking logic and I / O blocks from the mapping and assigning them to physical locations within the FPGA array. Current FPGA devices typically have three technologies; A combination of mincut, annealing simulation 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 among the overall net length or various variables of the interconnect. Xilinx XC4000 series FPGA devices use the parameters of the Mincut technology for initial deployment, caused by GFDR for improvement in deployment.
Routing tasks include determining the routing path used to interconnect the various mapped and placed blocks. Such a router, a so-called maze router, seeks the shortest path between two points. Routing operations provide direct interconnect among the chips, so the placement of the circuit associated with the chip is important.
Initially, the hardware model can 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, synthesizer server 360, such as Altera MAX + PLUSII programmable logic development tool 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, and is parameterized and often used logic module 362 ( For example, it has the ability to create a nonstandard multiplexer or nonstandard adder, and to synthesize any logic element 363 (eg, look-up table based logic that implements the ordered logic function). The synthesizer server eliminates 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 higher 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 circuit 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 generate any logic element based on a change in the standard logic element or any logic element that is not parallel to this 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 combinatorial 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 access, 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 function decomposition operation 359, a link to synthesizer server 360 is represented by arrow 366.

delete

delete

delete

delete

delete

delete

delete

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 place-and-route operation. First, a coarse-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. A 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 through 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 in 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.

delete

delete

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

The first term (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 (ie, C2 * D) makes a placement cost value based on the number of hops present between the various interconnect gates in the circuit CKTQ (ie, CKT1, 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 overall placement cost value resulting 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 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 sequential iteration, the system selects smaller values of C0 and C1 compared to C2. 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 cost function F (P, G, D) equation (i.e. C0 * P) of _{claim 1} , a P _used / P _available ratio is calculated for each FPGA chip. Therefore, for a 4x4 array of FPGA chips, the P _used / P _available ratio is 16. 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 placement 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 factors are equal. Lose. 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 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, infinity) 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. Thus, 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 this term depends on the specific maximum ratio and the calculated ratio G _used / G _available among the calculated ratios for each FPGA chip, the placement cost value is higher for higher gate usage, and the other factors will be equal. 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), the second term (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 circuit implementation). As a result, the system does not modify C1, and the second term (C1 * G) will determine the particular number.

Clause 3 (C2 * D) represents the number of hops between all gates requiring interconnection. The number of hops also depends on the interconnect matrix. The connection matrix provides 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 the division of the cluster into specific chips, 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, each interconnection between chips, such as interconnect 602 between chip F11 and chip F14, represents a 44 pin or 44 wire line. In other embodiments, each interconnect represents at least 44 pins. In other embodiments, each interconnect represents less than 44 pins.

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 data can pass within two hops through either interconnect 600, 606 or interconnects 603, 610. Pass from chip F11 to chip F33. 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 matrix 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.

The third term (ie, C2 * D) is expressed in the long form as follows.

The term 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 gates i and j that require internal chip interconnect, 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 checked. More specifically

The matrix is set up with every chip in the array so that each chip is numbered identifiably. This confirmation number is set on top of the matrix as a column header. Similarly, this confirmation number is set 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. The exponent k represents the number of hops needed to interconnect any gate in chip j and any gate in chip i requiring interconnection.

First, the connection matrix Mij for k = 1 must be checked. If the entry is "1", the direct connection is at the selected gate in chip j for this gate in chip i. Therefore, the exponent 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 examined. However, if the entry is "0", there is no direct connection.
If no direct connection exists, then k must be checked. This new k (ie k = 2) can be calculated by multiplying itself with the matrix Mij; 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 the 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 access 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 matrices 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} logically contains the FPGA chip for gate j and _{ml, j} ANDed on the column. The individually ANDed components are ORed to determine if the Mij value for the exponent or hop k is "1" or "0". If the result is "1", there is a connection, and the index k is specified as the number of hops. If the result is "0", then no connection exists.

delete

delete

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 interconnection 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. Other parts of the circuit 1090 are not shown for educational purposes. The connection between the OR gate 1091 and the AND gate 1092 is located in different chips and therefore requires interconnection, so a set of interconnects 1097 is used. The number of hops for this interconnect is "1". Access 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 requires interconnects because they are located on different chips, so a set of interconnects 1097 is used. The number of hops for this interconnect is "1". The connection between the OR gate 1091 and the AND gate 1093 requires an interconnect and a set of interconnects 1097 is used. The number of hops is also "1". For this arrangement, 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. Thus, on the basis of the distance D parameter, assuming that the other factors are the same, the cost function calculates the cost function more for the arrangement example of FIG. 35 (D) than for the arrangement example of FIG. 35C. However, all other factors are not the same. More similarly, the cost function of FIG. 35D is based on the gate usage / availability G. 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 example arrangement shown in FIG. 35 (C) is greater than the pin usage / availability for the same chip in the other example arrangement shown in FIG. 35 (D). .
After coarse-grain placement, fine control of the flattened 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 split if it increases the optimization of the placement. For example, assume that logic elements X and Y are the original part of cluster A and designated 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 designated for placement of the FPGA chip 2. Thus, an FPGA netlist 354 is created that binds the user's circuit design for a particular FPGA.
Determination of the cluster partitioning 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 micro-grain batch process is the same as the cost function used for the coarse-grain batch process. The difference between only two batch processes is not the process itself, but the size of the clusters to be placed. Coarse-grain batch processing uses larger clusters than fine-grain batch processing. In other embodiments, the cost functions for coarse-grain and fine-grain batch processing differ from each other as described above with respect to selecting weighting constants C0, C1 and C2.

delete

delete

delete

When the deployment is complete, routing tasks 355 between the chips are 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 run, then a particular time division multiplex circuit may 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, routing tasks can always be completed because the pins are arranged in time division multiplexes between the chips.
Once the placement and routing of each FPGA is determined, each FPGA is configured with optimized working circuitry, so the system generates a "bitstream" configuration file 356. In Altera technology, 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 MAX + PLUS II programmers use 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 terminates the automatic structure of the hardware model on the reconfigurable board.
Referring back to the TDM circuit, which allows time-division multiplexing of the pin output groups 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 operation can always be terminated because the pins can be divided in time-division multiplex form on the chip.

delete

delete

delete

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 skilled 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 requires time division multiplexing to require only one interconnect between these chips 990 and 991. Provide at least two interconnections.

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. In circuit 960 these wires 966 and 967 are outputs. 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 a chip assigned to one pin and accessed to another chip 990. One set of inputs 966 and 967 to AND gates 961 and 962 are provided by circuit model 960, respectively. The other set of inputs 968 and 969 are provided by loop register means which serve as time division multiplex select signals.

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 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 is output from wire 966 or circuit 960 on wire 967.

One embodiment of the receiving side of the TDM circuit is shown in Fig. 9C. The signals from circuit 960 on wires 966 and 967 in chip 991 (FIGS. 9A and 9B) are suitable wires 985 or 986 for circuits 953 in FIG. 9C. Must be combined). 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 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 "selects" the signal on wire 979 or 980. Thus, data on wire 978 from circuit 960 can be appropriately coupled to circuit 973 via wire 985 or 986.
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 FPGA space within the FPGA chip and software / hardware boundaries of the banks 326a-326d of the FPGA chip due to bandwidth limitations of the 32-bit PCI bus (ie, REG, S2H, Selectively control data transfer between 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 a 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 the software / hardware boundary by using the SPACE index. 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 within each FPGA chip and the address space within the software / hardware boundary depends on the memory / word capacity of the selected FPGA chip. For example, one embodiment of the present invention uses the Altera 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 accommodate approximately 100 words.

delete

delete

The SEmulation system is characterized by allowing the user to start and end, generate input values, and check the values 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, coupling components are modeled and 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 coupling component is more difficult to determine. In FPGAs, most coupling components are modeled as lookup tables to increase gate utilization. As a result, lookup table mapping provides effective hardware modeling but compromises the visibility of most combinatorial logic signals.

Despite these problems due to lack of visibility of the coupling components, the SEmulation system can reinforce or regenerate the coupling components for inspection by the user after hardware acceleration mode. If your circuit design only has coupling and register components, the values of all coupling components can be derived from the register component. That is, the coupling component is comprised from and includes various registers according to 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, combined component regeneration is not 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 coupling component value every cycle (or even most cycles) further reduces the simulation speed. In any event, checking of register values alone should be sufficient for most simulation analysis.

The process of regenerating the combined component values from the register values ensures that the SEmulation system is in hardware acceleration mode or ICE mode. Otherwise, the software simulation provides the user with the combined component value. The SEmulation system maintains the combined component values as well as the register values 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. Because the software model has a combined component value and a register value from the time period just before the start of hardware acceleration, the combined component regeneration process includes updating some or all values of the software model in response to the updated input register value.

The combined component generation process is as follows: First, if required by the user, the software kernel reads all output values of the hardware register components from the FPGA chip into the REG buffer. This process involves DMA transfer of register values in the FPGA chip into the REG address space through a chain of address pointers. Placing register values in the hardware model into the REG buffer within 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 the regenerated coupling component, these values can be read from a software model with the coupling component value 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 in accordance with the changed register values may change the values. These coupling components 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 a fan-out coupling component to the event queue. Here, a register whose value changes during acceleration detects an event. More similarly, these coupling components according to these changed register values will produce different values. Despite any change in the value of these coupling components, the system ensures that these coupling components evaluate these changed register values in the next step.

Fourth, the software kernel then executes a standard event simulation algorithm to convey the value change from the register to all of the combined components of the software model. In other words, the register values that changed during the post-acceleration time interval before acceleration are passed to all underlying coupling components that depend on these register values. These coupling components then evaluate these new register values. In accordance with the fan-out and propagation principle, another second level coupling component placed below from the first level coupling component that in turn directly depends on the changed register value must evaluate the changed data. This progression of register values to other components placed below that may be affected contributes to the purpose of the fan-out network. Thus, these coupling components placed below and affected by the changed register values are updated in the software model. None of the binding component values are affected. Thus, if only one register value changed during the time interval after acceleration and before acceleration, and only one coupling component is affected by this register value change, then only this coupling component will re-evaluate the value based on this changed register value. . Other parts of the modeled circuit will not be affected. For this small change, the combined component regeneration process will occur relatively quickly.
Finally, when the event progression ends, the system is ready for any mode of operation. In general, you want to check the value after a long run. After the combined component regeneration process, the user continues the pure software simulation 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, coupling component regeneration involves using register values to update coupling component values in a software model. When any register value changes, the changed register value will proceed 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 recreate the coupling component. In general, hardware accelerated operation will occur for several hours. As a result, many register values change, affecting the values of many coupling components placed under the fan-out network of those registers with the changed values. In this case, the combined component regeneration process can 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.

delete

delete

Ⅳ. 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 operates in an in-circuit emulation mode. As noted above, the SEmulation system includes a general purpose microprocessor and a reconfigurable hardware board interconnected by a high speed bus such as a PCI bus. The SEmulation system compiles the user circuit design and generates emulation hardware configuration data during the hardware model to reconfigurable board mapping process. The user then simulates the circuit through a general-purpose processor, hardware accelerates the simulation process, emulates the circuit design with 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. Emulation interface 382 and target system 387 are provided to the system during the in-circuit emulation mode. Under the user's separation, 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 the hardware model; 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) within the software / hardware boundary, bank of banks 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 the software model 315 and the hardware model 325. 321, 322, 323 and 324).

Double buffering is required for all primary inputs to the S2H and CLK spaces because 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 primary inputs from the kernel to the hardware model. As noted above, the hardware model substantially holds both the coupling component and the register component 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 components, and evaluates clock components. When any clock edge is detected by the kernel, registers and memory are updated and the values are passed through the coupling component. Thus, any change in values in these spaces triggers the hardware model to change the logic state if the hardware acceleration mode is selected.
During the inner-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 provides interface ports 385, emulation I / O control 386, target-to-hardware I / O buffers (T2H) 384, and hardware-to-target I / O buffers (H2T) 383. Include.
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.
Kernel 316 of software model 315 controls the internal-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 times will occur during the in-circuit emulation mode. Thus, the user can start, stop, single step, generate values, and check values at any time during the in-circuit emulation process.

delete

delete

delete

delete

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 from another form of software generated clock or test bench process, so that the software kernel detects the active clock edge and thus triggers the 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 behavior in 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 inner-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 process in the software model 315 to evaluate the data. Since the target system runs generally faster than the speed of the software simulation, the internal-circuit emulation mode will run at a higher rate. 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 through 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. In this setup, there will be no cable 390. The signal between the target system 387 and the hardware model 325 will still pass through the emulation interface.

delete

delete

delete

Ⅴ. 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 so that the user can review the various inputs and the 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 a 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 first recorded point 600 and simulates 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 may 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 to the hardware model to calculate a value change dump (VCD) 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 (VCD) method can link to any simulation waveform viewer for post simulation analysis.

VCD system on demand

One embodiment of the invention is a system for creating a custom VCD without a simulation return. According to one embodiment of the present invention, a custom VCD technique as described herein incorporates 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 ranges and design overviews without simulation returns. 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 primary 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 selected simulation time range does not contain bugs that the user wishes to correct, the user can select another simulation time range to dump to the VCD file. The user can then analyze these new VCD files. Due to this on-demand VCD feature, the user stops the simulation at any point and requires the creation of another optional VCD file on demand from any desired simulation time start point.

In a typical debug session, a user debugs his design using the RCC system shown in FIG. During the first simulation, the user quickly simulates his design at any desired 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 primary 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 exit points in the "simulation history" file so that the user can return these exit points to debugging past designs if desired.

At the end of a quick 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 the exact location of the simulation target range to isolate the bug, the RCC system decompresses the compressed primary input in the input history file and passes the uncompressed primary input to the hardware model for evaluation. Simulate quickly from the start. When the RCC system reaches the simulation target range, it dumps the results (e.g., hardware node values and register status) evaluated in the VCD file. The user can then analyze this area more carefully by replaying his design with the VCD file starting at the beginning of the simulation target range, or even immediately after the start of the simulation, rather than returning the simulation from the beginning of the simulation session range. have. This feature of storing hardware state as a VCD file in the simulation target range saves a significant amount of debugging time wasted during the simulation return.

Referring back to FIG. 83, a high level RCC system incorporating one embodiment of the present invention is shown. The RCC system includes an RCC computing system 2600 and an RCC hardware accelerator 2620. As described elsewhere in this patent specification, the RCC calculation system 2600 includes computing resources needed to allow a user to simulate a 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 computing system 2600 may include a CPU 2601, various clocks 2602 required by various components of the RCC system (including the software clocks described in various patent specifications), test bench processes 2603, and 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 computing system 2600 includes bus subsystems and other logic components that provide computing power to circuit designers to execute various on-the-job diagnostics, various software, and management files that the computing system performs.

In another session of this patent document, an RCC hardware accelerator 2620, called an RCC array, is a logic element of a reconfigurable array (e.g., FPGA) that allows a user to model at least a portion of a user's design in hardware to accelerate the debugging process. ). For this purpose, RCC hardware accelerator 2620 includes an array of reconfigurable logic elements 2621 that provide a hardware model of the user-designed portion. The RCC computing system 2600 is tightly coupled to the RCC hardware accelerator 2620 via a software clock and bus system as described elsewhere herein, and portions of the bus are shown as lines 2610 and 2611 in FIG. 83. do.

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 corrected 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 specific bugs are deployed and corrected 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 movement 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 out during the current simulation session scope, the user will simulate the design beyond the simulation time t3 to the next simulation session scope.

In this summary 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. In fact, 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. 83. 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 primary input and some form of recording of the compressed primary input. Second, the VCD generation operation of the RCC system will be discussed. This VCD generation operation involves decompressing the primary 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, a user models a software design in the RCC computing system 2600 of FIG. 83. For some portions of the design, RCC computing 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 within the RCC computing 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 finished his final circuit design. This is the time to debug the design to find defects. If the user has debugged a previous version of the design beforehand, he thinks of some places where the bug is placed. On the other hand, if this is the first debug session for a new design, the user should have some idea about the location of potential bugs. In either case, some guesswork is usually required to place the bug. For this discussion, assume that you are debugging your design for the first time.

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. Clearly, 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 iterative tasks that will slow down the debugging process. 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 implement 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 mentioned above, the separation of 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 the RCC computing system 2600. Fast simulation is performed at simulation time t0 to simulation time t3 instead of the normal simulation mode because regeneration of the software model is not needed during this time period. As discussed elsewhere in this patent specification, regeneration operations require the RCC computing system 2620 to receive hardware state information (e.g., node values, register state), thereby providing more intelligent logic elements (e.g., For example, the joining 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 computing 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 computing system 2600 to regenerate the software model from the primary 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 t0 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 computing system 2600 applies two distinct processes to the primary input I _P in parallel. Raw primary input from test bench process 2603 is provided in line 2610 for RCC hardware accelerator 2620 for evaluation. At the same time, the same primary 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 primary input can be collected for the user to play back any part of the simulation later. Can be. In particular, the primary input corresponding to the simulation time t0 to the simulation time t3 is compressed and stored in the system disk.

When the RCC hardware accelerator 2620 receives the primary input I _P from the test bench process 2603, the accelerator processes the primary input. As a result, the hardware state of the hardware model will change when various logic and other circuit elements evaluate the data. During a time period from simulation time t0 to simulation time t3, the RCC system does not have to wait for the RCC computing 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 primary outputs (eg hardware node values and register states) at all. Note that the RCC hardware accelerator 2620 does not evaluate low and uncompressed primary input while the RCC computing system 2600 compresses the primary input for writing to an "input history" file. In another embodiment, the RCC system does not compress the primary input to write to the input history file.

Why does the RCC computing system 2600 pass the primary 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 primary input from the start of the simulation to 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 primary 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 primary input from the simulation time t3 (or the simulation time just before the simulation time t3) is fed 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. In order to move quickly from one simulation session to the next, the RCC system saves the hardware state (with compressed primary 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 then 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 primary 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 computing system 2600 so that the RCC computing system 2600 can be configured with various logic of the software model if needed and targeted by the user. An element (eg, coupling logic) can be formed or regenerated. However, as noted above, the user is not interested in 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 primary output (eg, register value) from the design hardware model in RCC hardware accelerator 2620 corresponding to 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 have 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 primary input on the system disk for future reference, while simultaneously exiting from the test bench process 2603 on line 2610. Accelerate the design by supplying the primary input of to the RCC hardware accelerator 2620. The RCC computing system 2600 requires storing primary input (compressed or uncompressed) in the input history file to replay the debug session. Compression operation occurs concurrently with data evaluation in 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 primary 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 on-demand VCD type information can be stored in a compressed primary input file and a distinct VCD file in a system disk separate from the hardware state information file at simulation time t3. In other words, according to an embodiment of the present invention, the input history file, the simulation history file, and the VCD file may 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 merged 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 primary input event with 10% input events per simulation time step. Thus, large ASIC designs of more than one million gates may require 200 primary 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 primary input per simulation time step. For a compression rate of 20X, 40 byte data can be compressed to 2 bytes of data per simulation time step. Thus, for a design requiring about one million simulation steps, the RCC system compresses the primary input with two megabytes of data. Files of this size can be easily managed by any computing file system and waveform viewer. In one embodiment, ZIP compression is used.

According to one embodiment, primary input compression is performed concurrently with the primary input evaluation by the RCC hardware accelerator 2620; Input story file generation occurs concurrently with the primary input evaluation. Thus, the compression method does not provide a direct adverse effect on RCC system performance. One possible bottleneck is the process of writing compressed primary input to the system disk. However, because the data is highly compressed, the RCC system experiences less than 5% deceleration for most designs running 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>);

Now, the argument names, <disk space>, and <checkpoint control> will be described. 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 offline on-demand VCD type debugging.

The <disk space> argument is an optional parameter to indicate the maximum disk space (in MB units) allocated for the RCC system write process. 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 140 MB, the RCC system writes only the last 100 MB and discards the first 40 MB of the compressed primary 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 faults 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 the full state checkpoint. The default is 1,000,000 times. As with most conventional compression algorithms, the compressed primary input is based on state differences between successive simulation steps. During long simulation runs, a checkpoint on the overall RCC state at a given low frequency may facilitate simulation history extraction. For decompression rates of 20K to 200K simulation time steps per second in RCC systems and checkpoints deployed in every million steps, the RCC system extracts any simulation history within 5 to 50 seconds (i.e., primary input and selected VCD). Simulation playback from 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 primary input for storage of the system disk. The primary input from the RCC hardware accelerator is ignored because software logic regeneration is not needed at this point. The write process can be terminated with the $ rcc (stop) or $ rcc (off) command, at which point the RCC system switches the control of the simulation back to the software model. At this point, the primary 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 compressed primary input 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 primary input, the user can software simulate any part of his design. However, due to the features of the custom VCD, the user will 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 correct bugs. Indeed, due to the compressed primary input recorded, the RCC system can reproduce 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 a quick simulation of the design, the user reviews the results to determine if a bug exists. If a bug does not appear to the user, the design may be free of bugs 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 he or she has some kind of problem in the design, the user must analyze the simulation more carefully to isolate and correct 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 a simulation target range exists between simulation time t1 and 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 computing 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 computing system loads a previously stored file containing the compressed primary input. The RCC computing system decompresses the compressed primary input and inputs the decompressed primary input to the RCC hardware accelerator 2620 for evaluation. As with the initial high speed simulation operation where the primary input is compressed and stored over the simulation session range, the primary output (e.g., hardware model node value and register state) that is evaluated is the simulation time (t0) from the simulation time (t0). It is not stored during the high speed simulation to t1).

Once a high speed when the simulation operation has reached the introduction, that is, the simulation time (t1) of the simulated target range, RCC system, the evaluation results (that is, the first output (O _p)), the system from the hardware model in 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 computing system 2600 does not perform any compression. Again, the RCC computing system 2600 does not perform a regeneration operation on the software model because the user does not need to see the evaluation results at this time. By not performing any regeneration 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 the simulation time period from t1 to t2 while saving the primary output. If so, the RCC computing system 2600 performs a software model regeneration operation to allow the user to see any and all states from any form of user design.

At simulation time t2, RCC computing system 2600 stops storing the evaluation output from RCC hardware accelerator 2620 as a VCD file. At this point, the user can stop the 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 have to rerun the simulation from the start (eg, simulation time t0). Instead, the user can instruct the RCC system to load the stored hardware state information from the start of the simulation target range and view the simulated results with the software model. This will be described in more detail in the Simulation History Review section below.

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 simulation target range that he suspects has a bug. The user must use the same process used above for the decompression and VCD file dump. The user may hopefully make another conjecture that there is a better simulation target range within the simulation session range. In doing so, the RCC system performs a high speed simulation from the start of the simulation session range to the new simulation target range, decompresses the primary 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 primary 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 performs high-speed simulation by decompressing previously compressed primary inputs and passing them to a hardware model for evaluation. During the simulation target range from simulation time t1 to simulation time t2, the RCC system dumps the primary 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 the simulation target range ends and the bug is quarantined and removed, the user can proceed to the next simulation session range. This new simulation session range starts at simulation time t3. A new simulation target range of a certain length, 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 primary 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 (i.e. play the selected VCD file from the primary playback) within 50 seconds.

For the particular way in which the custom VCD characteristics are 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 simulation session scope; 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 6000000
Interrupt at simulation time 60000.0000ns

C6> $ axis_rpd;

Available simulation history:

1005.000000 to 50000.000000

50505.000000 to 60000.000000

Interrupt at simulation time 60000.0000ns

From this simulation log, 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 create a VCD file from the simulation history, you use the $ axis_rpd command with the following control arguments:

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

The start-time and end-time define the simulation time window for the VCD file, i.e. 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 scope 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.010000 !!

… RCC VCD exit at 50600.000000 !!

Interrupt at simulation time 60000.0000ns

This $ axis_rpd command generates a VCD file called "fl.dump" for the simulation target range from simulation time 50505 to 50600. If $ level and scope control> parameters are not provided, such as $ dumpvars, the $ axis_rpd command will dump the entire hardware state or primary 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 !!

… Skip from time 50000.000000

… Keep on time 50505.000000 !!                 

… RCC VCD exit at 50600.000000 !!

Interrupt at simulation time 60000.0000ns

This $ axis_rpd command creates a two-level VCD file "f2.dump" on the range dp0 in time 40000 to 50600. 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.

Custom VCDs are also useful after the user has finished the simulation process. To perform an off-line on-demand VCD, 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 custom VCD. An example of this procedure is as follows:

axis15: 3-dpo_rtlc> vlg + rccplay + rl -s

… Record playback 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 this example, a simulation record ("rl") is used to extract the simulation history and generate a VCD over the entire design at times 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, ie the beginning of the simulation time t1. Therefore, in contrast to the prior art, the user does not need to return a simulation from its start (eg, simulation time t0). The hardware state dumped into the VCD file reflects an estimate of the overall history of the primary input from simulation time t0 and includes the primary input from simulation time t1 to t2.

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

With this custom VCD feature, the user can 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 primary inputs from the test bench process can be recorded for the entire simulation session 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 corrects bugs within the scope of this simulation session.

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

Off-line support is possible because the entire primary input for the simulation session range at simulation time t0 and the hardware state at simulation time t1 are all stored in the system disk. Therefore, the user can load the design corresponding to the simulation time t0 and then return to debug his design by 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 means

A. Overview

The SEmulation system implements an array of FPGA chips on a reconfigurable board. Based on the hardware model, the SEmulation system divides, maps, places 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 the large circuitry deployed for 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). Any combination of address pointers associated with a particular address space can be chained together. Thus, during data transfer, the word data in each chip is from the main FPGA bus and the PCI bus to / from the PCI bus until one word at a time and the desired word data are accessed for that selected address space for each chip selected address space. One chip is selected sequentially at a time. This sequential selection of word data is achieved by 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, including more FPGA chips or piggyback boards that extend the bank 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 can be called a word select signal. When this word select signal reaches the output of the last flip-flop in this address pointer, it is called with the OUT signal to be propagated 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 exponential control signals from the FPGA I / O controller. Since all operations are essentially read or write, the SPACE exponential 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. As 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. FIG. 12 shows a state transition diagram of address pointer initialization for the address pointer of FIG. Initially, state 460 is in an idle state. 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_XSFR becomes "0", the address pointer initialization procedure ends and the system returns to sleep 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, while 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. Wire line 461 is "1", while the remaining wire lines 460, 462, and 463 are "0". Thus, wire line 466 is "1" while the remaining output wire lines 464, 465, 467 and 468 are "0". Similarly, if wire line 460 is "1", the REGR-move signal or wire line 465 on wire line 464, depending on whether the REG space is selected and whether the read (F_RD) or write (F_WR) operation is selected. One of the REGW-move signals on the phase will be "1".

As mentioned above, the SPACE index is generated 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 record pointer: REGW-move = (SPACE-index == # REG) &WRITE;

S2H Spatial Read Pointer: S2H-move = (SPACE-index == # S2H) &READ;

H2S space write pointer: H2S-move = (SPACE-index == # H2S) &WRITE;

CLK space write pointer: CLK-move = (SPACE-index == # CLK) &WRITE;

This is the equivalent 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 for the two 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, an address pointer associated with a particular address space within one FPGA chip is associated with the same address space within the next FPGA chip. It is still used, except that it is "coupled" to the address pointer.

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, with four input pins and four output pins on each chip. One embodiment according to the invention is a multiplexed crossover where 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 a chip address pointer chain. One embodiment of a multiplexed cross chip address pointer chain is shown in FIG. 14.

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, e.g., address pointer 427, except that the number of words (Wn) and the number of flip-flops may vary depending on how many words are to be implemented on each chip for a user-customized circuit design. It has a structure and a function similar to 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 the multiplexer 487; That is, both the OUT and MOVE signals (derived from the SPACE exponent signal) must appear active (eg, 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 (eg, wire line 413 in the address pointer shown in FIG. 11) for an address pointer associated with a particular address space, and (2) It includes a 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 and transferred to the appropriate resource at a time.

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 still the next FPGA. The chip 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 sum, 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 for all FPGA chips in this reconfigurable hardware board.

C. Gate / Data 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 evaluation 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 SEmulation 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 components, in particular derived clocks. Clock transfer timing issues arise 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 component. The software clock is free of race conditions and 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 SEmulation system will model this into hardware to maintain the performance of the SEmulation 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 combinational 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 components of the SEmulation system. This one-to-one mapping of user registers to SEmulation 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 codes, the SEmulation register can be easily used at high speed because the RTL level code is at a sufficiently high level to allow further lower level implementations to vary. For the gate level netlist, the SEmulation system will access the cell library of the component and modify it to suit a particular circuit design-specific logic element.

Step 502 extracts the clock signal from the register component of the hardware model. This step allows the system to determine the first clock and the derived clock. These steps also determine all the clock signals needed by the various components 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 component 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 SEmulation 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 components to generate this derived clock is small, so that such coupling components 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, a user's circuit design uses a significant number of derived clock components 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 first clocks 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 component from the first clock to the clock derived. In other words, this step traces the clock signal data path from the first clock through the coupling component. Step 506 determines a fan-in coupling component from the derived clock. That is, this step traces the clock signal data path from the coupling component 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 combinational 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 the 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 components that drive net N. For each component X driving net N, the system determines whether component X is a combined component or not. If each component X is not a combined component, the fan-in set of net N has no combined component and net N is the first clock.

However, if at least one component X is a combined component, the system determines the input net Y of component X. Here, the system considers the circuit design by finding the input node to component X. For each input net Y of each component X, there may be a fan-in set W coupled to net Y. This fan-in set W of net Y is added to the fan-in set of net N, and then component 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, the 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 the clock output node for determining the gated data logic from the fan-out perspective. Therefore, all logic 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 a 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 components that use net N. For each component X using net N, the system determines whether component X is a combined component or not. If each component X is not a combined component, the net-out set of net N has no combined component and net N is the first clock.

However, if at least one component X is a combined component, the system determines the output net Y of component X. Here, the system considers the circuit design by finding the output node from component X. For each output net Y from each component X, there may be a fan-out set W coupled to net Y. This fan-out set W of net Y is added to the fan-out set of net N, and then component 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 components.

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 coupling logic. The gated data logic is the intersection of the fan-in of the gated data and the fan-out from the first clock. Therefore, clock analysis and gated data analysis generate gated clock network / logic and gated data logic through some combining logic. As discussed below, gated clock network and gated data network decisions are important for the logic evaluation in the hardware model and successful implementation of the software clock during emulation. Clock / data network analysis ends at step 508.

17 illustrates basic building blocks of a hardware model according to an embodiment of the present invention. For the register component, the SEmulation 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 detection (i.e. latch) register hardware models. . This register model, which forms a 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 SEmulation register model is triggered by the positive level of the asynchronous enable (A_E) input or by the positive edge of the system clock. When either of these two positive edges or positive level triggering events occur, 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 no asynchronous enable (A_E) input or synchronous enable (S_E) input is 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 SEmulation 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 components. The hardware model of the SE emulator system uses only registers and coupling components. The SE emulator system also controls the evaluation of the hardware model through the software clock. In a SEmulation system, the hardware model for registers does not have a clock directly connected to other hardware components; Rather, the software kernel controls all clock values. By controlling several clock signals, the kernel has full control over the evaluation of the hardware model with negligible amounts of co-processor intervention overhead.

Depending on whether the register model is used as a latch or flip-flop, the software clock may be an input to either an asynchronous enable (A_E) or synchronous enable (S_E) wire line. The application of the software clock from the software model to the hardware model is triggered by edge detection of the clock component. When the software kernel detects an edge of a clock component, it sets a 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 implementations of the formation 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 latch, asynchronous ports A_E and A_D and synchronous 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 with the asynchronous enable A_E and the data input is provided with the asynchronous data A_D input. For I / O operations, the software kernel uses synchronous enable (S_E) and synchronous data (S_D) inputs to download values into the Q port. The S_E port is used as a REG spatial 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 in a flip-flop design. The flip-flop design uses the following ports: data D, set S, reset R, and enable E to determine the next state logic. All next state logic in the flip-flop design is factored into a hardware coupled component that is 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 hold-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. The gated 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 the 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. Similarly, 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 register logic and register logic that is in turn driven by the first clock. By default, the SEmulation 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 components to generate such an induction clock is small, so no I / O overhead is added by modeling these coupling components in software. However, if the number of derived clocks is large (eg, 10 or more), these derived clocks and their combined components 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 SEmulation 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 component rather than the clock input to the hardware register component. 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 SEmulation 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 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 second buffer 512 on wire line 523 is ultimately gated data logic 513 to drive the input of register 518 through wire line 530 in the user-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 the wire line 524 is set to logic “1”. The clock signal on wire line 525 is derived from gate clock logic 514 and ultimately from first clock register 510 at the output on wire line 522 of first buffer 511. The clock signal on wire line 525 is a gate clock signal. The enable wire line 526 for the first buffer 516 is an ~ EVAL signal from the state machine that controls the I / O and evaluation cycles (hereinafter initiated). The first buffer 516 also has a RESET signal on the wire line 527. The same RESET signal is provided to a second buffer 517 in clock edge register 515. The output Q of the first buffer 516 on the wire line 529 is provided to the input D to the second buffer 517. The second buffer 517 also has a CLK-EN signal on wire line 527 and an enable input on wire line 528 for a RESET input. The output Q of the second buffer 517 on the wire line 532 is provided to the enable input of the register 518 in the user-designed circuit model of the user. The buffers 511, 512, 517 along with the register 518 are clocked by the system clock. Only buffer 516 in clock edge register 515 is clocked by gate clock from gate clock logic 514.
Register 518 is a conventional D-type register model that is modeled in hardware and is part of the user's custom circuit design. Evaluation is strictly controlled by this embodiment of the clock implementation means of the present invention. The ultimate goal of this clock-setup is to provide a wire line to register 518 prior to the data signal on wire line 530 so that data signal evaluation by registers can be synchronized using the system clock and without race conditions. Allow the clock enable signal to arrive at 532.
For repetition, the first clock register 510 to be modeled is modeled in software but its double buffer execution is modeled in both software and hardware. Clock edge register 515 is implemented in hardware. From fan-in and fan-out analysis, the gate data logic 513 and gate clock logic 514 are separated for modeling purposes and can be software (if the number of gate data and gate clocks are small) or hardware (gate data and gate clocks). In the case of large number). Gate clock network and gate data network decisions are important for the logic evaluation in the hardware model and the successful performance of the software clock during the hardware acceleration mode.
The software clock execution mainly follows the clock setting shown in FIG. 19 along with the timing of assertion of the ~ EVAL, INPUT-EN, RESET signals. The first clock register 510 detects a clock edge for triggering software clock generation for the hardware model. The clock edge detection event is generated by a clock input on wire line 525, gate clock logic 514, and clock edge register 515 through wire line 522 such that clock edge register 151 detects the same clock edge. Triggers "activation". In this case, the clock detection that occurs in software (via inputs 519 and 520 in the first clock register 510) passes from the clock edge detection in hardware (via the input 525 to the clock edge register 515). Can be. At this time, the IMPUT-EN wire line 533 to the second buffer 512 in the first clock register 510 and the CLKEN wire line 528 to the second buffer 517 in the clock edge register 515 appear. No data evaluation is done. Thus, the clock edge is detected before the data is evaluated in the hardware register model. Note that in this step, data from the data bus on wire line 519 is propagated into hardware-modeled user register 518 rather than out of gate data logic 513. In practice, the data does not reach the second buffer 512 in the first clock register 510 because the INPUT-EN signal on the wire line 533 has not yet appeared.
During the I / O phase, the ~ EVAL signal on wire line 526 is generated to enable first buffer 516 in clock edge register 515. The ~ EVAL signal monitors the gate clock signal by allowing the gate clock logic to pass through the gate clock logic 514 to the clock input on the wire line 525 of the first buffer 516. Thus, as will be described below with respect to a four-state evaluation state machine, the ~ EVAL signal may be maintained as long as it is required to stabilize the data and clock signals through the system portion shown in FIG.
When the signal stabilizes, ~ EVAL is reduced to disable the first buffer 516 when the I / O is terminated or the system prepares for data evaluation. The CLK-EN signal is generated and applied to the second buffer 517 via wire line 528 to enable the second buffer 517 and on the wire line 532 at the enable input to the register 518. Send a logic " 1 " value on wire line 529 to output Q. Register 518 is enabled and any data present in wire line 530 is synchronously clocked into register 518 by the system clock. As the reader is observable, the enable signal to register 518 is faster than the evaluation of the data signal to register 518.
The IMPUT-EN signal on wire line 533 does not appear in the second buffer 512. RESET edge register signals on wire line 527 also appear in buffers 5156 and 517 in clock edge register 515 to reset these buffers and cause their output to be logic " 0 &quot;. The INPUT-EN signal appears for buffer 512 and the data on wire line 521 is propagated to gate data logic 513 for user circuit register 518 on wire line 530. Since the enable input to the register 518 is a logic " 0 &quot;, the data on the wire line 530 cannot be clocked in the register 518. However, the previous data is clocked by the enable signal already generated on wire line 532 before the RESET signal is already generated to disable register 518. Thus, input data to register 518 as well as inputs to other registers that are part of the user hardware model circuit design are stabilized at their respective register input ports. If the clock edge is later detected in software, the first clock register 510 and the clock edge register 515 in hardware clock the data wait at the input of register 518 and the wait for data at their respective register inputs. To enable the enable signal to register 518 to be synchronized by the system clock.
As described above, software clock execution mainly follows the clock setting shown in FIG. 19 along with the timing of generation of the ~ EVAL, INPUT-EN, CLK-EN, RESET signals. 20 illustrates a four state finite state machine for controlling the software clock logic of FIG. 19 in accordance with an embodiment of the present invention.
In state 510, the system is idle or some I / O operation is in progress. The ~ EVAL signal is logic "0". The ~ EVAL signal determines the evaluation cycle and is generated by the system controller and sustains many of the clock cycles required to stabilize the logic in the system. Typically, the ~ EVAL signal period is determined by the placement means during compilation and is based on the length of the longest straight wire and the length of the longest segment multiplex wire (ie, TDM circuit). During evaluation, the ~ EVAL signal is logic "1".
In state 541, the clock is enabled. The CLK-EN signal is generated at logic " 1 " and an enable signal for the hardware register model is generated. However, previously gated data in the hardware register model is evaluated synchronously without the risk of maintenance-time violations.
In state 542, new data is enabled when the INPUT-EN signal is generated at logic " 1. " The RESET signal is generated to move the enable signal from the hardware register model. However, new data enabled through the gate logic network to the hardware register model is waited to be clocked into the hardware register model when propagation continues or the enable signal is generated again for the intended hardware register model determination.
In state 543, new data propagation is stabilized in the logic while the EVAL signal is maintained at logic " 1. " The multiplexer-wires are at logic " 1 " as described above for the time division multiplex (TDM) circuits in connection with Figures 9 (A), 9 (B) and 9 (C). The ~ EVAL signal is set to Decrease or Logic " 0 " and the system returns to sleep state 540 and waits for software to evaluate upon detection of the clock edge.
D. FPGA Arrays and Controls
The SEmulator system initially compiles the user circuit design data into software and hardware models based on various controls including component types. During the hardware compilation process, as described above in FIG. 6, the system performs a mapping, placement, and routing process for the optimal partitioning, placement, and interconnection of the various components that make up the user circuit design. Using known programming tools, bitstream configuration files or programmer object files (.pof) (or, optionally, raw binary files (.rbf)) are referenced to reconfigure a hardware board containing many FPGA chips. Each chip contains part of a hardware model that corresponds to a user circuit design.
In one embodiment, the SEmulator system uses a total of 16 chips, 4 × 4 array of FPGA chips. Example FPGA chips include FPGA logic devices and Altera FLEX 10K devices from the Xilinx XC4000 series family.
The FPGAs of the Xilinx XC4000 series can be used, including the XC4000, XC4000A, XC4000D, XC4000H, XC4000E, XC4000EX, XC4000L, and XC4000XL. Specific FPGAs include Xilinx XC4005H, XC4025, and Xilinx 4028EX. Xilinx 4028EX FPGA engines reach 500,000 gates in a single PCI board capacity. Such Xilinx FPGAs can be found in detail in their databook, Xilinx, and programmable logic databook 9/96, which are incorporated herein by reference. Altera FPGAs can be found in detail in the databook, Altera, 1996 databook (June 1996), which is incorporated herein by reference.
A general brief description of the XC4025 FPGA is provided. Each array chip consists of a 240-pin Xilinx chip. The array board with the Xilinx XC4025 chip includes 440,000 configurable gates and can perform computationally-intensive tasks. Xilinx XC4025 FPGAs consist of 1024 deployable logic blocks (CLBs). Each CLB can implement 32-bit asynchronous SRAM or a small amount of common boolean logic, and two strobe registers. Around the chip, unstrobed I / O registers are provided. The XC4005H can be used instead of the XC4025. This is a relatively inexpensive version of the array board with 120,000 deployable gates. The XC4005H device has a high-power 24kW drive circuit but lacks the input / output flip-flop of the standard XC4000 series. These and other Xilinx FPGAs are available in detail through publicly available data sheets and can be incorporated by reference herein.
The functionality of the Xilinx XC4000 Series FPGAs can be customized by loading configuration data into internal memory cells. The values stored in these memory cells can determine the logic functions and interconnects of the FPGA. Configuration data of such FPGAs may be stored in on-chip memory and loaded from external memory. The FPGA can either read configuration data from an external serial or parallel PROM, or write configuration data from an external device to the FPGA. These FPGAs can be reprogrammed an unlimited number of times, especially if the hardware changes dynamically or if the user wants to adapt the hardware to other applications.
In general, XC4000 series FPGAs have up to 1024 CLBs. Each CLB has two levels of look-up tables, and two four-input look-up tables (or function generators F and G) are the third three-input look-up table (or function generator H), and 2 Four flip-flops or latches provide some input. The output of this look-up table can be driven separately from flip-flops or latches. The CLB may implement a combination of any of the following Boolean functions: (1) any function of four or five variables, (2) any function of four variables, and any second function of four uncorrelated variables And a third function of three uncorrelated variables, (3) one function of four variables and another function of six variables, (4) any function of four variables, and (5) several of nine variables function. Two D-type flip-flops or latches can be used to register the CLB input or to store the look-up table output. This flip-flop can be used separately from the look-up table. DIN can be used as a direct input to one of these two flip-flops or latches and H1 can drive another function generator through an H function generator.
Each 4-input function generator in CLB (i.e., F and G) contains dedicated arithmetic logic during fast generation to send or receive signals, and a 2-bit adder with "carry-in" and "carry-out". It can be configured to implement. Such function generators may also be implemented as read / write random access memory (RAM). Four-input wire lines are used as address lines for RAM.
Altera FLEX 10K chips are somewhat similar in concept. These chips are SRAM-based programmable logic devices (PLDs) with multiple 32-bit buses. Specifically, each FLEX 10K100 chip contains approximately 100,000 gates, 12 embedded array blocks (EABs), 624 logic array blocks (LABs), 8 logic elements (LEs) (or 4,992 LEs), 5,392 flip-flops or registers per LAB. , 406 I / O pins, and a total of 503 pins.
The Altera FLEX 10K chip includes an embedded array block (EAB) of an embedded array and a logic array block (LAB) of a logic array. EABs can be used to implement various memories (eg, RAM, ROM, FIFO), and complex logic functions (eg, digital signal processors (DSPs), microcontrollers, multipliers, data transformation functions, state machines). Depending on the memory function implementation, EAB provides 2048 bits. Depending on the logic function implementation, the EAB provides 100 to 600 gates.
With LE, the LAB can be used to implement medium sized logic blocks. Each LAB represents approximately 96 logic gates and includes 8 LEs and local interconnects. LE includes a four-input look-up table, a programmable flip-flop, and dedicated signal paths for carry and cascade functions. Typical logic functions that can be generated include counters, address decoders, or small state machines.
A more detailed description of the Altera FLEX10K chip can be found in Altera, 1996 databook (June 1996), and is incorporated herein by reference. The databook also includes details of supported programming software.
8 illustrates one embodiment of a 4x4 FPGA array and its interconnections.
Note that this embodiment of the SEmulator does not use crossbar or partial crossbar connections to the FPGA chip. The FPGA chips include chips F11 through F14 in the first row, chips F21 through F24 in the second row, chips F31 through F34 in the third row, and chips F41 through F44 in the fourth row. In one embodiment, each FPGA chip (eg chip F23) has the following pins to interface with the FPGA I / O controller of the SEmulator system:
interface pin Data bus 32 Space exponent 3 Reed, Light, Eval 3 Data XSFR One Address pointer chain 2 sum 41
Thus, in one embodiment, each FPGA chip uses only 41 pins to interface with the SEmulator system. These pins are further described in FIG. 22.
These FPGA chips are interconnected with each other through interconnects without or without crossbars. Each interconnect between chips, such as interconnect 602 between chip F11 and chip F14, represents a 44 pin or 44 wire. In another embodiment, each interconnect represents at least 44 pins. In another embodiment each interconnect represents less than 44 pins.
Each chip has six interconnects. For example, chip F11 has interconnects 600-605. Chip F33 also has interconnects 606-611. These interconnects run vertically along columns horizontally along rows. Each interconnect provides a direct connection between two chips along a row or between two chips along a column. Thus, for example, the interconnect 600 directly connects the chip F11 and the chip F13; Interconnect 601 directly connects chip F11 and chip F12; Interconnect 602 directly connects chip F11 and chip F14; The interconnect 603 directly connects the chip F11 and the chip F31; Interconnect 604 directly connects chip F11 and chip F21; The interconnect 605 directly connects the chip F11 and the chip F41.
Similarly, for a chip F33 not located at the edge of the array (eg chip F11), the interconnect 606 directly connects chip F33 and chip F13; Interconnect 607 directly connects chip F33 and chip F23; Interconnect 608 directly connects chip F33 and chip F34; Interconnect 609 directly connects chip F33 and chip F43; Interconnect 610 directly connects chip F33 and chip F31; The interconnect 611 directly connects the chip F33 and the chip F32.
Since chip F11 is located within one hop from chip F13, interconnect 600 'is referred to as "1". Since chip F11 is located within one hop from chip F12, interconnect 601 is referred to as "1". Similarly, because chip F11 is located within one hop from chip F14, interconnect 602 is referred to as "1". Likewise, all interconnections for chip F33 are referred to as "1".
This interconnect structure allows each chip to be connected with two "jumps" or other chips in an array within the interconnect. Thus, chip F11 is connected to chip F33 by either of the following two paths: (1) interconnect 600-interconnect 606; Or (2) interconnect 603 to interconnect 610. In short, the path may follow (1) first row followed by column, or (2) first column followed by a row.
Figure 8 shows an FPGA chip configured in a 4x4 array by horizontal and vertical interconnects, but the actual physical implementation on the substrate goes through the low and high banks to the extended piggyback substrate. Thus, in one embodiment chips F41-F44 and F21-F24 are in the low bank. Chips F31-F34 and F11-F14 are in the high bank. The piggyback substrate includes chips F11-F14 and chips F21-F24. Thus, a piggyback substrate containing multiple (e.g., eight) chips is added to the bank to expand the array, so that the top of the column that currently contains chips F11-F14 is expanded. In another embodiment, the piggyback substrate will expand the array underneath the row containing the current chips F41-F44. Another embodiment extends the right side of chips F14, F24, F34, F44. Another embodiment extends the left side of chips F11, F21, F31, F41.
FIG. 7 shows the connection matrix of the 4x4 FPGA array of FIG. 8 as "1" or "0". This connection matrix is used to generate deployment cost results from the cost function used for hardware mapping, placement and routing of the SEmulation system. The cost function has been described above with respect to FIG. 6. As in the example, chip F11 is located within one hop from chip F13, so the connection matrix entry of F11-F13 is " 1 &quot;.
Figure 21 illustrates the interconnect pin-out of a single FPGA chip in accordance with an embodiment of the present invention. Each chip has six sets of interconnects, each set containing a certain number of pins. In one embodiment each set has 44 pins. The interconnects of each FPGA chip are oriented horizontally (east-west) and vertically (north-south). The west set of interconnects is called W [43: 0]. The set of interconnections on the east side is called E [43: 0]. The north set of interconnects is called N [43: 0]. The south set of interconnects is called S [43: 0]. This complete set of interconnects is for connecting adjacent chips; That is, these interconnects do not "hop" beyond any chip. For example, in FIG. 8, chip F33 includes interconnects 607 of N [43: 0], interconnects 608 of E [43: 0], interconnects 609 of S [43: 0], and Has an interconnection of W [43: 0].
Returning to FIG. 21, two sets of additional interconnects remain. One set of interconnects is for non-contiguous interconnects vertically followed by-YH [21: 0] and YH [43:22]. Another set of interconnects is for non-contiguous interconnects horizontally leading to XH [21: 0] and XH [43:22]. Each set YH [...] and XH [...] is divided into two such that half of each set contains 22 pins. This configuration allows each chip to be manufactured identically. Thus, each chip can be interconnected in one hop to non-adjacent chips located at the top, bottom, left and right sides. The FPGA chip also represents pin (s) for general purpose signals, FPGA buses, and JTAG signals.
The FPGA I / O controller is described next. This controller was first briefly introduced as item 327 in FIG. FPGA I / O controllers manage data and control traffic between the PCI bus and the FPGA array.
22 illustrates one embodiment of an FPGA controller between a PCI bus and an FPGA array with a bank of FPGA chips. The FPGA I / O controller 700 includes a CTRL_FPGA unit 701, a clock buffer 702, a PCI controller 703, an EEPROM 704, an FPGA serial configuration interface 705, a boundary scan check interface 706, and a buffer ( 707). Appropriate power / voltage regulation circuits known to those skilled in the art are provided. Typical sources include Vcc, which is connected to a voltage detector / regulator and detection amplifier to maintain almost no voltage under various environmental conditions. The Vcc for each FPGA chip is equipped with a fast-acting thin film fuse in between. Vcc-HI is provided in CONFIG # for all FPGA chips and LINTI # for LOCAL_BUS 708.
The CTRL_FPGA unit 701 is the first controller of the FPGA I / O controller 700 that handles various control, inspection, and read / write independent data among various units and buses. CTRL_FPGA unit 701 is coupled to the low and high banks of the FPGA chip. The FPGA chips F41-F44 and F21-F24 (ie, low banks) are connected to the low FPGA bus 718. The FPGA chips F31-F34 and F11-F14 (ie, high banks) are connected to the high FPGA bus 719. These FPGA chips F11-F14, F21-F24, F31-F34, and F41-F44 correspond to the FPGA chips of FIG. 8 and maintain their symbols.
The low bank bus 718 and high bank bus 719 between these FPGA chips F11-F14, F21-F24, F31-F34, F41-F44 are thick film chip resistors for proper load. The resistor group 713 connected to the low bank bus 718 includes, for example, a resistor 716 and a resistor 717. The resistor group 712 connected to the high bank bus 719 includes a resistor 714 and a resistor 715, for example.
If expansion is desired, more FPGA chips may be installed in the low bank bus 718 and high bank bus 719 in the right direction of the FPGA chips F11 and F21. In one embodiment expansion is through a piggyback substrate similar to piggyback substrate 720. Therefore, if the bank of these FPGA chips had only the first eight FPGA chips (F41-F44 and F31-34), then the piggy bank containing the low bank FPGA chips (F24-F21) and the high bank chips (F14-F11). Expansion is further possible by adding a back substrate 720. Piggyback substrate 720 also includes additional low and high bank buses and thick film chip resistors.
PCI controller 703 is the main interface between FPGA I / O controller 700 and 32-bit PCI bus 709. If the PCI bus is extended to 64 bits and / or 66 MHz, appropriate adjustments can be made in the system without departing from the spirit and scope of the present invention. This adjustment will be explained below. One example of a PCI controller 703 that can be used in the system is PCI 9080 or 9060 from PLX Technology. The PCI 9080 has a suitable local bus interface, control registers, FIFOs, and a PCI interface to the PCI bus. Data Book PLX Technology, PCI 9080 Data Sheet (February 28, 1997 version 0.93) is incorporated herein by reference.
The PCI controller 703 delivers data to the CTRL_FPGA unit 701 and the PCI bus 709 via the LOCAL_BUS 708. LOCAL_BUS includes a control bus portion, an address bus portion, and a data bus portion for the control signal, an address signal, and a data signal, respectively. If the PCI bus is extended to 64 bits, the data bus portion of LOCAL_BUS 708 can also be extended to 64 bits. PCI controller 703 is coupled to EEPROM 704, which contains configuration data for PCI controller 703. Exemplary EEPROM 704 is 93CS46 from National Semiconductor.
The PCI bus 709 supplies a 33 MHz clock signal to the FPGA I / O controller 700. The clock signal is provided to the clock buffer 702 via wire line 710 for synchronization purposes and for low timing skew. The output of this clock buffer 702 is a 33 MHz global clock (GL_CLK) signal supplied to all FPGA chips via wire line 711 and to CTRL_FPGA unit 701 via wire line 721. If the PCI bus is extended to 66MHz, the clock buffer will also supply 66MHz to the system.
The FPGA serial configuration interface 705 provides configuration data to configure the FPGA chips F11-F14, F21-F24, F31-F34, and F41-F44. Altera Data Book, Altera, 1996 DATA BOOK (June 1996) provides and processes detailed information on configuration devices. FPGA serial configuration interface 705 is also coupled to LOCAL_BUS 708 and parallel port 721. In addition, the FPGA serial configuration interface 705 is coupled to the CTRL_FPGA unit 701 and the FPGA chips F11-F14, F21-F24, F31-F34, and F41-F44 via the CONF_INTF wire line 723.
The boundary scan test interface 706 provides a JTAG implementation of a certain set of specific test instructions to externally check the logic units and circuits of the processor or system by software. This interface 706 is an IEEE Std. Compile to the 1149-1990 specification. See Altera Data Book, Altera, 1996 DATA BOOK (June 1996) and Application Note 39 (JTAG Boundary-Scan Test on Altera Devices). The two references are incorporated herein by reference for more information. The boundary scan test interface 706 is coupled to the CTRL_FPGA unit 701 and the FPGA chips F11-F14, F21-F24, F31-F34, and F41-F44 via the BST_INTF wire line 724.
The CTRL_FPGA unit 701, along the buffer 707, passes through the low bank 32 bit bus 718 and the high bank 32 bit bus 719, respectively, to the low (chips F41-44 and F21-F24) and high ( Chips F31-34 and F11-F14) transfer data to / from banks, F_BUS 725 for low bank 32 bit FD [31: 0] and F_BUS (726 for high bank 32 bit FD [63:32] ).
One embodiment doubles the throughput of PCI bus 709 of low bank bus 718 and high bank bus 719. PCI bus 709 is 32 bits wide at 33 MHz. Thus, the throughput is 132 MB (= 33 MHz * 4 bytes). The low bank bus 718 is 32 bits at half the PCI bus frequency (33/2 MHz = 16.5 MHz). The high bank bus 719 is also 32 bits at half the PCI bus frequency (33/2 MHz = 16.5 MHz). Throughput for the 64-bit low bank bus and high bank bus is also 132 MB (= 16.5 MHz * 8 bytes). Thus, the performance of the low bank bus and high bank bus follows the performance of the PCI bus. In other words, the performance limit is on the PCI bus, not the low bank bus and the high bank bus.
According to one embodiment of the invention, an address pointer is also implemented with each FPGA chip for each software / hardware boundary address space. These address pointers are combined for several FPGA chips through a multiplexed cross chip address pointer chain. See the address pointer discussed above with respect to FIGS. 9, 11, 12, 14 and 15. In order to move the word select signal for a chain of address pointers and for several chips associated with a given address space, a chain out wire line must be provided. This chain out wire line is shown as an arrow between chips. The chain out wire line for the low bank is the wire line 730 between chip F23 and chip F22. Another said chain out wire line for the high bank is the wire line 731 between chip F31 and chip F32. The chain out wire line 732 at the end of the low bank chip F21 is coupled to the CTRL_FPGA unit 701 as LAST_SHIFT_L. Chain out wire line 733 at the end of high bank chip F11 is coupled to CTRL_FPGA unit 701 as LAST_SHIFT_H. These signals LAST_SHIFT_L and LAST_SHIFT_H are word select signals for each bank when the word select signal is propagated through the FPGA chip. When one of these signals LAST_SHIFT_L and LAST_SHIFT_H provides logic " 1 " to CTRL_FPGA unit 701, this indicates that the word select signal has advanced to each bank end of the chip.
CTRL_FPGA unit 701 writes signal F_WR on wire line 734, read signal F_RD on wire line 735, DATA_XSFR signal on wire line 736, and on wire line 738. The SPACE [2: 0] signal is provided to and from the FPGA chip. CTRL_FPGA unit 701 receives the EVAL_REQ # signal on wire line 739. The write signal F_WR, read signal F_RD, DATA_XSFR signal, and SPACE [2: 0] signal work together with respect to the address pointer of the FPGA chip. The write signal F_WR, the read signal F_RD, the DATA_XSFR signal, and the SPACE [2: 0] signal are determined by the SPACE index SPACE [2: 0] and the MOVE signal is directed to an address pointer associated with the selected address space. Used to generate The DATA_XSFR signal is used to initialize the address pointer and starts the word-by-word transfer process.
The EVAL_REQ # signal is used to restart the evaluation cycle as a whole if any of the FPGA chips see this signal. For example, to evaluate the data, the data is transferred or written from the main memory of the computing station of the host processor to the FPGA via the PCI bus. At the end of the transfer, the evaluation cycle begins, including address pointer initialization and the operation of the software clock to facilitate the evaluation process. However, for various reasons, a particular FPGA chip may need to reevaluate the data entirely. This FPGA chip sees the EVAL_REQ # signal and the CNTI_FPGA chip 701 restarts the evaluation cycle as a whole.
FIG. 23 shows a more detailed example of the CTRL_FPGA unit 701 and buffer 707 of FIG. 22. The same input / output signal and corresponding reference number for the CTRL_FPGA unit 701 shown in FIG. 22 are retained and used in FIG. However, additional signals and wire / bus lines not shown in FIG. 22 are, for example, SEM_FPGA output enable 1016, local interrupt output (Local INTO) 708a, local read / write control signal 708b. Will be described using new reference numbers, such as local address bus 708c, local interrupt input (Local INTE #) 708d, and local data bus 708e.
The CTRL_FPGA unit 701 includes Transfer Done Checking Logic (XSFR_DONE Logic) 1000, EVAL Logic 1001, DMA Descriptor Block 1002, Control Register 1003, and Evaluation Timer Logic. (EVAL timer) 1004, address decoder 1005, write flag sequencer logic 1006, FPGA chip read / write control logic (SEM_FPGA R / W Logic) 1007, demultiplexer and latch (DEMUX logic) 1008 And latches 1009-1012 corresponding to the buffer 707 of FIG. 22. The global clock signal CTRL_FPGA_CLK on wire / bus 721 is provided to all logic elements / blocks of CTRL_FPGA unit 701.
Transfer done checking logic (XSFR_DONE) 1000 receives LAST_SHIFT_H 733, LAST_SHIFT_L 732 and local INTO 708a. The XSFR_DONE logic 1000 outputs the transmission end signal XSFR_DONE on the wire / bus 1013 to the EVAL logic 1001. Based on the reception of LAST_SHIFT_H 733 and LAST_SHIFT_L 732, the XSFR_DONE logic 1000 checks the end of the data transfer so that the evaluation cycle can begin if necessary.
EVAL logic 1001 receives the transmission end signal XSFR_DONE on wire / bus 1013, along with the EVAL_REQ # signal on wire / bus 739 and the WR_XSFR / RD_XSFR signal on wire / bus 1015. EVAL logic 1001 generates two output signals, Start EVAL on wire / bus 1014 and DATA_XSFR on wire / bus 736. The EVAL logic indicates when data transfer between the FPGA bus and the PCI bus begins to initialize the address pointer. The EVAL logic receives an XSFR_DONE signal when the data transfer ends. The WR_XSFR / RD_XSFR signal indicates whether the transmission is read or written. Once the I / O cycle ends (or before the onset of the I / O cycle), the EVAL logic can begin the evaluation cycle using the Start to EVAL Timer signal. The EVAL timer ensures the successful operation of the software clock mechanism by defining the duration of the evaluation cycle and maintaining the evaluation cycle as valid as necessary to stabilize the data propagation for all registers and coupling components.
DMA descriptor block 1002 includes a local bus address on wire / bus 1019, a wire enable signal on wire / bus 1020 from address decoder 1005, and a wire via local data bus 708e. Receive local bus data on / bus 1029. The output is a DMA descriptor output on wire / bus 1046 directed to DEMUX logic 1008 on wire / bus 1045. The DMA descriptor block 1002 includes descriptor block information corresponding to information in the host memory, which includes a PCI address, a local address, a transfer count, a transfer direction, and an address for the next descriptor block. The host also sets up the address of the initial descriptor block in the descriptor pointer register of the PCI controller. Transmission can be initiated by setting a control bit. PCI loads the first descriptor block and initializes the data transfer. The PCI controller continues to load the descriptor block and transfer data until it detects the last chain bit set in the next descriptor pointer register.
The address decoder 1005 receives and forwards local R / W control signals on bus 708b and receives and forwards local address signals on bus 708c. The address decoder 1005 has a write enable signal on the wire / bus 1020 for the DMA descriptor 1002, a write enable signal on the wire / bus 1021 for the control register 1003, a wire / bus 738. FPGA address SPACE index on, control signal on wire / bus 1027, and another control signal on wire / bus 1024 for DEMUX logic 1008.
The control register 1003 receives the write enable signal on the wire / bus 1021 from the address decoder 1005 and the data via the local data bus 708e from the wire / bus 1030. Control register 1003 includes a WR_XSFR / RD_XSFR signal on wire / bus 1015 for EVAL logic 1001, a Set EVAL time signal for EVAL timer 1004, and SEM_FPGA on wire / bus 1016 for FPGA chip. Generate an output enable signal. The system uses the SEM_FPGA output enable signal to selectively turn on or enable each FPGA chip. Typically, the system enables one FPGA chip each at a given time.
EVAL timer 1004 receives the Start EVAL signal on wire / bus 1014 and Set EVAL time on wire / bus 1041. EVAL timer 1004 records the ~ EVAL signal on wire / bus 737, the end of evaluation (EVAL_DONE) signal on wire / bus 1017, and Start on wire / bus 1018 for Write Flag Sequencer logic 1006. Generate a flag signal. In one embodiment, the EVAL timer is 6 bits long.
Write Flag Sequencer logic 1006 receives a Start write flag signal on wire / bus 1018 from EVAL timer 1004. Write Flag Sequencer logic 1006 may be configured to provide a local R / W control signal on wire / bus 1022 for local R / W wire / bus 708b, local on wire / bus 1023 for local address bus 708c. Generate an address signal, a local data signal on wire / bus 1028 for local data bus 708e, and a local INTI # on wire / bus 708d. Upon receiving the start write flag signal, the write flag sequencer logic begins a sequence of control signals to begin a memory write cycle for the PCI bus.
SEM_FPGA R / W control logic 1007 controls control signals on wire / bus 1027 from address decoder 1005 and local R / W on wire / bus 1047 via local R / W control bus 708b. Receive the control signal. SEM_FPGA R / W control logic 1007 includes enable signal on wire / bus 1035 for latch 1009, control signal on wire / bus 1025 for DEMUX logic 1008, for latch 1011. Enable signal on wire / bus 1037, enable signal on wire / bus 1040 to latch 1012, F_WR signal on wire / bus 734, and F-RD signal on wire / bus 735 Create SEM_FPGA R / W control logic 1007 controls various write and read data transfers to / from the FPGA low bank and high bank buses.
DEMUX logic 1008 is multiplexed and latched, which receives four sets of input signals and outputs one set of signals on wire / bus 1026 to local data bus 708e. The selector signals are control signals on wire / bus 1025 from SEM_FPGA R / W control logic 1007 and control signals on wire / bus 1024 from address decoder 1005. DEMUX logic 1008 receives one set of inputs from the EVAL_DONE signal on wire / bus 1042, the XSFR_DONE signal on wire / bus 1043, and the ˜EVAL signal on wire / bus 1044. A single set of these signals has been labeled 1048. In any one time interval, only one of these three signals, EVAL_DONE, XSFR_DONE, and ˜EVAL, is provided to DEMUX logic 1008 to allow for selection. The DEMUX logic 1008 is also the other three sets of input signals, the DMA descriptor output signal on the wire / bus 1045 from the DMA descriptor block 1002 and the data on the wire / bus 1039 from the latch 1012. And another data output on wire / bus 1034 from latch 1010.
The data buffer between CTRL_FPGA unit 701 and the low and high FPGA bank buses includes latches 1009-1012. Latches 1009 are local bus data on wire / bus 1032 via wire / bus 1031 and local data bus 708e, and on wire / bus 1035 from SEM_FPGA R / W control logic 1007. Receive an enable signal. Latch 1009 outputs data on wire / bus 1033 to latch 1010.
Latch 1010 receives data on wire / bus 1033 from latch 1009 and enable signal on wire / bus 1036 via wire / bus 1037 from SEM_FPGA R / W control logic 1007. Receive. Latch 1010 outputs data on wire / bus 725 to FPGA low bank bus and DEMUX logic 1008 via wire / bus 1034.
Latch 1011 receives data on wire / bus 1031 from local data bus 708e and enable signal on wire / bus 1037 from SEM_FPGA R / W control logic 1007. Latch 1011 outputs data on wire / bus 726 to the FPGA high bank bus and outputs data on wire / bus 1038 to latch 1012.
Latch 1012 receives data on wire / bus 1038 from latch 1011 and enable signal on wire / bus 1040 from SEM_FPGA R / W control logic 1007. Latch 1012 outputs data on wire / bus 1039 to DEMUX 1008.
24 shows a 4x4 FPGA array, the relationship of the FPGA array to the FPGA bank, and expansion capabilities. Similar to FIG. 8, FIG. 24 shows the same 4 × 4 array. Also shown is CTRL_FPGA unit 740. The low bank chips (chips F41-F44 and F21-F24) and the high bank chips (chips F31-F34 and F11-F14) are alternately arranged. Thus, the FPGA chip row from the lower row to the upper row is characterized by: low bank-high bank-low bank-high bank. The data transmission chain follows the banks in a predetermined order. The data transfer chain for the low bank is shown by arrow 741. The data transfer chain for the high bank is shown by arrow 742. The JTAG configuration chain is shown by arrow 743, which extends the entire array of chips F41 through F44, F34 through F31, F21 through F24, and F14 through F11, and returns to CTRL_FPGA unit 740.
Expansion can be accomplished with a piggyback board. Assuming that the original array of FPGA chips in FIG. 24 includes F41-F44 and F31-F34, the addition of two or more chips F21-F24 and F11-F14 can be accomplished with the piggyback board 745. Piggyback board 745 includes a suitable bus to extend the bank. Further expansion can be achieved with many piggyback boards arranged on other tops of the array.
25 illustrates one embodiment of a hardware start-up method. Step 800 begins powering up or warming up the boot sequence. In step 801, the PCI controller reads the starting EEPROM. Step 802 reads and writes the PCI controller registers due to the initial sequence. Step 803 boundary scan checks for all FPGA chips in the array. Step 804 configures CTRL_FPGA of the FPGA I / 0 controller. Step 805 reads and writes the registers of the CTRL_FPGA unit. Step 806 sets up the PCI controller for the DMA master read / write mode. The data is then delivered and verified. Step 807 configures all FPGAs with the test design and verifies the modifications. In step 808, the hardware is ready for use. In this regard, the system takes every step that results from a positive confirmation of the operation of the hardware, otherwise the system never reaches step 808.
E. Optional Embodiments Using Highly Integrated FPGA Chips
In one embodiment of the invention, FPGA logic elements are provided on each board. If more FPGA logic elements are required to model your circuit design than are provided on the board, multiple boards with many FPGA logic elements can be provided. The ability to add many boards to the simulation system is a desirable feature of the present invention. In this embodiment, dense FPGA chips such as 10K130V and 10K250V that are changeable are used. The use of these chips changes board design and is used per board instead of up to eight dense FPGA chips (eg, 10K100, which can be changed).
Coupling these boards to the motherboard of the simulation system represents a challenge. Interconnection and connection methods shall compensate for backside defects. In a simulation system, FPGAs are provided on the motherboard through specific board interconnect structures. Each chip can have eight sets of interconnects, where the interconnects are directly adjacent interconnects (ie, N [73: 0], S [73: 0], W [73: 0], E [73: 0]), and one hop neighbor interconnect (i.e. NH [27: 0], SH [27: 0], XH [36: 0], XH) excluding local bus connections within a single board and across other boards. [72:37]). Each chip is directly interconnected to an adjacent neighboring chip or directly to one hop for a non-up-up chip disposed on top, bottom, left and right. In the x direction (east-west), the array is torus. In the Y direction (north south), the array is a mesh.
The interconnects combine logic components and other components within a single board. However, internal board connectors provide for (1) coupling of these boards and interconnects across other boards to carry signals between the PCI bus and array boards through the motherboard, and (2) any two array boards. do. Each board includes its own FPGA bus FD [63: 0] that allows the FPGA logic device to communicate with each other, namely SRAM memory devices, and the CTRL_FPGA unit (FPGA I / 0 controller). FPGA bus FD [63: 0] is not provided for multiple boards. However, FPGA interconnects provide connectivity between FPGA logic devices for many boards, even though these interconnects are not related to the FPGA bus. On the other hand, a local bus is provided for all boards.
Motherboard connectors connect the board to the motherboard, connecting it to the PCI bus, power, and ground. For some boards, motherboard connectors are not used for direct connection to the motherboard. In a six board configuration, only boards 1, 3, and 5 are directly connected to the motherboard and the remaining boards 2, 4, and 6 depend on neighboring boards for motherboard connection. Thus, each other board is directly connected to the motherboard, and the interconnects and local buses of these boards are joined together to the component side via internal board connectors arranged on the solder side. PCI signals are routed only through one of the boards (typically the first board). Power and ground are applied to the other motherboard connectors for these boards. Various internal board connectors placed on the solder side to the component side provide communication between PCI bus components, FPGA logic elements, memory elements, and various simulation systems and control circuits.
56 shows a high level block diagram of an array of FPGA chip configurations in accordance with an embodiment of the present invention. The CTRL_FPGA unit 1200 described above is coupled to bus 1210 via lines 1209 and 1236. In one embodiment, CTRL_FPGA unit 1200 is a programmable logic device (PLD) in the form of an FPGA chip, such as a modifiable 10K50 chip. Bus 1210 is coupled to other simulation array boards (if any) and other chips (eg, PCI, controllers, EEPROMs, clock buffers). 56 shows another major functional block in the form of a logic element and a memory element. In one embodiment, the logic device is a programmable logic device (PLD) in the form of a changeable 10K130V or 10K250V chip. The 10K130V and 10K250V are compatible pins, each in a 599-pin PGA package. Thus, instead of the embodiment described above with eight changeable FLEX 10K100 chips in the array, this embodiment uses only four chips of changeable FLEX 10K130. One embodiment of the present invention describes a board comprising these four logic elements and their connections.
Because the user design is modeled and configured with these arbitrary numbers of logic elements in the array, internal FPGA logic device communication needs to connect one part of the user's circuit design to another part. In addition, initial configuration information and boundary scans are supported by the internal FPGA interconnect. Finally, the required simulation system control signals must be accessible between the simulation system and the FPGA logic device.
Figure 36 illustrates the hardware architecture of the FPGA logic device used in the present invention. FPGA logic device 1500 includes 102 upper I / 0 pins, 102 lower I / 0 pins, 111 left I / O pins, and 10 right I / O pins. Thus, the total number of interconnect pins is 425. In addition, additional 45 I / 0 pins include GCLK, FPGA bus FD [31: 0] (for high bang, FD [63:32] is used), F_RD, F_WR, DATAXSFR, SHIFIN, SHIFTOUT, SPACE [2: 0], ~ EVAL, EVAL_REO_N, DEVICE_OE (signal from CTRL_FPGA unit to turn on output pin of FPGA logic element), and DEV_CLRN (signal from CTRL_FPGA unit to clear all internal flip flops before simulation starts) do. Thus, any data and control signals that cross between any two FPGA logic elements are performed by these interconnects. The remaining pins are used for power and ground.
Figure 37 illustrates an FPGA interconnect pin out for a single FPGA chip in accordance with an embodiment of the present invention. Each chip 1510 may have eight interconnect sets, where each set includes a certain number of pins. Some chips can have up to eight sets of interconnects, depending on their location on the board. In a preferred embodiment, every chip has a set of seven interconnects, although the particular set of interconnections used may vary from chip to chip depending on its respective board location. The interconnects for each FPGA chip are oriented horizontally (east-west) and vertical (north-south). The interconnect set for the west direction is labeled as W [73: 0]. The set of interconnects for the east direction is labeled as E [73: 0]. The set of interconnections for the north direction is labeled as N [73: 0]. The interconnect set for the south direction is labeled as S [73: 0]. These complete sets of interconnects are interconnections for adjacent chips; That is, these interconnects do not "hop" on any chip. For example, in FIG. 39, chip 1570 is interconnect 1540 for N [73: 0], interconnect 1542 for W [73: 0], and interconnect for E [73: 0]. Connector 1543 and interconnect 1545 for S [73: 0]. The FPGA chip 1570, an FPGA2 chip, has all four adjacent interconnect sets-N [73: 0], S [73: 0], W [73: 0] and E [73: 0]. The west interconnect of FPGA0 is connected to the east interconnect of FPGA3 via wire 1539 by a torus-shaped interconnect. Thus, wire 1539 allows chips 1569 (FPGA0) and 1572 (FPGA3) to be directly coupled to each other in a manner similar to winding the west-east end of the board to be wound around.
Referring to FIG. 37, four sets of "hopping" interconnects are provided. Two sets of interconnects are for non-nearly interconnects—NH [27: 0] and SH [27: 0] that extend vertically. For example, the FPGA2 chip of FIG. 39 shows NH interconnect 1541 and SH interconnect 1546. Referring to Figure 37, the other two sets of interconnects are non-contiguous interconnects -XH [36: 0] and XH [72:37] extending horizontally. For example, the FPGA chip 1570 of FIG. 39 shows an XH interconnect 1544.
Referring to FIG. 37, the vertical hopping interconnects NH [27: 0] and SH [27: 0] each have 28 pins. The horizontal interconnect has 73 pins (XH [36: 0] and XH [72:37]). Horizontal interconnect pins XH [36: 0] and XH [72:37] are west (e.g., interconnect 1605 of FIG. 39, for FPGA3 chip 1576) and / or east (e.g., For example, for FPGA0 chip 1573, it may be used in interconnect 1602 of FIG. This structure allows each chip to be ideally formed. Thus, each chip can be connected to one hop for non-adjacent chips disposed on the top, bottom, left and right.
FIG. 39 illustrates a immediately adjacent one hop adjacent FPGA array arrangement of six boards on a single motherboard in accordance with an embodiment of the present invention. This structure is used to describe two possible structures, such as a six board system and a dual board system. Position indicator 1550 indicates that the "Y" direction is north-south and the "X" direction is east-west. In the X direction, the array is torus. In the Y direction, the array is a mesh. In FIG. 39, only the board, FPGA logic elements, interconnects and higher level connectors are shown. Main boards and other auxiliary devices (e.g., SRAM memory devices) and wiring (e.g., FPGA buses) are shown.
Figure 39 illustrates the array shape and components, interconnects and connectors of the board. The actual physical configuration and placement involves placing this board on each edge element side with respect to the solder side. Roughly half of the board is connected directly to the motherboard, while the other half of the board is connected to each neighboring board.
In an embodiment using six boards according to the present invention, six boards 1551 (board 1), 1552 (board 2), 1553 (board 3), 1554 (board 4), 1555 (board 5), 1556 ( Board 6) is provided on a motherboard (not shown) which is part of the reconfigurable hardware of FIG. Each board contains a nearly identical set of components and connectors. Thus, for purposes of explanation, sixth board 1556 includes FPGA logic elements 1565-1568 and connectors 1557-1560 and 1581, and fifth board 1555 includes FPGA logic elements 1569-1572. ) And connectors 1582 and 1583, and fourth board 1554 includes FPGA logic elements 1573-1576 and connectors 1584 and 1585.
In this six board structure, board 1551 and board 1556 are Y-mash terminals, such as R-pack terminals 1557-1560 on board 6 1556, and terminals 1591-1594 on board 1 1551. It is provided as a "bookend" board, including Intermediate boards (ie, boards 1552 (board 2), 1553 (board 3), 1554 (board 4) and 1555 (board 5)) are provided to complete the array.
As noted above, across other boards within a single board except for local bus connections, the interconnects are adjacent direct neighbor interconnects (ie, N [73: 0], S [73: 0], W [73: 0). ], E [73: 0]), and one-hop neighbor interconnect (ie NH [27: 0], SH [27: 0], XH [36: 0], XH [27:37]) Is placed. The interconnect can only combine logic elements with other elements within a single board. However, board-to-board connectors 1581-1590 enable communication between FPGA logic elements across multiple boards (ie, boards 1-6). The FPGA bus is part of the board-to-board connectors 1581-1590. These connectors 1581-1590 are 600-pin connectors that transmit 520 signals and make 80 power / ground connections between two neighboring array boards.
In FIG. 39, various boards are arranged in an asymmetrical manner with respect to the board-to-board connectors 1581-1590. For example, between board 1551 and board 1552, inter-board connectors 1589 and 1590 are provided. Interconnect 1515 connects FPGA logic elements 1511 and 1577 together, and, depending on connectors 1589 and 1590, these connections are symmetrical. However, interconnect 1603 is not symmetric; The FPGA of the third board 1553 is connected to the FPGA logic elements of the board 1551. For connectors 1589 and 1590, these interconnects are asymmetrical. Similarly, the interconnect 1600 is asymmetrical with respect to connectors 1589 and 1590, which are interconnect terminals that connect the FPGA logic element 1557 to the FPGA logic element 1577 through the interconnect 1601. 1591). There are other similar interconnects that show asymmetry.
As a result of this asymmetry, the interconnects are routed (routed) through the board-to-board connectors in two ways: one is a symmetrical interconnect, such as interconnect 1515, and the other is interconnected with interconnects 1603 and 1600. Same asymmetric interconnects. The interconnect routing means are shown in Figures 40 (A) and 40 (B).
In FIG. 39, an example of a direct neighbor connection within a single board is an interconnect 1543 that couples the logic element 1570 to the logic element 1571 along the east-west direction of the board 1555. Another example of a direct neighbor connection within a single board is an interconnect 1607 that couples the logic element 1573 to the logic element 1576 of the board 1554. An example of a direct-neighbor connection between two different boards couples the logic element 1570 of the board 1555 to the logic element 1574 of the board 1554 via connectors 1583 and 1584 along the north-west direction. Interconnect 1545. Here, two board-to-board connectors 1583 and 1584 are used to transmit signals.
An example of a one-hop interconnect within a single board is an interconnect 1544 that couples the logic element 1570 to the logic element 1552 on the board 1555 along the east-west direction. An example of a one-hop interconnect between two different boards is an interconnect 1599 that couples the logic element 1556 of the board 1556 to the logic element 1573 of the board 1554 via connectors 1581-1584. )to be. Here, four board-to-board connectors 1581-1584 are used to transmit across the signal.
In particular, some boards located at the north-south end of the motherboard include a 10 ohm R-pack to terminate a given connection. Thus, the sixth board 1556 includes 10 ohm R-pack connectors 1557-1560, and the first board 1551 includes 10 ohm R-pack connectors 1591-1594. Sixth board 1556 is R-pack connector 1557 for interconnects 1970 and 1971, R-pack connector 1558 for interconnects 1972 and 1541, and R-pack for interconnects 1973 and 1974. Connector 1559, R-pack connector 1560 for interconnects 1975 and 1976. Moreover, interconnects 1561-1564 are not connected to anything. Unlike the east-west torus-type interconnection, the north-south interconnection is arranged in a mesh-type manner.
This mesh interconnection increases the number of north-south interconnections. Otherwise, the interconnect at the north and south edges of the FPGA mesh would all be useless. For example, FPGA logic elements 1511 and 1577 already have one set of direct interconnects 1515. Additional interconnects are also provided to these two FPGA logic elements via R-pack 1591 and interconnects 1600 and 1601; That is, R-pack 1591 connects interconnects 1600 and 1601 together. This increases the number of direct connections between FPGA logic elements 1511 and 1577.
Internal board connections are provided. Logic elements 1577, 1578, 1579, and 1580 on board 1551 are coupled to logic elements 1511, 1512, 1513, and 1514 on board 1522 through interconnects 1515, 1516, 1517, and 1518. Thus, interconnect 1515 couples logic elements 1511 on board 1552 to logic elements 1577 on board 1551 through connectors 1589 and 1590; Interconnect 1516 couples logic elements 1512 on board 1552 to logic elements 1577 on board 1551 through connectors 1589 and 1590; Interconnect 1517 couples logic elements 1513 on board 1552 to logic elements 1579 on board 1551 through connectors 1589 and 1590; Interconnect 1518 couples logic elements 1514 on board 1552 to logic elements 1580 on board 1511 through connectors 1589 and 1590.
Some interconnects, such as interconnects 1595, 1596, 1597 and 1598, are not connected to either because they are not used. However, as described above with respect to logic elements 1511 and 1577, R-pack 1591 is connected to interconnects 1600 and 1601 to increase north-south interconnection.
A dual board embodiment of the present invention is shown in FIG. In a dual board embodiment of the present invention, only two boards are necessary for modeling the user's design in the simulation system. Like the six board structure of FIG. 39, the dual board structure of FIG. 44 uses the same two boards (board 1 1551 and board 6 1556) for the "bookend", which is the reconstruction in FIG. It is provided on a motherboard that is part of the flexible hardware unit 20. In FIG. 44, one bookend board is board 1 and the second bookend board is board 6. In FIG. Board 6 is used in FIG. 44 to show similarly to board 6 in FIG. 39; That is, bookend boards such as boards 1 and 6 have the necessary terminals for north-south mesh connections.
This dual board structure comprises four FPGA logic devices 1577 (FPGA0), 1578 (FPGA1), 1579 (FPGA2) and 1580 (FPGA3) on board 1 (1551), and four FPGA logic devices on board 6 (1556). (1565 (FPGA0), 1566 (FPGA1), 1567 (FPGA2), and 1568 (FPGA3). These two boards are connected by internal-board connectors 1581 and 1590.
This board includes a 10µR-pack to terminate any connection. For a dual board embodiment, the two boards are "bookend" boards. Board 1551 includes 10ΩR-pack connectors 1591, 1592, 1593, and 1594 as resistive terminals. The second board 1556 also includes 10 Ω R-pack connectors 1557-1560.
Board 1551 has a connector 1590 and board 1556 has a connector 1581 for inter-board communication. Interconnects from one board to another, such as interconnects 1600, 1971, 1977, 1541, 1540, proceed to these connectors 1590, 1581; In other words, the internal-board connectors 1590, 1581 allow interconnects 1600, 1971, 1977, 1541, 1540 to connect between one component on one board and another component on the other board. Internal-board connectors 1590 and 1581 transfer control data and control signals on the FPGA bus.
In a four-board configuration, boards 1 and 6 are provided with bookend boards, 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 with boards 21551, boards 315353 and boards 4554; Board 5 1555 (see FIG. 39) is an intermediate board. 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 board 1 and board 6 in FIG. 39) have the necessary terminals 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 element is coupled to a neighboring logic element that is not adjacent to an adjacent neighboring logic element in one hop. Thus, in FIGS. 39 and 44, logic element 1577 couples with adjacent neighboring logic element 1578 through interconnect 1547. Logic element 1577 also couples with non-neighboring logic elements 1579 through one-hop interconnect 1548. However, logic element 1580 may be considered adjacent to logic element 1577 due to a torus configuration that is wound into interconnect 1549 providing coupling.

delete

delete

delete

delete

delete

delete

42 shows a top view (component side) of an on-board component and connector 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 and bottom ends, the board 1551 is terminated by one set of 10 μs R-pack and the board 1556 is terminated by another set of 10 μs R-pack.
Referring back to FIG. 42, the board 1820 has four FPGAs, that is, a logic element 1822 (FPGA0), a logic element 1827 (FPGA1), a logic element 1824 (FPGA2), and a logic element 1825 (FPGA3). )). Also provided are two SRAM memory elements 1828 and 1829. The SRAM memory elements 1828 and 1829 are used to map memory blocks from logic elements on the board; That is, the memory simulation feature of the beam invention maps from a logic element on the board to an SRAM memory element on the board. Other boards may have different logic and memory elements 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 elements and memory elements on board 1 but is independent of other boards. In another embodiment, the memory mapping is not board dependent. Thus, a few large memory elements are used to map memory blocks from logic elements on one board to memory elements located on another board.

delete

A light emitting diode (LED) 1821 is also provided to visually illustrate some selection operations. 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 can be used in a system is PCI9080 or PCI9060 from PLX Technology. The PCI9080 has an appropriate local bus 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 and 5 are directly connected to the motherboard while the remaining boards 2, 4 and 6 rely on the motherboard and neighboring boards for access. Inner-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. Connectors J1 and J2 are used for stand-alone single-board boundary scan testing 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 accesses. Connectors J17-J28 are a second set of PGA interconnect access. When the component-side is located on the solder-side, the connector provides effective access 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: J5 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 Row A: J17 Low B, VCC3V, GND Row 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 [2] Low B: S [0], 4x VCC3V, 4x GND, S [2] 0.05 "pitch, 2x45 through-hole header, SAMTEC, comp / solder side J20 Low A: S [0], 4x VCC3V, 4x GND, S [2] Low B: S [0], 4x VCC3V, 4x GND, S [2] 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 Row A: J21 Row B, FIRSTL, GND Row B: J21 Row 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. In Table D, parentheses [] indicate SMS FPGA logic device numbers (0-3). Thus, S [0] represents 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 End OD A30 VCC5V PWR B30 VCC5V PWR

I / O direction is board 1 direction

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 dot outline block 1843 filled in green represents a 2x30 or 2x45 receptacle located on the solder side in a through hole type. 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 intra-board communication. Related buses and signals are grouped together and supported by these inner-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 1661-1668 designated for one set of FPGA interconnects, connectors 1669-1674, 1676, 1679 designated for another set of FPGA interconnects, and It includes a connector 1801 designated for the local bus. 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 It is designated as 10m R-pack for a given north-south interconnection. 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 designates connector 11691-1698 designated for one set of FPGA interconnects, connector 1699-1706 designated for another set of FPGA interconnects, and for the local bus. A designated connector 1707. Connector 1709 is used to couple boards 5 and 1690 to the motherboard.

In FIG. 41C, board 4 1715 shows a connector 1716-1723 designated for one set of FPGA interconnects, a connector 1724-1731 designated for another set of FPGA interconnects, and a connector designated for the local bus. (1732,1733). Connector 1709 is not used to directly couple board 41715 to the motherboard. This configuration is shown in FIG. 38B in which 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 shows connectors designated for one set of FPGA interconnects (1741-1748), connectors designated for another set of FPGA interconnects (1749-1756), and connectors designated for the local bus. (1757,1758). Connector 1959 is used to couple board 3 1740 to the motherboard.

In FIG. 41E, board 2 1765 shows a connector 1762-1733 designated for one set of FPGA interconnects, a connector 1774-1781 designated for another set of FPGA interconnects, and a connector designated for the local bus. (1782,1783). Connector 1784 is not used to directly couple 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 11791-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. Because board 1 1790 is located as one of the boards at the end of the motherboard (along board 1 1660 of FIG. 41A at the other end), connectors 1805, 1807, 1808, 1810 are specific north-south. Designated as 10µR-packs for interconnects.

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 of another 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 allow the FPGA interconnect buses to be coupled together.

Similarly, local buses on two boards are joined together via local bus connectors. The local bus 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 can be added with the solder side on the component side of the second board. Similarly, FPGA interconnect and local bus in-board access 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 on the solder side of the dual board configuration will be described with reference to FIG. 38A. The figure illustrates a side view of an FPGA board access 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. The component side of boards 1525 and 1526 is indicated by reference numeral 1988. The solder side of the two boards 1525 and 1526 is 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. PCI signals are 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 through the motherboard connector 1523 from a power supply (not shown).

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

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

Moreover, connectors 1531A-1531B are internal-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 devices and the FPGA I / O controller (CTRL_FPGA) unit.

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 the other 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 FIG. 38A in which all other boards are directly accessed with the motherboard and the interconnects and local buses of these boards are joined together through an inner-board connector placed at the solder-side to the 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 internal-board connectors enable communication between PCI bus components, FPGA logic devices, memory devices, and various simulation system control circuits. The first set of inner-board connectors 1990 corresponds to connectors J5-J16 of FIG. 42. The second set of inner-board connectors 1991 corresponds to connectors J17-J28 of FIG. 42. The third set of inner-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 with power and ground. The center-to-center spacing between adjacent motherboard connectors is approximately 20.32 mm in one embodiment.

For the 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 are on the component side. Are located on the solder side, and the local bus connectors J3-J4 are 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 the end boards 1526 (first board) and 1535 (sixth board), the pair of connectors J17-J28 are 10 Ω R-pack terminals.

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 through a connector without a backside. 40A shows two exemplary boards 1611 (board 2), 1610 (board 1). The component side of the board 1610 abuts the solder side of the board 1611. Board 1611 includes various FPGA logic elements, other components, and wire lines. Specific nodes of the logic element 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 elements, other components, and wire lines. Specific nodes of the logic elements and other components on board 1610 are denoted by Node A (reference numeral 1613) and Node B (reference numeral 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 (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 asymmetrical interconnects include NH-SH interconnects 1577, 1579, 1581 on both sides of connectors 1589-1590.

A-A 'and B-B' correspond to symmetrical interconnects such as interconnects 1515 (N, S), while N and S interconnects use through-hole connectors, while NH and SH asymmetric interconnects Use SMD connectors. 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. The component-side connector pad 1636 couples to the solder-side connector pad 1639 via a 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 through 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, unique inner-board connection means are provided using surface mount and through hole connectors without using switching components.

F. Timing-Insensitive Glitch-Free (TIGF) Logic Devices

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

The above mentioned retention time problem is briefly explained. As is known, a common problem in logic circuit design is a retention 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 retention time changes from one logic element to the next, but is not always specified in 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 remain stable for a holding 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 value at the input of the flip-flop 2401 (logic 1 at the input D ₂ and the flip-flop 2402 (logic 0 at the input D ₃ ) has a hold time condition. The shift is stored or stored in the next flip-flop in the next clock cycle, assuming that 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 reaches all the logic elements almost simultaneously or substantially simultaneously. The circuit is designed such that the clock skew, or time difference, between clock signals arriving at 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 holding time violation is due to the clock signal arriving at flip-flops 2400-2402 at different times, causing some flip-flops to be 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 reconfigurable logic (FPGA) implementations of the same shift register design, if the clock is generated directly from the primary input, the circuitry allows a low skew network to distribute the clock signal to all logic elements such that the logic elements are clocked substantially simultaneously. It can be designed to detect 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, then the hold time becomes more important. The derivation or gate clock is generated from the 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 prevention or further control, the clock signal can reach each logic element at a different time and the clock skew can 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 holding time violation is described. However, at this time, individual flip-flops of the shift register circuit are arranged for the various 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 this example, the internally generated clock signal CLK is provided to flip-flops 2400-2402 of the shift register circuit. Chip 2412 includes flip-flops 2400, chip 2415 includes flip-flops 2401, and chip 2416 includes flip-flops 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 other obtained clock input) to generate an internal clock signal CLK. The internal clock signal CLK is sent to chip 2412 and labeled CLK1. Internal clock signal CLK from clock logic 2410 is also sent to chip 2415 and labeled 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 are 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 the flip-flop 2400 of the 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 detected at flip-flop 2400, the input at D ₁ must be stable for the required holding time H ₂ (up to time t ₄ ). At this time, the flip-flop 2400 shifts or stores to the input logic 1 such that the output at Q ₁ (or D ₂ ) is logic 1.

While this occurs in flip-flop 2400, clock signal CLK2 proceeds to flip-flop 2401 on 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. As a result, a hold time violation occurs when some preventive measures are not implemented, as shown in FIG. 76A, when a 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 retention 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 the exclusive OR 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 at the time it reaches flip-flop 2420.

Flip-flop 2421 receives data input at D ₂ on line 2426 and outputs data at Q ₂ on 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 no clock glitches are produced, or at least the 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 the glitches and will not affect the rest of the circuit.

Two known solutions to the retention time violation problem are (1) timing adjustment and (2) timing resynthesis. 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 retention time of the logic elements. For example, adding a sufficient delay on inputs D ₂ , D _{3 in} the shift register circuit can prevent a holding time violation. 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 no hold time violation occurs.

A potential problem with timing adjustment solutions is that they rely too much on the spec sheet of the FPGA chip. As is known to those skilled in the art, reconfigurable logic chips, such as FPGA chips, implement logic elements with look-up tables. The delay of the look-up table in the chip is provided in the spec sheet and the designer relies on this specific time delay using a timing adjustment method that prevents a hold time violation. 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 an impossible task, 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 resynthesis introduced in IKOS's VirtualWires technology. The timing resynthesis concept involves transforming a user's circuit design into a functionally identical design during finite state machines and registers during tight control of the timing of the clock and pin-out signals. Timing resynthesis 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 a flip-flop-based single-clock synchronous design. Thus, timing resynthesis uses registers at the input and output pin-out of each chip to control elaborate internal-chip signal movement such that no internal-chip hold time violations occur. Timing resynthesis also uses each chip's finite state machine 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 resynthesis 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. First finite state machine 2438 is also coupled to register 2443 via line 2449. Register 2443 and first finite state machine 2438 are controlled by a design-independent global reference clock.
The CLK signal is also conveyed to chips 2432 and 2433 before reaching chip 2434. In chip 2432, second finite 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 finite state machine 2441 that controls register 2446 via line 2464. The register 2446 outputs the CLK signal to the chip 2434.
Chip 2431 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 finite state machine 2439 controls register 2444 through line 2451, register 2466 through line 2455, and flip-flop 2436 through latch enable line 2453. To control. The fourth finite state machine 2439 also receives the original clock signal CLK from the chip 2430 via line 2450.
Chip 2434 includes 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 finite state machine 2439 controls register 2447 through line 2459 and flip-flop 2437 through latch enable line 2458. The fifth finite state machine 2442 also receives the original clock signal CLK from the chip 2430 via the chips 2432 and 2433.
Using timing resynthesis, finite state machines 2438-2442, registers 2443-2447, 2466, and a single global reference clock are used to control signal flow and update internal flip-flops for multiple chips. Thus, at chip 2430, distributing the CLK signal to other chips is scheduled by first finite state machine 2438 via register 2443. Similarly, at chip 2431, fourth finite state machine 2439 passes input S _in to flip-flop 2436 through register 2444 and Q ₁ output through register 2466. Schedule it. The latching function of flip-flop 2436 is also controlled by the latch enable signal from fourth finite state machine 2439. The same principle applies to logic in other chips 2432-2434. Using the internal-chip input delivery schedule, internal-chip output delivery schedule, and strict control of internal flip-flop status update, internal-chip hold-time violations are eliminated.
However, timing resynthesis techniques require the user's circuit design to be transformed into mostly functionally identical circuits, including finite 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 glitches, designers must take additional precautionary steps using timing resynthesis techniques. One conventional design approach is to design a circuit such that the input of a logic device using a 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 resynthesis requires some additional untried means to avoid clock glitches.

delete

delete

delete

delete

delete

delete

Various embodiments of the present invention that address the retention 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 glitch-free (TIGF) latch in accordance with one embodiment of the present invention. Similarly, the flip-flop design shown in FIG. 18B is emulated with a timing insensitive glitch-free (TIGF) latch in accordance with one embodiment of the present invention. TIGF logic elements in the form of latches or flip-flops may also be referred to as emulation logic elements. Updates of TIGF latches and flip-flops are controlled by global trigger signals.
In one embodiment of the invention, not all logic elements found in the user designed circuit are replaced by TIGF logic elements. 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 element is controlled by a gate or an obtained clock, only a particular logic element 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 elements found in the user designed circuit are replaced with TIGF logic elements.
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) for the evaluation period and to update the state (new input) for a 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 evaluation period followed by a short trigger period. The global trigger signal traces the EVAL signal during the evaluation 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, which has one logic state (logic 0) during the evaluation period and another logic state (logic 1) during the non-evaluation or TIGF latch / flip-flop update period. Have

delete

delete

The evaluation cycle described with reference to the RCC computing system and the RCC hardware array is used to run all primary inputs and the flip-flop / latch device transforms the simulation cycle at any time into a full user design. During the 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 cycle is design specific. That is, the evaluation cycle for one user design may be different from the evaluation cycle 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 design circuit during the evaluation period. A short trigger period, indicated by a change in the logic state of the EVAL signal, according to one embodiment of the present invention, can be updated with all TIGF latches and flip-flops in the user design so that they can be updated with new values propagated from the evaluation period after the steady state is reached. To control. 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 ₀ to t ₁ ). During a short trigger period, a new primary input is sampled for every input stage of TIGF latches and flip-flops, and previously stored values of the same TIGF latches and flip-flops are exposed to the next stage of the user-designed RCC hardware model. 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, TIGF trigger signal, trigger signal, or simply a trigger.

delete

FIG. 80A shows the latch 2470 previously 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.

delete

delete

delete

Since this latch is level-sensitive and asynchronous, the output Q traces 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 interconnects.
D flip-flop 2471 receives the input of D flip-flop 2471 from the output of AND gate 2474 over 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 other input of multiplexer 2472 is connected to TIGF latch D input on line 2475. 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 through 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 one input of AND gate 2474 via line 2481. The other input of AND gate 2474 is connected to a reset (R) signal on line 2482. 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 feed back a new input signal of TIGF latch to D flip-flop 2471 on line 2476, so line 2476 is 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. In the event of a situation that typically causes a hold time violation of the circuit used in the &lt; RTI ID = 0.0 &gt; introduced &lt; / RTI &gt;
The trigger signal is distributed through a low skew global clock network.
This TIGF latch also solves the clock glitch problem. Note that the clock signal is replaced by the enable signal in the TIGF latch. The enable signal on line 2484 often causes glitches 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.

delete

delete

delete

delete

delete

delete

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 (+ edge of CLK), Q ← D
else Q retains the previous value.

delete

delete

delete

delete

Because this latch is edge-triggered, while the flip-flop enable input is enabled, the output (Q) follows the input (D) at the positive 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 clock input, a set S, a reset R, 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 interconnects.
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 via line 2505 to one of the inputs of OR gate 2494. The other input of OR gate 2492 is the set (S) signal on line 2506. The output of OR gate 2494 is connected via line 2507 to one of the inputs of AND gate 2495. 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 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 over 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.
The TIGF flip-flop stores 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 of line 2513 of D flip-flop 2496.

delete

delete

delete

delete

delete

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. Thus, before the evaluation period of each TIGF flip-flop, a new value is stored in the D flip-flop 2491. Thus, the TIGF flip-flop can avoid holding time violations by pre-storing new values 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 cycle. 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 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 emulated TIGF flip-flop. In the user-designed hardware model, this output is changed according to any clock glitches before the entire propagated signal reaches steady state. Thus, an input on line 2501 will represent the 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 glitch.

delete

delete

In addition, TIGF flip-flops also provide immunity to clock glitches. 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 glitch does not affect any circuit using this TIGF flip-flop. Referring to Figures 77 (A) and 77 (B), because of the flip-flop 2423 clocked to a new value but not clocked to a new value for a time between times t ₁ and t ₂ , the clock glitch is shown in Figure 77. It adversely affects the circuit of (A). The skew characteristics of CLK1 and CLK2 cause 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 glitch does not affect the clocking of the new value. If 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 flip-flop 2491 (Figure 91). (B)). Next, any clock glitch such as the clock glitch in 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 cycle 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

A 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 hardware 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 a reconfigurable hardware unit for acceleration and hardware state swapping purposes. Once acceleration is achieved or a 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 multiple times for the "task" to end. In the other extreme case where a slice is required, the "work" is a subset of the "process". Thus, if a "process" requires multiple time slices for execution terminated due to the presence of other equal priority users / processes, the "process" is divided into "tasks". Also, unless a "process" requires multiple time slices for terminated execution because the only high priority user or process is short enough to terminate 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, each "process" may require one or more "tasks" to terminate 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 work in a non-network environment. The station can be used. 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 the scheduler determines access priorities for multiple users, swaps tasks, and selectively locks hardware unit access among the scheduled users. In other cases, multiple users may access the same reconfigurable hardware unit using separate, different user-designed 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, access is achieved through a time sharing process in which the scheduler determines access priorities for multiple users, swaps tasks, and selectively locks hardware unit access among scheduled users. In a network environment, the scheduler receives network requests through UNIX socket system calls. The operating system uses sockets to send 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 finishes work and ends the session. Among the same priority users or processes, a preemptive round robin algorithm is used in which the operation is executed until the same time slice is assigned to each user or process and terminated. 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 is swapped out by interrupting one user or process and sufficient actions are 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 allocating resources for various users, processes, and devices in 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 through the bus for memory through a crossbar switch. Thus, multiple processes can be run by multiple microprocessors that execute respective instructions and access memory without going through the local bus. 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.

The scheduler 1117 provides time sharing access to the reconfigurable hardware unit 20 via the device driver 1119 and the 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 task interruptions 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 receives the network request through the socket system and makes a system call to the operating system 1121, which in turn is interrupted by the device driver 1119 to the reconfigurable hardware unit 20. Address preemption by initiating signal generation. One of a number of steps for scheduling algorithms that involve generating such an interrupt signal includes stopping the current task, storing state information about the currently interrupted task, swapping the task, and executing a new task. do. 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 a CPU to a process for a time period (e.g., 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. These three layers include a socket layer, a protocol layer, and a device layer. The upper layer, the socket layer, provides the interface between the system requests 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, contains device drivers that control the network devices. An example of a device driver is an Ethernet driver on an Ethernet based network.

Processes communicate using a client-server model in which a server process receives a socket at one endpoint and a client process receives a server process on another socket at another endpoint 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 system calls include a connect system call request where the kernel is connected to a socket, a close system call closes a socket, a shutdown system call closes a socket connection, and a send and receive system. 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. Multiple workstations are connected to the simulation system through the scheduler 1117. 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, operating system 1118 is provided and almost all 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. Scheduler 1117 controls time sharing access to user stations 1111, 1112, 1113 by making a socket call to 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 through a remote station 1111, 112, or 1113. Remote user stations 1111, 112, and 1113 are connected to scheduler 1117 via network access 1114, 1115, and 1116, respectively.

As is known to those skilled in the art, a device driver 1119 is accessed between the PCI bus 50 and the reconfigurable hardware unit 20. An access or electrically conductive path 1120 is provided between the device driver 1119 and the reconfigurable hardware unit 20. In this network multi-user implementation of the present invention, the scheduler 1117 communicates with and controls the reconfigurable hardware unit 20 for hardware acceleration and simulation after hardware state recovery purposes. 1119).

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 the memory via the local bus, the Sun 450 system allows the multiprocessor to access the memory by means of a dedicated bus to the memory through the crossbar switch on behalf of the local bus.

47 illustrates a high level structure of the simulation server according to the 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 end circular 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 jobs are executed first for termination. In the extreme case, if different users each have a different priority, the user with the highest priority is served first until the end of his work, 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 provides services to the user according to the priority. This scenario is similar to having only one user accessing the simulation system until termination.
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 ends or the fixed time slice ends. If a task is not completed during the time slice, the simulation image associated with any task that is completed should be saved for later recovery and execution. Next, this job is placed at the end of the queue. If a saved simulation image exists, the next task is restored and executed at the next time slice.
High priority jobs can preempt low priority jobs. That is, jobs of the same priority are operated in a round robin fashion until executed over time slices for termination. Next, lower priority tasks are run in a round robin fashion. If a high priority job is put in the queue while a low priority job is running, the high priority job preempts the low priority job until the high priority job ends. Thus, the high priority task ends execution before the low priority task begins execution. If the low priority task has already started executing, the low priority task is not terminated further until the high priority task has finished executing.

delete

delete

delete

delete

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 for 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 scheduling algorithm of the operating system.
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 request simulation tasks to be simulated on the server through UNIX socket calls from client application programs.
In one embodiment of the present invention, a typical series of events includes multiple clients delivering requests to the server via the UNIX socket protocol. For each request, the server recognizes 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.

delete

delete

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 example 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. Thus, users / processes 1147, 1148, and 1149 are connected to the simulation server 1140 through 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 a 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 swapper 1144, a device driver 1145, and a reconfiguration. And a flexible hardware unit 1146. The simulation job queue table 1142, priority classifier 1143, and job swapper 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 swapping efficiency. Other usage features include compiling 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. 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 one embodiment, the priority level may be modified based on the urgency of a particular process or the importance of a particular user. 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.

Task swapper 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, the task swapper is swapped in the saved simulation state only during the simulation session. However, if multiple users simulate multiple designs, the task swapper loads into the hardware structural design before swapping in the simulation state. In one embodiment, the task swapping mechanism improves the performance of the time sharing embodiment of the present invention because task swapping should only be done for reconfigurable hardware unit access. Thus, if one user needs software simulation for some period of time, the server will alternate to another task for the other user so that the other user can access the reconfigurable hardware unit for hardware acceleration. The frequency of task swapping is user adjustable and programmable. The device driver also communicates with the reconfigurable hardware unit to swap tasks.
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 dormant. If the system is dormant at step 1160, the simulation server does not need to be inactive and the simulation job is not running. A dormant 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 or only one process is running. Thus, conditions 2 and 3 above have only one job to be processed by the simulation server so that job queuing, prioritization, and job swapping are not required and are essentially required from other workstations or processes. The simulation server is dormant because it does not receive (event 1161).
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 queues the incoming simulation task or tasks at step 1162. The scheduler maintains a simulation work queue and lists 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.

delete

delete

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 task swapper swaps in the saved simulation state only during the simulation session. However, if multiple users simulate multiple designs, the task swapper first loads the designs prior to swapping in the simulated state. Here, the device driver also communicates with the reconfigurable hardware unit to swap tasks.
In one embodiment, the task swapping mechanism improves the performance of the time sharing embodiment of the present invention because task swapping 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 swapped into different tasks for other users so that the other users 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 swapped for a task 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 the reconfigurable hardware unit for acceleration, Preempts the task for user 2 so that the task for user 1 can be swapped 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 the execution of the current simulation task, which is excessively time consuming and allows the system to determine if other progress tasks of the same priority should gain access to the reconfigurable hardware model. Because it is determined.
At the end of the task swapping 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 the end of the simulation or the occurrence of a break in the current simulation session at event 1166, the server returns to priority classifier step 1163 to later determine the priority of the current simulation task and later swaps 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 task 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 cases is when the system is currently running a simulation-intensive simulation task, in which case the scheduler can be programmed to preempt the ongoing task to schedule tasks of equal 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 swaps the ongoing task even if it is at the priority level.
50 is a flowchart of a task swapping process. The task swapping function is performed in step 1164 of FIG. 49 and is shown in the simulation server hardware as the task swapper of FIG. In FIG. 50, if the simulation task needs to be swapped with another simulation task, the task swapper sends an interrupt to the reconfigurable hardware unit in step 1180. If the reconfigurable hardware unit is not currently doing any work (that is, if the system is dormant or the user is operating in software simulation mode without hardware acceleration intervention only), the interrupt is immediately reconfigured for task swapping. Prepare a scalable hardware unit. However, if the reconfigurable hardware unit is currently executing a task and is executing instructions or processing data, the interrupt signal is recognized but the reconfigurable unit executes the instruction currently in progress and retrieves data for the current task. Process. 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.
At 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.
At step 1182, the simulation system configures the reconfigurable hardware unit with a 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 simulated image for the new task is appropriately different from the simulated image for the interrupted task, the simulation system is 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, the simulation can be initiated for this new task, but the previously interrupted task can only proceed in software simulation mode because there is no access to the reconfigurable hardware for the time being.
51 shows signals between the device driver and the reconfigurable hardware unit. The device driver 1171 provides an interface between the scheduler 1170 and the 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. Signals between the device driver and the reconfigurable hardware are bidirectional communication handshake signals, unidirectional design configuration information from the computing environment to the reconfigurable hardware unit via the scheduler, information swapped to the simulation state, and swapped from the simulation state. Simulation tasks can be swapped, including information and interrupt signals from the device driver to the reconfigurable hardware unit.
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 transmits 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 swapped with simulation state information to reconfigurable hardware unit 1172. Line 1176 is swapped in the simulation state information from the reconfigurable hardware unit to the computing environment (ie, usually memory). The information swapped into the simulation state includes previously stored hardware model state information and a hardware memory state in which the reconfigurable hardware unit 1172 needs to be accelerated. The swapped state information is transmitted at the beginning of time so that the scheduled current user can access the reconfigurable hardware unit 1172 for acceleration. The swapped state information includes memory state information that must be stored in memory at the end of the time slice at the reconfigurable hardware unit 1172 that receives the interrupt signal to move to the next time slice associated with a different user / process than the hardware model. do. The storage of state information allows the user to recover this state at a later time, such as the next time slice assigned to the current user / process.
Line 1177 transmits an interrupt signal from device driver 1171 to the reconfigurable hardware unit so that simulation work can be swapped. This interrupt signal is swapped between time slices to cause the current time slice to be swapped from the current time slice to the new simulation task.
A communication handshake protocol according to an embodiment of the present invention will be described with reference to FIGS. 53 and 54. 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 diagram of the communication handshake signal between the device driver 1171 and the reconfigurable hardware unit 1172.

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

In FIG. 53, a handshake logic interface 1234 is provided to the 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 COMMAND 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 the reconfigurable hardware unit in an appropriate mode for the various operations in which these signals 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: an REG space is assigned to a register component; CLK space is designated by software clock; The S2H space is designated as the output to the hardware model of the software test-bench component; 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 time.

The following table G describes each SPACE signal.

Table G: SPACE Signal

SPACE Explanation 000 Hardware (DMA wr) in global (or CLK) space and software 001 Register write (DMA wr) 010 From hardware to software (DMA rd) 011 Register read (DMA rd) 100 SRAM Write (DMA wr) 101 SRAM Read (DMA rd) 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 end 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 the 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 dormant. Unless a new command is displayed, the system sleeps as indicated by 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 the 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 in 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 that handles 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 the 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 execution 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. Task D takes over at time 1197 and finishes running until time 1198.
VIII. Memory simulation
Memory simulation or memory mapping in accordance with one embodiment 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 means 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 element in which a user design is implemented and an SRAM memory element 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 supporting the simulation system, which resides 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 includes transferring data from an FPGA logic element (and an FPGA SRAM memory element for initialization and memory content dump) to a host computing system. DMA write transfers include data transfers from a host computing system to FPGA logic devices (and FPGA SRAM memory devices for initialization and memory content dump).
The "FPGA data bus", "FPGA bus", "FD bus" and their analogy refer to the high bank bus FD [63: 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 control and interface 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.

delete

delete

delete

delete

delete

delete

delete

delete

The FPGA logic element 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 Devices and SRAM Memory Devices. With respect to the FPGA logic device side, the FPGA I / O controller side includes (1) the main computing 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 and SRAM memory devices; Contains a memory state machine.
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). The DATAXSFR signal represents a DMA data transfer period, where the computing system and the SRAM memory unit are each different through an FPGA bus (high bank bus (FD [63:32]) 1212 and low bank bus (FD [31: 0]) 1213. Send data to the device.
During the evaluation cycle, the logic circuitry in each FPGA logic device generates the appropriate software clock, input enable, and MUX enable signals for user-designed logic for data evaluation. Internal-FPGA logic device communication occurs during this period.
During the memory access period, the memory simulation system waits for the high and low bank FPGA logic elements to send each address and control signal to each FPGA data bus. This address and control signal is latched by the CTRL_FPGA unit. If the operation is a write operation, address, control, and data signals are transferred from the FPGA logic element to each SRAM memory element. 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 transferred 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 completed, and the memory simulation system waits until the next memory simulation write / read cycle begins.
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 aforementioned CTRL_FPGA unit 1200 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 with 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 element and a memory element. 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. Logic elements include 1201 (FPGA1), 1202 (FPGA3), 1202 (FPGA0), and 1204 (FPGA2). The SRAM chip includes a low bank memory element 1205 (L_SRAM) and a high bank memory element 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 elements 1201 (FPGA 1) and 1202 (FPGA 2) are connected to high bank bus 1212 through 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 the bus 1220 and the low bank memory device 1205 is connected to the low bank bus 1213 via the 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.

delete

delete

delete

delete

delete

delete

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 elements 1201 through 1204 and the host computer are performed on PCI buses (eg, bus 50 in FIG. 46), local buses 1210 and 1236, and FPGA bus 1212 (FD [63:32]). And 1213 (FD [31: 0]). Memory elements 1205 and 1206 cause DMA data transfer for initialization and memory content dump. Evaluation data transfer between logic elements 1201 through 1204 in the reconfigurable hardware unit is through the interconnect and FPGA bus 1212 (FD [63:32]) and 1213 (FD [31: 0]). Memory access between logic elements 1201-1204 and memory elements 1205, 1206 is through 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. 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. CTRL_FPGA unit 1200 also provides memory address signal MA [18: 2] over bus 1229 and 1214 to low bank memory device 1205 and high bank memory device 1206, respectively. To control the mode of this memory device, CTRL_FPGA unit 1200 provides chip select write (and read) signals to low bank memory device 1205 and high bank memory device 1206 via lines 1216 and 1215. To indicate the end of the DMA data transfer, the memory simulation system may send and receive the DONE signal on line 1209 to the CTRL_FPGA unit 1200 and the computing system.

As described above with respect to FIGS. 9, 11, 12, 14, and 15, logic elements 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 ends through a set of chains, the final logic element generates a LAST signal (ie, LASTL or LASTH) and sends it to CTRL_FPGA unit 1200. For the high bank, logic element 1202 generates a LASTH shiftout signal on line 1218 and sends it to CTRL_FPGA unit 1200. For the low bank, the logic element 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 elements 1201-1204, memory elements 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 elements (two for each bank), two memory elements (one for each bank), and a bus are provided on one board. The second board contains complementary logic elements (typically four), memory elements (typically two), an FPGA I / O controller (CTRL_FPGA unit) and a bus. However, the PCI controller is only installed on the first board. The above-described internal-board connectors are provided between the boards so that logic elements on all boards can be connected 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 not for multiple boards.
In a board implementation, the simulation system performs memory mapping between logic elements and memory elements on each board. No memory mapping is performed between the different boards. Thus, logic elements on board 5 map memory blocks to memory elements on board 5, but do not map to memory elements on other boards. However, in another embodiment of the present invention, the simulation system may map memory blocks from logic elements on one board to memory elements 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 the end 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 elements 1201 through 1204 are FPGA data buses, high bank buses (FD [63:32]) 1212 and low bank buses. Data is transmitted to another device via (FD [31: 0]) 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 elements 1205 and 1206.
During the evaluation period, the logic circuit of each FPGA logic element 1201-1204 generates a software clock, input enable, and MUX enable signal appropriate 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 termination.
During the memory access period, the memory simulation system waits for the high and low bank FPGA logic elements 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, the address, control, and data signals are sent from the FPGA logic elements 1201 through 1204 to the SRAM memory elements 1205 through 1206, respectively. If the operation is a read operation, address and control signals are sent from the FPGA logic elements 1201-1204 to the SRAM memory elements 1205-1206, respectively, and the data signals are sent from the SRAM memory elements 1205, 1206, respectively. Is sent to 1201-1204. 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 placed on the FD bus for the memory block. If the operation is a read operation, a double buffer latches data for the memory block on the FD bus from the SRAM memory element. This operation is performed sequentially for each memory block of each FPGA logic device. When all the desired memory blocks of the FGPA logic element have been accessed, the memory simulation system performs the next FPGA logic element in each bank and begins accessing the memory block of the FPGA logic element. After all desired memory blocks in all FPGA logic elements 1201-1204 have been accessed, the memory simulation write / read cycle ends, and the memory simulation system waits until the start of another memory simulation write / read cycle.

delete

delete

delete

delete

FIG. 57 shows a block diagram of a memory simulation in accordance with the present invention, including a more detailed structural diagram of each logic element associated with CTRL_FPGA unit 1200 and memory simulation. 57 shows CTRL_FPGA unit 1200 and logic element 1203 (which is structurally similar to other logic elements 1201, 1202, 1204). The CTRL_FPGA unit 1200 includes a memory finite state machine (MEMFSM) 1240, an AND gate 1241, an evaluation (EVAL) counter 1242, a low bank memory address / control latch 1243, a 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 element, such as logic element 1203 shown in FIG. 57, includes an evaluation finite state machine (EVALFSMx) 1248, a data bus multiplexer (FDO_MUXx for FPGA 0 logic element 1203) 1249. "X" marked at the end of the EVALFSM represents the relevant specific logic elements (FPGA 0, FPGA 1, FPGA 2, FPGA 3), in the present embodiment "x" is 0, 1, 2, 3. Thus, EVALFSM 0 is associated with the FPGA 0 logic element 1203. In general, each logic element is associated with the same number x, and " x " represents 0 to N-1 when N logic elements are used.
In each logic element 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 element. Memory block interface 1253 also provides memory write data on bus 1295 to be transmitted to FPGA data bus multiplexer (FDO_MUXx) 1249 and memory on bus 1297 from memory read data double buffer 1251. Receive read data.
Memory block data / logic interface 1298 is provided to 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]. The memory block data / logic interface 1298 includes a memory read data double buffer 1251, an address offset unit 1250, a memory model 1252, and a memory block interface 1253 (mem_block_N) for each memory block N (mem_block_N). These are all repeated for a given FPGA logic element 1201-1204 for each memory block N). Thus, for five memory blocks, five sets of memory block data / logic interfaces 1298 are provided. That is, five sets of memory read data double buffers 1251, an address offset unit 1250, a memory model 1252, and a memory block interface 1253 for each memory block N (mem_block_N) are provided.

delete

delete

As with EVALFSMx, "x" in FDO_MUXx refers to the specific logic elements 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 has a high bank bus FD [depending on which chip (FPGA 0, FPGA 1, FPGA 2, FGPA 3) is associated with FDO_MUXx 1249. 63:32] or low 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]. Portions of bus 1283 are used to transfer read data from high bank FD [63:32] or low bank FD [31: 0] buses to read bus 1283 for input to memory read data double buffer 1251. do. Therefore, write data is transferred from the memory block of each logic element 1201 to 1204 through the FDO_MUX0 1249 to the high bank FD [63:32] or low bank FD [31: 0] buses, and the read data is read from the read bus ( 1283 is transferred from the high bank FD [63:32] or low bank FD [32: 0] buses to the memory read data double buffer 1251. The memory read data double buffer provides a double buffered mechanism to latch data in the first buffer, and is buffered 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 can also be unique for the user design. For example, the user's memory type may be DRAM, flash memory, or EEPROM. However, in all the various memory block interfaces 1253, memory addresses 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, the memory address and control signals are provided on bus 1296 and sent to memory model 1252 to perform the conversion.
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 corrected 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 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 uses space 0-2K and can be present here, while the second memory block uses space from 2K to 5K and can be present here. The offset address from offset unit 1250 and the control signals on bus 1292 are combined, 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 spatial indices. The SPACE index generated by the FPGA I / O controller (reference numeral 327 in FIGS. 10 and 22) selects a particular address space (e.g., 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 represents a dedicated memory space for DMA read transfer of hardware-software H2S data. SPACE3 represents a dedicated memory space for 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 generate SPACE2 data on bus 1289, SPACE3 data on bus 1290, address / control signal on bus 1299, and memory on bus 1295. A predetermined output is selected from among a plurality of outputs from the recording data. The generation of the selection signal by the EVALFSMx unit 1248 is described below.
The EVALFSMx unit 1248 is the heart of the operation of each logic element 1201 through 1204 with respect to the memory simulation system. The EVALFSMx unit 1248 receives as inputs 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, 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 the FPGA logic elements 1201 to 1204 for the memory simulation system according to the present invention will be described. When the EVAL signal is logic 1, data evaluation is performed within the FPGA logic elements 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 multiplex signal for data, latch related data, and logic elements, 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 software 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 transmitted 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 elements 1201-1204 include at least one memory block, the memory simulation system waits for the selected data to be shifted to the selected FPGA logic element, and the address of memory block interface 1253 (mem_block_N) on the FD bus. Generates a select signal and an output_en signal for the FPGA data bus driver to transmit control signals.

delete

delete

delete

delete

delete

delete

delete

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 element 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 dual buffer 1251 depending on which bank the FPGA chip is connected to. The read latch signal rd_latx on 1286 latches and double buffers the selected data from the SRAM via the low bank or high bank bus. The wrx signal is a memory write signal sent from the memory interface of user designed 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 in 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 element in the chain. Memory accesses to devices on the high and low banks are performed in parallel. Occasionally, memory access to one bank may end 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.

delete

On the CTRL_FPGA unit 1200 side, the 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 active of the memory simulation write / read cycle, so that various operations are controlled by the cycle. MEMFSM 1240 receives DATAXSFR signal on line 1260 over line 1258. The signal is also provided to each logic element on line 1273. When DATAXSFR goes low (ie, logic low), the DMA data transfer cycle ends and the evaluation and memory access cycle begins.

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 element (e.g., logic elements 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 element 1203), the corresponding LAST signal is a SHIFTOUT signal on line 1280. Since the particular logic element 1203 is not the last logic element in the low bank chain as shown in FIG. 56 (logic element 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 element 1204 (see FIG. 56). Similarly, the SHIFTIN signal on line 1280 represents Vcc for the FPGA0 logic element 1203 (see FIG. 56).
The LASTL and LASTH signals are input to AND gate 1241 through lines 1256 and 1257, respectively. AND gate 1241 provides an open drain. 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 the end 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 elements 1201 through 1204 perform inter FPGA communication to evaluate data in the user design. The output of the EVAL counter 1242 is fed back on 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 end of the evaluation period.

delete

delete

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. Essentially, the MEM_EN signal is a control signal from the CPU that enables the on-board SRAM memory device to access the FPGA logic device. Here, the MEMFSM unit 1240 waits for the FPGA logic elements 1201-1204 to place address and control signals on the FPGA buses FD [63:32] and FD [31: 0].

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

The memory address / control latch 1243 for the row bank receives an address and control signal and a latch signal 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 provides an address / control signal received from FPGA bus FD [31: 0] to address / control mux 1244 via 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. The address / control mux 1244 outputs address / control information on the bus 1276 and transmits it to the low bank SRAM memory device 1205. The select signal on line 1265 provides an 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.
The address counter 1245 receives information from SPACE4 and SPACE5 over the 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 elements 1205, 1206) over the PCI bus. The address counter 1245 provides its output to the buses 1288 and 1268 and sends them to the address / control mux 1244 and 1246. Providing an appropriate select signal on line 1265 for the low bank, address / control mux 1244 provides bus 1266 for read / write memory access between SRAM device 1205 and FPGA logic elements 1203 and 1204. Address / control information on the bus or alternatively DMA write / read transfer data from SPACE4 or SPACE5 on bus 1276 is provided on bus 1276.
During the 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, bus 1266. The address / control signal on is sent to the low bank SRAM on bus 1276. Thereafter, write data transfer occurs from the FPGA logic element to the SRAM memory element. 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 FPGA bus FD [31: 0] transmitted 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.

delete

delete

delete

Similar configurations and operations are provided for the high bank. 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 from FPGA bus FD [63:32] to address / control mux 1246 over bus 1239.

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

The address counter 1245 receives information from SPACE4 and SPACE5 via bus 1267, similar to the DMA write and read transfer described above. The address counter 1245 provides its output to the buses 1288 and 1268 for transmission to the address / control mux 1244 and 1246. By providing the appropriate select signal on line 1269 for the high bank, address / control mux 1246 is an address on bus 1239 for read / write memory access between SRAM device 1206 and FPGA logic elements 1201 and 1202. Control information or alternatively provides DMA write / read transfer data from SPACE4 or SPACE5 on bus 1267 on bus 1277.

During a 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 to address / control on bus 1239. The signal is sent to the high bank SRAM on bus 1277. Thereafter, write data transfer occurs from the FPGA logic element to the SRAM memory element. 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 elements and the high bank memory elements 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 end 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 desired. 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 element 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 a 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 in all memory blocks come in at different times, and the double buffer causes all data to be latched first. Once all data is latched into 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. When the clk_en signal appears, the latched data on line 1343 is buffered onto D flip-flop 1341 onto line 1344.

For the next memory block 1, another double buffer 1372 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 the input of a double buffer 1332 on line 1398 to a second D flip-flop (not shown). 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. The double buffered data output is 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 the other rd_latx signal 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.

delete

delete

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 ends, triggering the DONE signal to indicate the end of the DMA data transfer period. The XSFR_DONE signal is then generated and the EVAL cycle begins. When EVAL ends, 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 elements 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 ends, the DATAXSFR signal is returned to logic zero.

When the DATAXSFR signal returns to logic zero, the generation of a start signal is triggered in the MEMFSM unit in state 1302. The start signal starts the EVAL counter 1242, which is 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 at state 1303, an EVAL signal indicates logic 1 and is provided to the MELFSM unit 1240 and EVALFSMx in the FPGA logic device. When the count ends, the EVAL counter indicates that the EVAL signal is logic 0 and sends it to EVALFSMx in the MEMFSM unit 1240 and the FPGA logic element. 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 has ended and the memory access cycle has progressed. The CPU checks the 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 a dormant 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 element 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. To determine whether the simulation system requires a read operation or a write operation, the memory write signal mem_wr_L for the row 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 element to send more address and control signals on the FD [31: 0]. The process continues until the last data is shifted out of the FPGA logic device. However, if mem_wr_L = 1 and LASTL = 1, the last data is shifted out of the FPGA logic element.

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 FPGA logic elements is not shifted yet. Thus, the simulation system returns to state 1305, where the simulation system waits one cycle for the FPGA logic element 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) can be inserted 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 ends. 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 element 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. 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 signals. 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 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 elements is not yet shifted. Thus, the simulation system returns to state 1311, where the simulation system waits one cycle for the FPGA logic element to send more address and control signals on the FD [63:32]. The process continues until the last data is shifted out of the FPGA logic device. However, if mem_wr_H = 1 and LASTH = 1, the last data is shifted out of the FPGA logic element.

Similarly, if mem_wr_H = 0 indicating a read operation, the MEMFSM proceeds to state 1314. At 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 FPGA logic elements is not shifted yet. Thus, the simulation system returns to state 1311, where the simulation system waits one cycle for the FPGA logic element to send more address and control signals on the FD [63:32]. The process continues until the last data is shifted out of the FPGA logic device. The write operation (mem_wr_H = 1) and the read operation (mem_wr_H = 0) can be inserted or otherwise 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 ends. The simulation system then proceeds to the dormant state 1300 whenever DATAXSFR = 0.

Optionally, 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.

EVALFSMx unit 1248 receives the EVAL signal on line 1274 from CTRL_FPGA unit 1200 (see FIG. 57). When EVAL = 0, no data evaluation by the FPGA logic device is performed. Thus, in state 1320, EVALFSMx is dormant when 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 user design through FPGA logic devices. 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-designed 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 mentioned above, inter-FPGA wire lines are sometimes multiplexed to effectively utilize limited pin resources within each FPGA logic device chip.
In state 1324, EVALFSM is dormant while EVAL = 1. When EVAL = 0, the evaluation cycle ends and state 1325 requests EVALFSMx to turn on mux_en signal.

delete

If the number of memory blocks M (where M is an integer containing 0) is zero, EVALFSMx returns to state 1320 where it is dormant 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, then the right part (memory access period) of Figure 59 is implemented in the FPGA logic element. 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 terminates its memory access and the current FPGA logic device is ready to perform its memory access operation. Alternatively, if SHIFTIN = 1, the current FPGA logic element is the first logic element 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, so that memory accesses to specific memory blocks N can 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 sends a select 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 an output_en signal and send it to the FGPA bus driver FDO_MUXx (1249). If a write operation is requested, wr = 1. Otherwise, if a 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]. Thereafter, EVALFSMx waits one cycle for the SRAM memory device to end the write cycle. EVALFSMx then proceeds to state 1335 where memory block number N 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 dual 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 becomes 2, and 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 element in the bank is accessed to access the SRAM memory elements. Turn on the SHIFTOUT output signal to allow. EVALFSMx then proceeds to state 1320 where it is dormant until the simulation system requests data evaluation from the FPGA logic device (ie, EVAL = 1).

delete

delete

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 low bank SRAM will be different than high bank SRAM. For simplicity, FIG. 61 illustrates one access time for an ideal low or high bank. 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 the end 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 ends, 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 ends 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. The next FPGA logic element in the bank is now ready 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 related to the address and control signal on the FD bus are transferred to the SRAM memory device.

Thus, as shown in FIG. 61, the next FPGA logic element (logic element 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 allows 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 is placed on the MA [18: 2] / control bus. It requires time to make it possible. 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. As such, 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 at the address / 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 element, but rather the read data associated with AC1_1 may not be transferred to the SRAM for subsequent reading by the user design logic via the simulation memory block interface. The memory device is disposed on the FD bus. This is indicated by trace 1381 on the high bank. On the low 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 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 element 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 bank and the high bank can occur at different times and speeds and FIG. 61 shows a special example in which the timing for the low bank and the high bank are the same. In addition, write operations for the low bank and high bank occur together, followed by read operations on both banks. This is not always the case. The presence of a low bank and a high bank 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 element 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 has been accessed, the end 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 on 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. The two figures show 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 the end of the DMA write operation). As such, in Fig. 62, the DMA read operation occurs almost immediately after the end 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 end of the EVAL cycle.

At the beginning of the timing diagram, the EVAL_REQ_N signal experiences competition because many 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 multiple LAST signals (which come from the shift-in and shift-out signals at the output of each FPGA logic element) are 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 to 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 becomes active indicating the end 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 end of this DMA transfer operation, where the 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. During three clock cycles, the EVAL_REQ_N signal is processed through 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, that is, approximately two clock cycles after time 1412 (at the end of the DMA write operation), the CTRL_FPGA unit sends a write address strobe WPLX ADS_N signal to the PCI controller to begin the DMA read transfer. . 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 the generation of the EVAL_REQ_N signal from the FPGA logic elements, the PCI controller is responsible for the FPGA bus FD [63: 0] and local bus LD [31: 0]. Process the DMA read data by transferring data from the host computer system.
At time 1410, the DMA read data may continue to be processed, while the EVAL signal is deactivated and the EVAL DONE signal is activated to indicate the end of the EVAL cycle. Contention between FPGA logic elements also begins when they generate the EVAL_REQ_N signal.
At time 1417, just before the end 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 terminate 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 recognizes that the DMA cycle is almost complete. 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 cycle occurs at time 1416 when RD_XSFR is disabled and the DAM read data is no longer on FPGA bus FD [63: 0] or local bus LD [31: 0]. . The XSFR_DONE signal is also activated at time 1416 and competition between LAST signals for the generation of the DONE signal begins.

delete

delete

delete

During the entire DMA cycle 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 retention time of such a cycle is based on (1) overhead time for PCI controller time 2, (2) the number of words in WR_XSFR and RD_XSFR, and (3) the 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 element and the SRAM memory element 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. This happens after the CPU has finished 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 cycle 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 is deactivated.

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 begins after the EVAL_DONE signal is activated and almost terminates. It waits for the end of the EVAL cycle instead of starting immediately after the end of the DMA write operation. The EVAL signal is active (activated) for a preset time from time 1412 to time 1410. At time 1410, the EVAL DONE signal is activated (activated) to indicate the end 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 cycle. 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 approximately 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 chart is the same as in FIG.

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 the end of the EVAL period, and the DMA read operation is delayed. The RD_XSFR signal in FIG. 62 is present after the detection of the CLK_EN signal after the end of the DMA write transfer.

IX. COVERIFICATION SYSTEM

The joint validation 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 manufacturing and there are no limitations of emulator-based co-verification tools. Debugging characteristics can be improved and overall debugging time can be significantly reduced.

Conventional joint validation tool with ASIC as device-under-test

64 illustrates a typical final design implemented as a PCI add-on card, such as a 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 is present on chip 2004 and the chip 2004 is connected to interface connector 2002 via bus 2003 and to local oscillator 2005 via bus 2007 for generating a local clock signal. And 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 co-verification tool is shown in FIG. 65. The user design is implemented in the form of an ASIC labeled with a test element (or “DUT”) in FIG. 65. In order to obtain stimulus from several sources designed to interface, a test element 2024 is placed in the target system 2020, which is a combination of a central computing system 2021 and several peripheral devices on the motherboard. to be. 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 to execute many applications. As is known in the art, Sun Microsystems' Solaris is an operating environment and a set of software products that 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.

Device driver 2022 for test device 2024 is included in central computing system 2021 to enable communication between the operating system (and any application) and test device 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 run.

The test device 2024 and the central computing system 2021 are coupled to the PCI bus 2023. Other peripheral devices of the target system 2020 can be used to connect the target system to the network 2030 via the bus 2034, the SCSI drive 2027 via the bus 2036 and 2035, the Ethernet PCI add-on card 2025. And a SCSI PCI add-on card 2026 coupled to 2031, a VCR 2028 coupled to the test component 2024 via a bus 2032 (if necessary for the design of the test component 2024), and the bus 2033. Monitor and / or speaker 2029 (if necessary for test device 2024 design) coupled to the test device 2024. 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 test device 2024 can be inspected with various stimulus from the 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 co-verification tool should be appropriate 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 co-verification tool is unsatisfactory because there are no debugging features (the designer can't pinpoint the cause of a "failed" test without sophisticated techniques, and the "correction" of all detected bugs is Water projects cannot be predicted at the beginning of the project, and thus schedules and budgets cannot be predicted).

Conventional cavity validation tool with emulator as test element

66 shows a conventional cavity validation tool with an emulator. Unlike the setup shown in FIG. 64 and described above, the test element 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 test devices 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 on any operating system, such as Solaris of Microsoft Windows or Sun Microsystems, to execute multiple applications. The device driver 2042 of the test device is included in the central computing system 2041 to enable communication between the operating system (and any application) and the test device 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 Ethernet PCI add-on cards 2045 used to couple the target system to the network 2049 via the bus 2058, and SCSI via the buses 2060 and 2059. SCSI PCI add-on card 2046 coupled to 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 test case 2061 and device model 2068 for other devices that are modeled but not physically coupled to emulator 2048.

Finally, emulator 2048 is coupled via bus 2061 to other peripheral devices such as a frame buffer or data stream recording / reproducing system 2051. This frame buffer or data stream recording / reproducing system 2051 also monitors on a communication device or channel 2053 via bus 2063, on VCR 2054 via bus 2064, and on bus 2065. And / or to the 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 co-validation tools with emulators have various constraints. When using a logic analyzer or sample-and-hold device to obtain the internal state information of a test device, the designer compiles his design and, as a result, investigates the relevant signals of interest while investigating for debugging purposes. It 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, because these co-verification tools use signals, sophisticated circuitry must be provided to convert these signals to 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 Arrays

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 joint validation system in accordance with one embodiment of the present invention.

In FIG. 67, RCC array system 2080 includes an RCC computing system 2081, a reconfigurable 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 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 reconfigurable logic elements during deployment time. As more reconfigurable logic elements are used, more boards may be required. In one embodiment, four reconfigurable logic elements are provided on one board. In another embodiment, eight reconfigurable logic elements are provided on one board. Reconfigurable Logic Elements on a 4-Chip Board The capacities and capabilities can differ significantly from the reconfigurable logic elements on an 8-chip board.

The bus 2090 provides various clocks for the hardware model from the PCI interface 2085 to the hardware model 2087. Bus 2091 provides other I / O data between PCI interface 2085 and hardware model 2087 via connector 2093 and 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 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 joint validation system described below.

The RCC array system 2080 allows the designer to simulate the entire design, accelerate the portion of the test points during the selected cycle through the hardware model of the reconfigurable computing array, and virtually any state of the design at any point in time. It provides the power and flexibility to get information. Indeed, a single-engine reconfigurable computing array (RCC) system can be described as a hardware acceleration simulator, which includes the following tasks in a single debug session: (1) simulation, (2) user start, stop, value assumption, and It can be used to perform simulation, (3) post-simulation analysis, and (4) internal circuit emulation with hardware acceleration that can examine the internal state of the design at any point in time. Since both software and hardware models are under tight control of a single engine through a software clock, the hardware model of the reconfigurable computing array is tightly coupled to the software simulation model. This allows designers to debug cycle-by-cycle 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 reconfigurable computing array does not need to be recompiled if the designer wants to examine a different set of nodes than a conventional emulation system. Please refer back to the above description for more details.

Co-verification system without external I / O

One embodiment of the present invention is a joint validation system that does not use any actual physical external I / O devices and target applications. Thus, the co-verification system according to one embodiment of the present invention can integrate 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. have. Instead, the target system and external I / O devices are modeled in software of the RCC computing system.

Referring to FIG. 68, the co-verification 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 reconfigurable 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 co-verification 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 reconfigurable 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 bench data. As mentioned above, each board includes a plurality of reconfigurable 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.

To compare the co-verification system of FIG. 68 with a conventional emulator-based co-verification system, FIG. 66 shows a target system 2040, a given I / O device (e.g., a frame buffer or data stream recording / reproducing system 2051). ), And emulator 2048 coupled to workstation 2052. This emulator configuration presents many problems for designers and configuration 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. Provided as output for recording. Long recompiles are very expensive.

In the joint validation 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 co-verification system only processes data, 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 into a hardware model, and use various test bench data with the hardware model to accelerate the design. You can examine the resulting internal state 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 determine other parts of the user's design. Can be simulated.

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 joint validation system to remotely access debug data. In a non-network configuration, the workstation may be locally coupled to the co-verification system, or in some other embodiments the workstation may internally couple the co-verification system so that debug data may be locally accessed. Can be.

Joint Verification 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, the actual I / O device and target application (instead of the software model of such I / O device and target application) may be physically coupled to the co-validation system.

One embodiment of the present invention is a co-verification system using actual and physical external I / O devices and target applications. Thus, the co-verification system can 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 co-validation system can use both test bench data from software and stimulus 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 (eg, target systems or external I / O devices) and test bench processes in software is that the test bench data is pinned out and applied to internal nodes. While a target system or external I / O device can be used to test a user design by itself, it can only be applied to the user design via a pin out (or node of the user design representing the pin out). In the following description, the structure of the co-verification system and the co-verification configuration associated with the target system and the external I / O device will be provided.

Compared to the system configuration of FIG. 66, the co-verification system according to one embodiment of the present invention replaces the structure and function of items in dotted line 2070. In other words, FIG. 66 shows an emulator and workstation inside the boundary of dashed line 2070, while one embodiment of the present invention is a cavity as shown in FIG. 69 as a cavity validation system 2140 inside dashed line 2070. Verification system 2140 (and associated workstations).

Referring to FIG. 69, a joint validation system configuration in accordance with an embodiment of the present invention is a target system 2120, a joint validation system 2140, certain optional I / O devices, and control / data for coupling them together. 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 co-verification that are part of this computing environment, the central computing system 2121 is coupled to the PCI bus 2129. Other peripheral devices of the target system 2120 are an Ethernet PCI add-on card 2125 used to couple the target system to the network, a SCSI PCI add-on coupled to the SCSI driver 2128 via the bus 2130. Card 2126, and PCI bus bridge 2127.

The joint validation system 2140 combines the RCC computing system 2141, the RCC hardware array 2190, the external interface 2139 in the form of an external I / O expander, and the RCC computing system 2141 and the RCC hardware array 2190 together. PCI bus 2171 for coupling. The RCC computing system 2141 includes the CPU, memory, operating system, and software needed to run the single engine co-verification 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 co-verification 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 co-verification system 2140. As long as any test bench process is active or any signal from the outside world is provided for co-verification, the kernel evaluates active test bench components, evaluates clock components, updates registers, memory and propagation logic data. The clock edge is detected to simulate time. 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 design in synchronization 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 converted 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.

According to 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 co-validation system. have. 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, graphics 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 co-validation system.

The co-verification 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 that provides 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 reconfigurable computing element (eg, FPGA chip) 2153 and an external interface (target system and I / O) that the co-verification system can use to form at least part of the hardware model. O I) and an external I / O controller 2152 for sending traffic and data between the joint validation system 2140. The board 2145 uses an external I / O controller to allow the RCC computing system 2141 to access all data passed between the external world (ie, target system and I / O system) and the RCC hardware array 2190. To be. This access is important because the RCC computing system 2141 of the co-verification system contains 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. .

If stimulus from an 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 co-verification system can optionally control the next debug step. The debug step includes examining the internal state values of the design as a result of this applied addition. As described above in connection with the board layout and interconnect overview, the first board and the last board 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. PCI controller 2151 is coupled to RCC computing system 2141 via bus 2171 and to tri-state buffer 2179 via bus 2172.

The primary traffic controller present in the co-validation 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). 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 Figs. FPGA I / O controller described and illustrated in an exemplary diagram such as (unit 1200).

External I / O controller 2152 is coupled to tri-state buffer 2179 to enable external I / O controllers 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. And, in another example, data can 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). to be. External buffer 2154 is a DRAM DIMM in one embodiment and may be used by chip 2153 for various purposes. External buffers 2154 each provide more memory capacity than individual SRAM memory elements locally coupled to reconfigurable logic elements (e.g., reconfigurable logic elements 2157. This large memory capacity allows the RCC computing system to Allows to store large amounts of data, such as test bench 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 is also described above. Essentially, this external buffer 2154 has more memory, but is described and illustrated above in FIG. 56 (SRAMs 1205 and 1206, for example). May function partially similar to other high or low bank SRAM memory devices. Can be used by the joint validation system to store data received from the target system 2120 and external I / O devices such that the data can 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 highly complex.

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 the interconnect structure for such a joint validation system, as well as the figures in FIGS. 8 and 36-44 and the description 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, A high bank memory 2169 and a low bank memory 2170. As described above, in one embodiment the internal I / O controller 2158 is the FPGA I described and shown above with the exemplary diagrams in FIGS. 22 (unit 700) and FIG. 56 (unit 1200). / O controller. Similarly, high and low bank memory elements 2169 and 2170 are, for example, SRAM memory elements 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 joint validation 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 the 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 software clocks. 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 many I / O devices to the co-validation system 2140 to run a successful debug session. .

On the side of the joint validation system 2140, 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. Data bus 2175 is used to pass pin-out data between external devices (target system 2120 and external I / O devices) and co-validation system 2140. Software clock control line 2174 is used to transfer software clock data from RCC computing system 2141 to an external device.

The software clock present on control lines 2174 and 2131 is 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, the 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 I / O devices 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 passed to co-verification system 2140 synchronized with a software clock.

Thus, the I / O data transferred between the external interface and the joint verification system is synchronized with the software clock. In essence, the software clock synchronizes the operation of an external I / O device with a target system having a joint validation 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 to an internal node selected 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 another software clock cycle if desired. For a data output operation, the RCC computing system can deliver a software clock to the external interface and subsequently control the data gate to the external interface with the aid of a pointer from an internal node of the hardware model of the RCC hardware array 2190. . Again, in one unit, the pointer will gate the data from the internal node to the external interface. If more data needs to be delivered to the external interface, the RCC computing system can generate another software clock cycle and then drive the selected pointer to gate the data output to the external interface. The generation of the software clock is tightly controlled so that the co-verification system synchronizes the data transfer, and the data evaluation between the co-verification system and any external I / O device is connected to the external interface.

Scan control line 2173 is used to allow the co-verification 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 where multiple inputs are provided as outputs for a specific period of time 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 can be accessed. In the next time period, the data bus 2137 samples the co-verification system 2140 to receive and process all pin-out data originating from the target system 2120 or external I / O devices during this debug session. do. Certain data received by the co-verification 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 operating system) coupled to primary PCI bus 2129, and co-validation 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 co-verification 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 the joint validation 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 (e.g. 2156, 2158) and reconfigurable logic elements (e.g. FPGA chips ( 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 the co-verification 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.

Devices in a particular subset of control logic include an external I / O controller 2152, a three-phase buffer 2179, an internal I / O controller 2156 (CTRL 1), a reconfigurable logic element 2157 (board 1 of Chip0_1 representing chip 0) 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 recon. The programmable logic element 2204 and various bus and control lines that allow data transfer. External buffer 2201 is also shown for this data input embodiment. This subset shows the logic required for data input operations, 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, co-validation 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 register components and coupling components 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 components. If a certain clock edge is detected by the kernel, the registers and memory are updated and the values propagated through the coupling component. 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 joint validation 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 2 on line 2255. 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 latches 2208-2213 of the reconfigurable logic element 2204. In this example, the reconfigurable logic element corresponds to chip0_1 (ie chip 0 on 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. Certain example 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 the user design. User designs typically have other internal nodes that cannot be accessed through pin-out, but these non-pin-out internal nodes have stimulus across multiple internal nodes in the user design, whether they are input pin-out or not. It is for other debugging purposes to provide flexibility for designers who want to provide For stimulus providing an external interface to the high hardware model of the user's 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 to Reset the 6845 Controller

RS-Register Selection

E-Enable

CLK-Clock

~ CS-Chip Selection

Other input pin-outs can also be used in such video controllers. Based on the number of input pin-outs that interface with the outside world, the number of latches and pointers can be easily 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 through 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 routes itself to 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 logic "1" for the first half cycle 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 enable, 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 increase 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 reverts 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 target systems 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, tri-state buffer 2206 in external I / O controller 2200 is enabled to load data onto 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 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. It can be delivered in a software model. 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 the external buffer 2201 is provided by the memory address counter 2201 to the external buffer 2201 via the bus 2220. To enable such storage, a WR_EXT_BUF signal is provided to external buffer 2201 via line 2221. Before the external buffer 2201 is filled, the RCC computing 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-input global cycle.

The S2H cycle will be described below. The S2H cycle is used to transfer test bench data from the RCC computing system to the RCC hardware array, and then sequentially move the data from one chip to the next for each board. While the CPU-IN signal is logic "1", the EXT_IN signal goes to 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 the three-phase buffer 2202 to allow data to pass 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, data from the RCC computing system is first delivered to chip m1 and then to chip 0_1 (ie chip 0 on board 1), chip 1) 1 (ie 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-input cycles.

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 RCC computing system and external interfaces. During the process of processing data in response to 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 have stimulant responses at multiple internal nodes in the user design, whether or not they are output pin-outs. It is for other debugging purposes that will give flexibility to designers who want to read and analyze the data. From the high hardware model of the user design (with the model of other I / O devices in the software) to the stimulus provided by the RCC computing system or external interface, these internal nodes corresponding to the data-out logic and output pin-out Is performed.

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 in 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 gate 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 computing system includes a model of the entire user design in software, these output pin-out internal nodes must be provided to the RCC computing system, so that any changes that occur within the software model can be made with the software model. 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 to allow these output pin-out internal nodes to be communicated to RCC computing systems and external 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 the RCC hardware 2190 to the RCC computing system 2141 and to 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 parts are the various internal I / O controllers (e.g. 2156 and 2158) and reconfigurable control elements (e.g. FPGA chips 2159 and 2165). Is shown in 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. Such 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 specific 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, reconfigurable logic elements 2303 and several buses and control lines. This enables 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. The 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 the data-out control logic, a pointer will be used to select (or gate) data from an internal node to an external interface with the RCC computing system. In the embodiment shown in FIGS. 71 and 73, data-out pointer state machine 2319 generates five pointers H2S_PTR [4: 0] on bus 2359 for both hardware-hardware data and hardware-external interface data. . Data-out pointer state machine 2319 generates the DATA_XSFR and F_RD signals on line 2358. Internal I / O controller 2302 generates the DATA_XSFR and F_RD signals on line 2358. DATA_XSFR is always 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 logic "1", 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 gate logic. Input sets 2353-2357 to the gate 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 the 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 wire 1 on line 2327, and an internal node connected to line 2352 is configured to correspond to wire 4 on ain 2328. Similarly, wire 3 corresponds to KD3 on line 2331, wire 1 corresponds to LD1 on line 2332, and wire 4 corresponds to LD4 on line 2333.

Look-up table 2309 is connected to the inputs to these latches 2305 and 2306. The look-up 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 look-up table 2309. If the entry (or bit) in the particular column is a logic "1", the LUT output line connected to the particular entry in the look-up table 2309 enables its corresponding latch and reads the data. It is driven by an external interface, and finally by a 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 look-up table 2309 are programmed for enabling latches corresponding to the output pin-out wires for the internal node of chip m1. Similarly, columns 4-6 are programmed for the 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 of the look-up table, only one entry is logic "1" because a single output pin-out wire 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 configured such that the 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 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 is in a state of its internal state. 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 directed to the output pin-out internal node. The F_RD signal also controls the look-up 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 on chip m1 goes to logic "1". This drives data at the internal node of chip m1 based on H2S_PTR0 to the RCC computing system via tri-state buffer 2301 and local bus 2320. Look-up table address counter 2304 is counted and instructed row 0 of look-up table 2309 to latch onto the external interface at the appropriate data on chip m1. When the F_RD signal returns to logic " 1 ", data at internal nodes that can be driven by H2S_PTR1 is passed to the RCC computing 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 to the external interface from the appropriate data of chip m1. Latched.

Reconfigurable 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 computing system. Data from three internal nodes associated with H2S_PTR2, H2S_PTR3, and H2S_PTR4 will be delivered to the RCC computing system and external interface.

When F_RD becomes logic "1", H2S_PTR0 of chip 2303 becomes logic "1". It drives these internal nodes in chip 2303 that rely on H2S_PTR0 to the RCC computing system via a tri-state buffer 2301 and a 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 computing 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 coupled with line 2350 is provided at LD3. This data is provided to both the RCC computing 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 computing 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 computing 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 computing 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, look-up table address counter 2304 is counted and instructs look-up table 2309 to row 5 to indicate 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 computing 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 computing 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 row 6 to match lines 2352-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 computing system and then to the RCC computing 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 joint verification 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. The 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 has a chip m1 connected to the south interconnect 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 that chip m2 is connected to the south interconnect 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 reg2 (clk, reset, d2, q2);

register reg3 (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 = 0;

# 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 shown 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 generates a schematic of the nature before actually presenting the nature on the HDL foam. Certain schematic capture tools allow generating the useful code after the schematic schematic has been entered and processed.

As shown in Figure 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 registers (clock, reset, d, q)" and ending with "endmodule" are register definition sections.

The next few lines of code, reference number 907, represent wire interconnect information. Wire variables of HDL known to those skilled in the art are used to represent physical connections between structural entities such as gates. Since HDL is mainly used to model digital circuits, wire variables need variables. Usually, "q" (e.g., q1, q2, q3) represents an output wire line, and "d" (e.g., d1, d2, d3) represents an input wire 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 shows the coupling components S4, S5, S6, S6. Note that coupling component S4-S7 has 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 illustrate test bench components. Reference numeral 904 shows a test bench component (driver) S9. Reference numeral 905 shows test bench components (initialization) S10, S11. Reference numeral 904 shows a test bench component (monitor) 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 in software and optionally in hardware. In each case, the user can control the simulation and hardware acceleration modes. In addition, the user can emulate the circuit by a 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 monitor process that receives the sigout signal. In this example, S9 generates a random sine 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 SEmulation 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 searching for clock edges to update registers and memory. The simulation time is then performed. Even if the kernel is on the software side, some of its operations and instructions may operate on hardware because a hardware model exists for such 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 on 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 monitor 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 enable inputs to registers S1-S3. As described above, the software clock corresponding to the present invention eliminates race conditions and retention time violations. 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 the 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 components S4-S7 are also connected to the register components S1-S3, sign, sigout. These signals travel on and from the PCI bus on the I / O bus 915.

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. 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 SEmulation system before the final structure file occurs. Thus, the hardware model requires at least three wires between the two chips for wire 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 wire 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 the number of wires only, the example can be considered that the SEmulation system selected FIG. 32 after performing the mapping, fixation and operational routing. have. The result portion of Figure 32 may be used as the basis for generating the rescue file.

Figure 34 illustrates 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 divided parts of the user circuit design, a TDM unit 941 for the transmitting side, the software clock 942 and an I / O bus 943 among other components. The TDM units 931 and 941 have been described with reference to Figs. 9A, 9B and 9C.

The chips 930 and 940 have two interconnect wires 944 and 945 connecting the hardware model together. These two interconnect wires are the interconnects shown in FIG. Referring to FIG. 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 of the interconnections is 44. In Figure 34, the modeled circuit requires only two wires / pins between the chips 930, 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 corrections and changes. 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)

A method of generating a value change dump (VCD) file for an on-demand modeling design. Selecting a simulation session range starting at simulation time t0 of the simulation of the modeling design and ending at simulation time t3; Selecting a simulation target range starting at simulation time t1 of the simulation of the modeling design and ending at simulation time t2, wherein the simulation time t1 is greater than or equal to the simulation time t0 and the simulation time t2 is greater than the simulation time t3. Less than or equal to; Generating a VCD file of the modeling design during the selected target range of the simulation of the modeling design; And Directly accessing the VCD file at the simulation time t1 to debug the modeling design being simulated How to create a VCD file containing. The method of claim 1, Simulating the modeling design by providing primary inputs to the modeling design for evaluation by the modeling design; And Recording simulation history during the simulation session range Further comprising, VCD file generation method. The method of claim 2, Simulating the modeling design by evaluating a simulation history of the modeling design from the simulation time t0 to the simulation time t2. The method according to claim 3, Generating the VCD file, Generating evaluated results from the modeling design based on the simulation history; And And storing the evaluated results in the VCD file during the simulation target range. The method of claim 4, wherein The recording of the simulation history, Compressing the primary inputs; And Recording the compressed primary inputs as the simulation history. The method of claim 5, wherein Processing the simulation history, Decompressing the compressed primary inputs; And Providing the decompressed primary inputs to the modeling design as the processed simulation history for evaluation. The method of claim 4, wherein The recording of the simulation history, Recording the primary inputs as the simulation history. The method of claim 1, Storing state information of the modeling design in a first file at the simulation time t0; And And storing state information of the modeling design in a second file at the simulation time t3. An electronic design automation system for verifying user designs. A computing system including a central processing unit (CPU) and a memory for modeling a user design of software for simulating the user design; An internal bus system coupled to the computing system; Reconfigurable hardware logic coupled to the internal bus system for modeling the user design and for modeling at least a portion of the user design of hardware; Control logic coupled to the internal bus system to control data transfer between the reconfigurable hardware logic and the computing system; And Custom VCD logic for recording simulation history for a selected simulation session range and dumping state information from a hardware model to a VCD file for a selected simulation target range, wherein the simulation target range is within the simulation session range. Electronic design automation system comprising a. The method of claim 9, The custom VCD logic, First range selection logic for selecting a simulation session range starting at simulation time t0 and ending at simulation time t3; Second range selection logic for selecting a simulation target range starting at simulation time t1 and ending at simulation time t2-the simulation time t1 is greater than or equal to the simulation time t0 and the simulation time t2 is less than the simulation time t3 Or equal to-; Dump logic for generating a VCD file of the user design during the selected simulation target range; And Access logic to directly access the VCD file at the simulation time t1 to debug the user design Further comprising, electronic design automation system. The method of claim 10, The custom VCD logic, A test bench process for simulating the user design by providing primary inputs to the user design for evaluation by the user design; And Recording logic of the computing system to record simulation history during the simulation session range Further comprising, electronic design automation system. The method of claim 11, The custom VCD logic, Evaluation logic of the reconfigurable hardware logic for simulating the user design by evaluating the simulation history of the user design from the simulation time t0 to the simulation time t2 Further comprising, electronic design automation system. The method of claim 12, The dump logic dumps evaluation results from the user design into the VCD file during the simulation target range based on the simulation history. The method of claim 13, The recording logic is, Compression logic for compressing the primary inputs; And Write logic for writing the compressed primary inputs as the simulation history Further comprising, electronic design automation system. The method of claim 14, The processing logic is, Decompression logic to decompress the compressed primary inputs; And Data transfer logic for passing the uncompressed primary inputs to the user design as the simulation history for evaluation Further comprising, electronic design automation system. The method of claim 13, The write logic further comprises write logic to write the primary inputs as the simulation history. The method of claim 9, And state storing logic for storing state information of the user design in a first file at simulation time t0 and storing state information of the user design in a second file at simulation time t3. A custom VCD system for providing evaluation information from a modeling design simulated during a selected simulation target range of simulation times, First logic for selecting a simulation session range starting at simulation time t0 and ending at simulation time t3; Second logic to select a simulation target range starting at simulation time t1 and ending at simulation time t2, wherein the simulation time t1 is greater than or equal to the simulation time t0 and the simulation time t2 is less than or equal to the simulation time t3; ; Generation logic for generating a VCD file of the evaluation information during the selected simulation target range; And Access logic to directly access the VCD file at the simulation time t1 to debug the modeling design Custom VCD system comprising a. The method of claim 18, Compression logic for receiving and compressing primary input data during the time period of the simulation session range; And Decompression logic to decompress the compressed primary input data and pass the decompressed primary input data to the modeling design for evaluation. Further comprising, on-demand VCD system. The method of claim 19, The generation logic further comprises dump logic for dumping the evaluated information into the VCD file, wherein the evaluated information is generated by evaluating the decompressed primary inputs by the modeling design.

Images