JP2003223476A - Hardware acceleration system for function simulation - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a hardware acceleration system materializing a low cost, a high performance, a low turnaround time, and a high scalability. <P>SOLUTION: This hardware acceleration system for the function simulation is provided with a general circuit board having a logic chip and a memory. The circuit board can be connected to a computing device by a plug. This system is so applied that the computing device guides DMA (direct memory access) transfer between memories related to the circuit board and the computing device. The circuit board can be constituted using a simulation processor. The simulation processor can be programmed for, at least, a circuit design. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to hardware acceleration for functional simulation of circuits.
The present invention relates to a system, and more particularly, to a hardware acceleration system and method using a simulation processor, and a method for compiling a netlist for the simulation processor.

[0002]

2. Description of the Related Art (1) References The following papers provide useful background information,
For that reason, it is hereby incorporated by reference in its entirety and is referred to in the remainder of this specification by reference numbers in brackets attached to each of them (ie <4.
> Indicates a reference by J. Abke et al. With number 4.)

<1> http: //www.quickturn.com/produc
ts / speedsim.htm. <2> http: //www.quickturn.com/products/palladiur
n.htm. <3> 2001. http: /www.quickturn.com/products/CoBAL
TUItra.htm. <4> Joerg Abke and Erich Barke. A new placement
method for direct mapping into LUT-based FPGAs (LU
New placement method for direct mapping to T-based FPGAs). In International Conference on Field Programm
able Logic and Applications (FPL 2001), pages 27-3
6, Belfast, Northern Ireland, August 2001. <5> Semiconductor Industry Association. Internat
ional technology roadmap for semiconductors (International Semiconductor Technology Roadmap for Semiconductors). 1
999. http://public.itrs.net. <6> Jonathan Babb, Russ Tessier, and Anant Agarw
al. Virtual wires: Overcoming pin limitations in F
PGA-based logic emulators. In Procee
dings of the IEEE Workshop on FPGAs for Custom Com
puting Machines, April 1993. <7> Jonathan Babb, Russ Tessier, Matthew DahI, S
ilvina Hanono, DavidHoki, and Anant Agarwal. Logic
emulation with virtual wires. In IEEE Transactions on C
AD of Integrated Circuits and Systema, June 1997. <8> Steve Carlson. A new generation of verificat
ion acceleration. June (New generation verification acceleration). http: //www.tharas.com. <9> M. Chiang and R. Palkovic. LCC simulators sp
eed development of synchronous hardware. In Comput
er Design, pages 87-92, March 1986. <10> Seth C. Goldstein, Herman Schmit, Matt Mo
e, Mihai Budiu, Srihari Cadambi, R. Reed Taylor, a
nd Ronald Laufer. Piperench: A coprocessor for stre
aming multimedia acceleration (Pipe Wrench: a coprocessor for streaming multimedia acceleration). In The 26th Annual International
Symposium on Computer Architecture, pages 28-39,
May 1999. <11> S. Hauck and G. Borriello. Logic partition
orderings for multi-FPGA systems. In ACM / SIGDA
International Symposium on Field Programmable Gate
Arrays, pages32-38, Monterey, CA, February 1995. <12> Chandra Mulpuri and Scott Hauck. Runtime a
nd quality tradeoffsin FPGA placement and routing
(Runtime and quality trade-off in FPGA placement and routing). In International Symposium on Field P
rogrammable Gate Arrays, pages 29-36, Napa, CA, Fe
bruary 2001. <13> Alberto Sangiovanno-Vincentelli and Jonath
an Rose. Synthesis methods for field-programmable
gate arrays. In Proceedings of the IEEE, V
ol. 81, No. 7, pages 1057-83, July 1993. <14> E. Shriver and K. Sakallah. Ravel: Assigne
d-delay compiled-code logic simulation.
In International Conference on Computer-Aided Des
ign (ICCAD), pages 364-368, 1992. <15> D. Thomas and P. Moorby. The Verilog Hardw
are Description Language, 3rd Edition (Verilog Hardware Description Language, 3rd Edition). Kluwer Academic Publisher
s, 1996. <16> S. Trimberger. Scheduling designs into at
ime-multiplexed FPGA (Scheduling design to time-multiplexed FPGA). In Proceedings of the 1998 ACM / SIGDA
Sixth International Symposium on Field Programmab
le Gate Arrays, February 1998. <17> S. Trimberger, D. Carberry, A. Johnson, an
d J. Wong. A time-multiplexed FPGA
A). In IEEE Symposium on FPGAs for Custom Computin
g Machines (FCCM) 1997, February 1997. <18> Keith Westgate and Don Mclnnis. Reducing s
imulation time withcycle simulation. 200
0. http://www.quickturn.com/tech/cbs.htm. <19> J. Cong and Y. Ding. An Optimal Technology
Mapping Algorithm for Delay Optimization in Looku
p-Table based FPGA Designs. Optimal technology mapping algorithm for delay optimization in look-up table based FPGA design. In IEEE Transaction
s on CAD, pages 1-12, January 1994. <20> F. Corno, MS Reorda, and G. Squillero.
RT-level ITC99 Benchmarks and First ATPG Results
(RTC ITC99 benchmark and first ATPG result). I
n IEEE Design and Test of Computers, pages 44-53,
July 2000. <21> Xilinx. Virtex-Il 1.5v Field Programmable
Gate Array: AdvanceProduct Specification (Virtex-I
l 1.5v Field Programmable Gate Array: Advanced Product Specification). Xilinx Application Databook, O
ctober 2001.http: //www.xilinx.com/partinfo/databoo
k.htm.

(2) Preface a) Verification gap With the emergence of new applications and processing demands over the last decade, the complexity and density of integrated circuits (ICs) has increased significantly. At the same time, it is expected that shortening the design cycle will become necessary due to the increase of the market pressure, and the dependence on the fully automated design method will increase. Functional verification is an important part of these design methods. Functional verification plays a crucial role in determining the overall time-to-market for a design. Designers must perform a vast amount of functional verification before spending time and money on manufacturing. Over 60% of human and computer resources are used in the normal design process (Ref. <1>), and 85% of them are used for functional verification (Ref.
>). While chip complexity and density has grown exponentially over the last few years (which is expected to continue for the next decade), circuit verification capability is not. That is, the performance of the CAD tool for functional verification is not sufficiently improved due to the complexity of the circuit.

The resulting "functional verification gap" is
Some work has been done by using hardware-assisted simulators and dedicated hardware emulators.
The performance of the dedicated emulator is significantly higher than that of the software simulator, but the cost is also significantly higher. The process of software simulation itself has until recently been based on event-driven simulation, but has made rapid progress with the advent of cycle-based logic simulation a few years ago.

B) Cycle-based simulation Unlike conventional event-driven simulation, cycle-based simulation is very suitable for functional verification. The event driven simulator updates the gate's output for the input at which the event occurred, and then schedules future events for each gate affected by the update. This is an efficient method for circuits with low activity. This is because the number of gates to be updated in each cycle occupies a very small proportion of the total number of gates. This method also allows the event driven simulator to model and simulate gate delays. However, the use of this method in large circuits with high activity increases memory usage and slows simulation.

Cycle-based simulation is
A high-speed, low-memory-intensive function verification method is provided.
Cycle-based simulation is characterized by:

Values are calculated only on clock edges,
Intermediate gating results are not calculated. Instead, the output at each clock cycle is calculated as a Boolean logic function of the input for that clock cycle.

The combinational timing delays are ignored.

Normally, the simulation is binarized (states 0, 1) or quaternized (states 0, 1, x, and z). The full-featured event-driven simulator is
It must support up to 28 states.

Therefore, cycle-based simulators enhance performance by focusing on functional verification. For practical circuits, cycle-based simulators are 10 more than event-driven simulators.
Although it is twice as fast, the memory usage is only about 1/5 (reference <18>). For example, a commercial cycle simulator, SpeedSim (Quickturn / C).
can produce a netlist of 1.5 million gates on a standard UltraSparc workstation at a rate of 15 vectors per second. 50,000 ~
The speed for a netlist with 100,000 gates is typically about 400-500 vectors per second. as a result,
Such simulators are becoming more and more popular in design verification.

C) Hardware support cycle base
If you want to accelerate your simulation cycle-based simulation even faster, you can accelerate it with dedicated hardware.
Since the cycle-based simulation has a considerable amount of concurrency (that is, instruction-level parallelism) that cannot be handled by the conventional microprocessor, the hardware acceleration can be expected to have a great effect. With the advent of electrically reconfigurable field programmable gate arrays (FPGAs), it has become possible to create inexpensive hardware solutions. Reconfigurability makes it possible to emulate logic circuits on FPGAs and even to handle parallelism through the use of spatial parallelism.
By such a method, the functional verification is significantly accelerated, and the design time and the time to market of the complicated design can be shortened.

Although a single FPGA can emulate several logic designs, there are size limitations and large circuits cannot accommodate one at a time. F
A circuit that requires more resources than the amount of resources in the PGA cannot fit in the FPGA.

A second workaround for this problem is immediately to use multiple FPGAs. However, multiple FPGA emulation systems cannot address this issue both in terms of scalability and cost effectiveness. For example, a system consisting of 10 FPGAs is powerless if the design is larger than the combined size of 10 FPGAs. In addition, the fact that the number of pins connecting the FPGA is limited becomes a bottleneck and the logic utilization rate decreases, resulting in that some FPGAs are only partially used. In addition, these pins use relatively slow onboard interconnect wires,
This also causes a reduction in emulation speed (Reference <11>). These problems are solved to some extent by the concept of VirtualWires developed by MIT (references <6>, <7>). But,
Some emulation vendors (such as Axis) still use multiple FPGAs and specially designed hardware in their systems, with product prices in the hundreds of thousands to millions of dollars.

Another approach to emulation is to time-share large designs on physically small FPGAs. In this method, emulation is partially performed instead of the entire circuit. Each part fits in a single FPGA and the FPGA is reconfigured iteratively. With this method, even if there are multiple FPG
Although the solution's high cost problem is solved by adopting A, the performance is degraded due to the overhead required for reconfiguring the FPGA. Most general purpose FP
Since the GA has not been designed for frequent reconfigurations, only a few I / O pins are available for reconfiguration. Therefore, the bandwidth of the configuration is very small,
There will be a significant delay during reconfiguration. Dedicated FPGA architectures with increased on-chip storage have been devised in response to situations where multiple configuration contexts are used (references <16>, <17>), but such architectures are not commercially available, and Not scalable.

(3) Technology and Background of Related Research In this section, some aspects of the related research will be discussed based on the background and the prior art.

(4) Simulation Method In event driven simulation, a change in value on the net is regarded as an event. Event is event
Managed dynamically by the scheduler. The event scheduler schedules events and updates each net whose value has changed in response to the scheduled event. The event scheduler also schedules future events triggered by scheduled events (15). The main advantage of event driven scheduling is flexibility. The event driven simulator can simulate both a synchronous model and an asynchronous model by arbitrarily delaying the timing. The disadvantage of event-driven simulation is that it is inherently serial and, due to the large memory usage, provides only low levels of simulation performance.

A uniformized compiled code logic simulator (a cycle-based simulator is a derivative of this) can provide much higher simulation performance than an event-driven simulator. This is because most of the runtime overhead required for event sequencing and propagation is eliminated. This is done once every clock cycle by evaluating all components in topological order so that all inputs to the component are up to date by the time the component is executed. To be done. The main drawback of cycle-based simulators is that they cannot be simulated by arbitrary gate delays (ref. <14> is a notable exception).

Until a few years ago, event-driven simulators were generally preferred over cycle-based simulators. This is because the activity rate of most circuits was within the range of 10 to 20% (Ref. <9>). Event-driven simulator performance depends on circuit activity rather than circuit size. The entire circuit is not compiled statically, the simulation proceeds by interpretation, during which only the gates and nets affected by the circuit activity are updated. On the other hand, in cycle-based simulation, each gate in the circuit is evaluated cycle by cycle because the entire circuit is statically compiled before the simulation starts. Another reason why event-driven simulators were so popular in the early stages was that they could simultaneously test circuit functionality and timing. However, with the advent of static timing analysis tools, it is now possible to verify functionality and timing separately.

In recent years, applications such as pipeline processing and parallel execution (in the area of multimedia and networking) have appeared, and circuits with much higher activity rates are being used. Cycle-based simulators are more event-driven when gate delays are not needed (ie for functional verification).
Better than a simulator. The cycle-based simulator simulates the entire circuit, but its performance is superior to that of the event-driven simulator due to its small memory usage and the possibility of parallelization (References <14>, <18>).

The method of the present invention relates to a scalable hardware accelerator for cycle-based simulation using a general-purpose board with a single off-the-shelf FPGA. The rest of this section will cover other FPGs, including commercial products that could be competitors in this area.
Discuss A-based hardware accelerators.

A) Single FPGA System Using a single FPGA for logic emulation has two major problems.

Lack of scalability: A design that does not fit in an FPGA cannot emulate the whole at once. In order to emulate such a design part by part, it is necessary to perform reconfiguration repeatedly, which is very time-consuming in a commercially available FPGA.

Long compile time: Traditional FPGA tool flows are complex, requiring hours to days for large designs. In addition, the increased simulation overhead will have a significant impact on design time and time to market.

In the document <17>, the author presents a time-division FPGA architecture capable of holding a plurality of contexts and switching between the contexts at high speed. Large circuits that do not fit in the FPGA can be divided into just the right size and each part stored in the FPGA. This solution avoids cumbersome reconfiguration iterations, but has the drawback of being affected by the amount of context storage provided in the FPGA. Furthermore, since a commercially available FPGA cannot store and switch a plurality of contexts, it is necessary to build a dedicated FPGA.

B) Multiple FPGA System Emulation systems typically consist of a number of interconnected off-the-shelf FPGAs. This makes it possible to emulate large designs, but F
Since there are few pins that can be used for inter-PGA communication, each FPG
The utilization rate of A is significantly reduced. FP because there are few pins
The GA is only partially filled, resulting in waste. In the document <6>, “Virtual Wires”
Has been proposed. Virtua
In lWires, each physical pin is time-shared and mapped to multiple "virtual pins" in the design. This is done with the addition of some time division hardware, but the overall design emulation needs to be done at a slower clock rate than the FPGA clock rate. Still, yet, furthermore,
The concept of Virtual Wires is multiple FPG
It is extremely effective for the A system.

C) Commercial product (1) Quickturn / Cadence Quickturn (currently absorbed in Cadence) is a cycle-based simulator,
He was selling simulation accelerators and emulators. SpeedSim is a (software) cycle-based verilog simulator that translates HDL directly into native machine code. Its performance is based on symmetric multi-processing (SMT) and simultaneous test (SMT) that allow multiple test vectors to be simulated within a single design.
T) method (reference <1>).

One of Quickturn's comprehensive verification products for simulation acceleration, test bench generation, and in circuit emulation is Palladium (reference <2>). Pal
The ladium is built using a specially designed ASIC specifically designed for simulation and emulation. After all Pallad made by Quickturn
A much larger emulation system than the ium,
CoBALT (reference <3>) can be expanded to a maximum of 112 million gates. All of these products are 1
It is very expensive (price range of millions of dollars) as it requires a system dedicated to 00%.

(2) Tharas Systems Tharas Systems is "Hammer".
Provides a relatively affordable verification acceleration system called. Hammer hardware is a configuration in which a high bandwidth backplane is connected to a board with several proprietary custom built ASICs. A
SICs can evaluate parts of RTL or gate level designs, and even non-blocking interconnects with all other ASICs on board (ref. <8>).
I will provide a. The system can scale up to 8 million gates and costs hundreds of thousands of dollars.

(3) IKOS IKOS (http://www.ikos.co
m) is the emulation system Virtua
It sells Logic and VStation. Vir
tuaLogic consists of hardware consisting of several FPGAs connected to each other using the Virtual Wires concept (reference <6>). VSt
ation is a relatively large-scale emulator.
nsaction Interface Porta
You can connect to a workstation using the IKOS proprietary interface called "l". The IKOS system primarily targets the emulation market.

(4) AXIS AXIS (http: //www.axiscor
p. The Xtreme simulation acceleration system sold by
Composed of. The combination of the AXIS system and the software simulator "Xcite" enables "hot swapping" between hardware and software. Initially, hardware accelerated simulation is used, and if a design bug is found, the entire design is effectively swapped into software for debugging.

(5) Others Avery Design Systems is "Si
It sells a product called mCluster. With this product, you can verify log across multiple CPUs.
The simulation can be distributed efficiently. This product can be licensed alone or used with a third party verilog simulator. Logic Express is "SOC-V2
We offer a product called "0". This product also has several F
It is composed of PGA and wiring logic for simulation acceleration.

[0033]

Although the performance of conventional hardware-assisted simulators and dedicated hardware emulators outperforms that of software simulators, the cost is also significantly higher.

In conventional hardware-assisted cycle-based simulation, FPGAs are reconfigurable.
It becomes possible to emulate logic circuits above, and even to handle concurrency by using spatial parallelism. However, although a single FPGA can emulate several logic designs, there is a size limitation and large circuits cannot accommodate one at a time.

Also, an emulation system with multiple FPGAs cannot address this problem both in terms of scalability and cost effectiveness. In addition, the fact that the number of pins connecting the FPGA is limited becomes a bottleneck and the logic utilization rate decreases, resulting in that some FPGAs are only partially used. In addition, these pins use relatively slow onboard interconnect wires,
This also causes a reduction in emulation speed. Some emulation vendors (such as Axis) use multiple FPGAs and specially designed hardware in their systems, and their product prices are in the hundreds of thousands to millions of dollars.

In a method in which a large-scale design is time-divided on a physically small FPGA and a part of the circuit is emulated instead of the whole circuit, the pin limitation is caused, and the cost of the solution using a plurality of FPGAs is high. It also solves the problem, but reduces the performance due to the overhead required to reconfigure the FPGA. Most general purpose FPGA
Is not designed for frequent reconfigurations, so
Only a few I / O pins are available for reconfiguration. Therefore, the bandwidth of the configuration is very small, a large delay occurs at the time of reconfiguration, and there is a problem in scalability.

The disadvantage of event-driven simulation is that it is inherently serial and, due to the large memory usage, provides only low levels of simulation performance.

A uniformized compiled code logic simulator (a cycle-based simulator is a derivative of this) may provide much higher simulation performance than an event-driven simulator, but is optional. It has the drawback that it cannot be simulated due to the gate delay of.

Single FPG for logic emulation
There are two major problems with using A.

Lack of scalability: A design that does not fit in an FPGA cannot emulate the whole at once. In order to emulate such a design part by part, it is necessary to perform reconfiguration repeatedly, which is very time-consuming in a commercially available FPGA.

Long compile time: Traditional FPGA tool flows are complex, requiring hours to days for large designs. In addition, the increased simulation overhead will have a significant impact on design time and time to market.

An emulation system, which is a multiple FPGA system, typically consists of a number of interconnected off-the-shelf FPGAs, allowing emulation of large designs, but used for inter-FPGA communication. Since the number of pins that can be formed is small, the utilization rate of each FPGA is significantly reduced. Due to the small number of pins, the FPGA is only partially filled, resulting in waste.

The present invention seeks to overcome the shortcomings associated with the prior art and overcome some of the above problems. Specifically, at least the method according to the present invention,
It offers four advantages: (i) low cost, (ii) high performance, (iii) low turnaround time, and (iv) high scalability. That is, the present invention is
The objective is to provide a hardware acceleration system that achieves extremely high performance while achieving simulator-like cost, scalability, and turnaround time.

[0044]

In order to achieve the above object, the present invention provides a hardware acceleration system for functional simulation, which is composed of a general-purpose circuit board containing a logic chip and a memory. provide.
The circuit board can be plugged into a computing device. This system is
The device is adapted to direct a DMA transfer between the circuit board and the memory associated with the computing device. The circuit board is
It is also possible to configure using a processor. The simulation processor can be programmed for at least one circuit design.

In another particular enhancement, the simulation processor is mapped to the FPGA.

In another particular enhancement, a netlist of simulated circuits is compiled for the simulation processor.

In another particular enhancement, the simulation processor comprises at least one element processor and one corresponding to said at least one element processor.
At least one register having one or more registers
And a file.

In another particular enhancement, the simulation processor further comprises a distributed memory system having at least one memory bank.

In another particular enhancement, said at least one memory bank is used for the element processor set and its associated registers.

In another particular enhancement, the registers can be spilled onto a memory bank.

In another particular enhancement, the system further comprises an interconnection system connecting said at least one element processor with another element processor.

In another particular enhancement, the element processor can simulate any two-input gate.

In another particular enhancement, the element processor can perform RT-level simulations.

In another particular enhancement, the connection is made via a register.

In another particular enhancement, the interconnection network is pipelined.

In another particular enhancement, the register file is located close to the associated element processor.

In another particular enhancement, the distributed memory system has a dedicated port associated with each register file.

In another particular enhancement, the system can process the partitions of the netlist one at a time if the netlist does not fit in on-board memory.

In another particular enhancement, the system can simulate the entire netlist by sequentially simulating partitions of the netlist.

In another particular enhancement, the system is capable of processing a subset of simulation vectors used to test the circuit.

In another particular enhancement, the system can simulate the entire simulation vector set by sequentially simulating each subset.

In another particular enhancement, the acceleration system can be used interchangeably with a general purpose software simulator capable of exchanging the states of all registers in the design.

In another particular enhancement, both binarization and binarization simulations can be performed on the simulation processor.

In another particular enhancement, the system further comprises an interface and opcode, said opcode specifying read, write, and other operations associated with the simulation vector.

In another particular enhancement, the simulation processor includes at least one arithmetic logic circuit.
(ALU: arithmetic logic un
it), zero or more signed multipliers, each further comprising a distributed register system having at least one register associated with the ALU and the multiplier.

In another particular enhancement, the system uses each A
It has a carry register file for the LU, the width of which is the same as the width of the corresponding register.

In another particular enhancement, the system comprises pipelined carry chain interconnects connecting registers.

In another aspect, a method is provided for performing a logical simulation of a circuit, the method comprising compiling a netlist corresponding to the circuit to generate an instruction set for a simulation processor, and executing the instructions. The simulation processor configures the steps of loading into the onboard memory for the simulation processor, transferring the simulation vector set onto the onboard memory, and the instruction set corresponding to the simulated netlist. On the FPGA being implemented, executing the instruction set to generate a result vector set, and transferring the result vector to a host computer.

In yet another aspect of the present invention, there is provided a method of compiling a netlist of circuits for a simulation processor, the method comprising the circuit as a directed graph in which the nodes of the graph correspond to hardware blocks in the design. Representing the design of the node, generating a ready-front subset of nodes that are ready to be scheduled, performing a topological sort on the ready-front set, and to date unselected The step of selecting a node, the step of completing the instruction and proceeding to a new instruction if no element processor is available, and the associated number of free registers to perform the operation corresponding to the selected node. Registering operands and steps to select a large number of element processors Comprising a step of designating the route to the selected element processors, and a step of repeating until unselected node is eliminated from.

[0070]

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

1. Hardware acceleration
System Here, an overall hardware acceleration system, which is an example of implementation using the method according to the present invention, will be described.

SimPLE intermediate
architecture (SimPLE Intermediate Architecture: hereinafter referred to as SimPLE) 2.6 (eg, those shown in FIGS. 2-4) is an example implementation of the inventive approach associated with a simulation processor.
It should be understood that the particular architecture and implementations described herein are exemplary only, and should not be construed as limiting the claimed invention in any way. Those skilled in the art will appreciate that numerous alternative implementations are possible without departing from the scope of the techniques according to the present invention. Furthermore, these examples are based on FPGA (Field Programmable G).
However, it goes without saying that any logic chip can be used.

Time-sharing a netlist on FPGA 2.2 usually involves a great deal of structural overhead. This is because most FPGAs have very few pins for configuration bits. The present invention solves this constituent bandwidth problem by introducing the concept of a simulation processor. In the following, an example of such a simulation processor called "SimPLE" will be described.

SimPLE 2.6 is a virtual concept that is a compilation destination of a netlist. After being configured once on FPGA 2.2, SimPLE 2.6
It is programmed for various circuit designs using a compiler example called the E compiler (ie,
Different netlists can be simulated on SimPLE). The instruction for SimPLE is FPGA data I.
Since the / O pin is used, there is no effect even if the configuration bandwidth is small.

(1) Example of Overall System The overall hardware acceleration system described here is a commercially available FPGA, memory,
Since it is composed of a general-purpose PCI board having a PCI controller and a DMA controller, it can be plugged into any computing system as a matter of course.
It is assumed that the substrate has direct access to the host memory and its operation is controlled by the host. Thus, the host can direct a DMA transfer between the main memory and the memory on the board accessible to the FPGA. Furthermore, when using the method according to the invention, the substrate memory is either an FPGA or (via a PCI interface).
You only have to make a single port connection to one of the hosts that accesses it from time to time.

FIG. 2 shows a simulation technique of the method according to the present invention. Circuit compiled (using compiler 2.5) SimPLE instructions are simulated
Along with the vector set is transferred to onboard memory 2.1 using DMA. Each instruction is SimPLE
Each element processor (PE: process) in 2.6
ing element) Specify the operation of 2.31 to 2.34. Each instruction represents one slice of the netlist. Executing all the instructions simulates the entire netlist for one simulation vector. So, for each simulation vector, all instructions are streamed from the board's memory to the FPGA 2.2 and the resulting vector is returned and stored in the onboard memory 2.1. If the SimPLE instruction is larger than the FPGA memory bus on the board,
It is finely time-shared and reorganized using the extra hardware on FPGA 2.2. When all the simulation vectors have been processed, the resulting vector is returned from the board to the host 2.4 by DMA processing (by the DMA / PCI controller 2.3). This allows another simulation vector to be simulated if desired. Host control of the entire simulation is performed via API 3.1 (shown in FIG. 3).

To quantify the simulation speed,
User cycle, processor cycle (Reference <16
>) And FPGA cycles. The FPGA cycle is the clock period of FPGA 2.2 with SimPLE 2.6 configured. Processor cycles are the speed at which SimPLE 2.6 runs. This is defined as the time required to complete one SimPLE instruction. Normally, one instruction completes in one FPGA cycle, so the processor
The cycle is the same as the FPGA cycle. However, if the instructions are time-shared (ie, the SimPLE instructions are larger than the FPGA memory bus), the processor
The cycle will be longer than the FPGA cycle. For example, S
If the imPLE instruction is twice as wide as the FPGA memory bus, then there are twice as many processor cycles as FPGA cycles. Finally, a user cycle is the time it takes to fully simulate (ie, process all instructions) a single simulation vector netlist.

Next, the simulation speed is quantified. When targeting the SimPLE architecture with an instruction width of IW, it is assumed that the SimPLE compiler 2.5 will generate N instructions per netlist. If the FPGA memory bus width is BW and the FPGA clock cycle is FC, then the user cycle UC and the simulation speed R are given by: _{U C = N × [I W} / B W] × F C (1) R = 1 / U c (2)

Therefore, the simulation speed is (i) the number of instructions generated by the compiler, (ii) the instruction width,
And (iii) the FPGA clock cycle can be reduced.

If the compilation of a very large scale circuit generates excessive instructions that cannot fit in the onboard memory, the instructions are finely divided and individually DMA-processed.
This process affects overall performance, but
The scalability of SimPLE 2.6 is maintained.
However, if you upgrade your onboard memory,
Scalability can be achieved without any performance loss. Also, by adjusting the amount of memory, it becomes possible to simulate a very large netlist. For example, a board with 256 MB SDRAM can hold all 50 million gate netlist instructions.

Method according to the invention (especially SimPLE)
One of the goals is to create an inexpensive hardware accelerator that can use general purpose logic chips (eg, FPGA boards, etc.). This board is a commercially available FPG
It is "plug-and-play" compatible with virtually any computing system because it consists of an A, memory, and PCI interface. It is assumed that this board has direct access to main memory, but its operation is controlled by the CPU of host 2.4.

FIG. 3 illustrates another example of the inventive technique. Gate circuit (MULTI-MILLION GAT
E CIRCUIT 3.2 compiled instructions (S
imPLE instruction) uses simulation vector set with onboard memory 2.1 using DMA.
Transferred to. For each subsequent simulation vector, FP in which all instructions correspond to one user cycle (ie, one simulation cycle)
Streamed over GA 2.2 and the corresponding result vector is stored back into the board memory. When all simulation vectors have been processed, the resulting vector is returned to the host main memory 3.3 by DMA processing. If there are still test vectors, they can be simulated at this point as well.

If there are too many instructions that cannot fit in the onboard memory due to the compilation of a very large scale circuit,
Instructions are finely divided and individually DMA-processed. This affects overall performance, but SimP
LE 2.6 scalability is maintained. However,
Onboard memory 2.1 can be upgraded to achieve scalability without performance loss. For example, 256MB DRAM
With a substrate having, it is possible to simulate 20 million gate netlists.

In the following sections, instructions and simulation
Describe the vector transfer process and the interface software required to perform the hardware simulation.

A) Instruction Transfer Most SimPLE configurations are large-scale Virtex-.
2 It easily fits in FPGA, but some commands have large command words. For example, processor x 64, register x 6
4, the simulation processor with register read port x2, 16K memory block x32,
It requires 3080 bits per instruction. The largest Virtex-2 FPGA has a data pinout of around 1100. Therefore, it is necessary to time-division the instruction and transfer it to the FPGA in a plurality of processor cycles. The HDL generator is in charge of this process and creates dedicated hardware that enables time sharing of instructions. This extra hardware is part of the SimPLE architecture and is used as hardware specific to the FPGA package present on the board.

B) Transfer of simulation vector The value set consisting of the primary inputs of the netlist to be simulated represents the simulation vector. Several simulation vectors are commonly used when verifying the functionality of a netlist. In the simulation, an output vector or result vector is calculated for each vector. Therefore, SimPLE
2.6 must process three types of "board level" instructions. The three types are an instruction representing a simulation vector, an instruction representing an actual SimPLE instruction generated by the SimPLE compiler 2.5, and a dedicated instruction for reading a result vector.

Primary input (PI: primary in)
put) from the onboard memory to SimPLE2.
It is written to the local scratchpad memory in 6 and accessed by the element processor. Similarly,
The primary output (PO) is S
Element Processors 2.31 to 2.3 in imPLE2.6
4 is written to the scratchpad memory and read from the onboard memory.

Large gate-level circuits have hundreds of simulation vector bits. The transfer of these simulation vectors still needs to be time-shared. Unlike the case of time-sharing instructions, the degree of time-sharing required for simulation vectors is
Determined by netlist. Since the SimPLE architecture must be independent of the simulated netlist, dedicated hardware for time-sharing simulation vectors cannot exist on SimPLE 2.6. Therefore, the SimPLE interface software described in the next section takes charge of this time division. In each cycle, the input simulation vector is transferred from onboard memory to SimPLE.
Directly loaded into scratchpad memory (on FPGA 2.2) of 2.6.

The maximum number of bits that can be loaded into the scratchpad memory is equal to the total memory bandwidth. If the simulation vector is longer than the maximum memory bandwidth, the interface software splits the simulation vector into a number of words equal to the memory bandwidth.
An appropriate operation code for identifying it is added to each simulation vector.

A similar procedure is performed for the primary output,
Offloaded from FPGA 2.2 at a pace equal to memory bandwidth.

C) SimPLE interface software The interface software generates a board level instruction by inputting the simulation vector specified by the user and the SimPLE instruction generated by the compiler. These instructions are transferred onto the onboard memory 2.1 by DMA processing using the API provided on the FPGA 2.2 board.

Board level instructions distinguish between three input simulation vectors, output simulation vectors, and actual simulation processor instructions. The three cases are distinguished using three kinds of operation codes. The opcode bits are embedded before the input simulation vector bits or SimPLE instruction bits to generate board level instructions. If the opcode points to the output simulation vector, the remaining instruction bits are tristated.
Read from SimPLE 2.6 using the bus.

In addition to embedding the appropriate opcode bits, the interface software also organizes the primary input and output vectors. simulation·
Vectors are sequentially specified by the user. However, since the simulation vectors are transferred directly to the SimPLE 2.6 scratchpad memory block, the bits are reorganized based on the memory organization. Further, the POs sent from SimPLE are similarly reorganized to generate the final result vector.

2. Architecture Here we will focus on the problems encountered when simulating large scale designs using a single general purpose FPGA 2.2. FPGA 2.2 is usually too small to emulate a netlist with millions of gates. Therefore, you first need to divide the netlist into partitions that fit in the device. After that, by repeatedly reconfiguring FPGA 2.2,
Partitions are sequentially simulated. This solution scales to the size of the netlist, but (because of the small configuration bandwidth) FPGA
It is not suitable for practical use because the reconfiguration overhead in 2.2 increases.

In the present invention, this configuration bandwidth problem is solved by introducing the concept of a simulation processor for logic simulation (SimPLE). SimPLE 2.6 is a virtual concept that is a netlist compilation destination. SimPLE
2.6, once configured into FPGA, SimPL
Various designs (or using E compiler 2.5)
Programmed for different parts of the design). S
The instruction for imPLE is the data I / O of FPGA 2.2.
Since pins are used, there is no effect even if the configuration bandwidth is small.

(1) SimPLE Architecture SimPLE 2.6 is based on the VLIW architecture model. Such architectures can take advantage of the essential parallelism that is abundant in gate-level netlist simulations. Figure 4
Shows the template of SimPLE 2.6. This S
The template for imPLE 2.6 is a very simple functional unit interconnected, namely an element processor 2.31.
Composed of ~ 2.34 large arrays.

The respective element processors 2.31 to 2.34 are
Since any two-input gate can be simulated, it is possible to evaluate many gates simultaneously in each cycle. This template comprises a distributed register file system 4.2 for storing intermediate signal values, which achieves very high accessibility at high clock speeds. In addition, since the number of registers is limited by hardware constraints (since FPGA 2.2 does not have a large number of registers), the distributed memory system 4 that enables spill processing of registers is used as the second memory hierarchy. .1 has been introduced. This allows memory loading and storage of registers. Reference numeral 4.3 is a crossbar.

Further, the presence of a plurality of memory banks realizes high speed simultaneous access. Only the total memory size limits the number of intermediate signal values that can be stored, and this size can be very large in modern FPGA 2.2. For example, a large Virtex-I
The total size of the block RAM in I is about 3.5 million bits. FIG. 5 shows the maximum number of intermediate values required for a typical netlist for an ASAP schedule, assuming no resource constraints. The memory capacity available on the FPGA far exceeds the maximum memory capacity required to store intermediate values. Therefore, the scheme of the present invention provides a scalable, fast, and inexpensive solution for solving the problem of single FPGA logic simulation.

Summarizing the above, SimPLE 2.6 is characterized by:

The number of element processors (PE). Each element processor can be a single gate or a more complex gate (eg, a combination of NAND, NOR, OR, NOR, etc.). Here, this is Sim
This is called the "width" of PLE.

The number of registers included in each register file. In the implementation according to the invention, each element processor is distributed in such a way that it stores an individual register file. Such a distributed register file system enables faster access compared to large general purpose multiported register files.

The number of read ports on each register file.

The size of each memory bank.

The span or number (from the PE's point of view) of the port of each memory bank. The number of ports in a memory bank is equal to the number of PEs, or bank span. Therefore, each PE can access the memory bank at the same time.

The size of each memory word. This is a unit of memory access.

Memory latency, ie the number of cycles required to perform a single memory load or store.

• Interconnect latency. This is 2 P
It means an extra register inserted to pipeline the interconnection between Es (shown as crossbar 4.3 in FIG. 4). Si on FPGA 2.2
During placement and routing of mPLE 2.6 instances, interconnects are often on the critical path. Therefore, by inserting a register,
The overall clock speed can be increased at the expense of some computational efficiency.

Unlike the configurable parameters above,
The following properties of SimPLE 2.6 are unchanged.

PE is a simple 2-input gate.

Each register file is written or "memory loaded" by its element processor.
It can only be written directly from memory during execution.

Each register file has one extra read port, which allows memory storage.

Full interconnection (Crossbar 4.3)
Sets each read port of each register file (excluding the read port for storing memory) to each PE in the system.
Connect to the input of.

(2) Advantages of SimPLE SimPLE 2.6, whether FPGA-based or not, has some essential advantages over software cycle-based simulation and hardware emulators. There is.

A) Parallelism In SimPLE 2.6, since a plurality of element processors can execute simultaneously in a single cycle, a characteristic that a large amount of parallelism can exist in cycle-based simulation can be utilized. This was not possible with conventional processors, or software implementations.

B) Access to Registers and Memory The architecture model of the simulation processor allows easy access to a much larger number of registers than is possible with conventional CPUs. This property is important because it allows the register to be accessed in a single cycle. Further, since the memory banks are close to each other, high-speed memory access is possible when register spill (overflow) occurs.

C) Configurability Since SimPLE 2.6 is a virtual architecture constructed on general-purpose FPGA 2.2, the compiler is optimized for Si.
It has the flexibility needed to target the mPLE configuration. For example, depending on the application, it may be necessary to increase the number of registers and memories, or it may be desirable to increase the number of element processors. Corresponding to such various situations, multiple SimP
The LE configuration can be recompiled into one library and the compiler can be made to select the optimal configuration from this library. Using this scheme also eliminates the complication of having to perform the FPGA 2.2 placement and routing process each time.

D) Scalability SimPLE 2.6 has the property of being transparent to the size of the netlist, much like a software solution. The netlist is compiled into an instruction set. Any number of SimPLE2.
6 can be run. The larger the size of SimPLE 2.6, the better the performance, but the smaller size SimPL
Even with E2.6, netlist simulation is possible.

E) Configuration Bandwidth SimPLE 2.6 avoids problems due to the small configuration bandwidth of the FPGA due to the data I / O pins for instructions.

F) Division of netlist If the netlist is too large, it is divided so that it fits in the board memory, and each part is transferred individually to maintain scalability.

The number of instructions generated increases as the size of the netlist increases. A large netlist may have too many instructions to fit in board memory, but this does not interfere with the simulation. The simulation proceeds as follows.

The instruction set is divided into subsets sized to fit in board memory. Dividing this instruction is equivalent to dividing the netlist itself. The instruction subset is individually transferred to the board memory by the DMA processing.
The first subset is streaming to FPGA2.
On passing 2, the corresponding part of the netlist is simulated. The second subset then replaces the first subset in the substrate memory and the process continues. The state of the netlist being simulated is maintained between the subsets.

Example: A large instruction set I is divided into sizes I1 and I2 that fit in the board memory. First, the simulation vector sets T and I1 are transferred to the substrate memory by DMA processing. All instructions in I1 associated with the first simulation vector t1 in the simulation vector set T are streamed through the FPGA 2.2. Subsequently, I2 is transferred to the substrate memory by the DMA process and replaces I1. All instructions in I2 are streamed to F
Pass through PGA 2.2. This completes the simulation of the vector t1. It should be noted here that the performance of the DMA process is affected in the course of the simulation, but the scalability of the method of the present invention is maintained.

G) Division of Simulation Vectors For large simulation vector sets,
It can be divided into smaller blocks and each block can be individually simulated on the substrate. Both the simulation vector and the instructions must fit in the board memory to perform the simulation. The present invention according to claim 1 deals with the case where an instruction does not fit in the memory.

If the simulation vector does not fit, it can be divided into blocks and each block can be simulated individually. For example, a design has 1 million vectors, but on-board memory is 50 (in addition to instructions).
If only ten thousand vectors can be held, the simulation vector set is divided into two blocks of 500,000 vectors each and each block is simulated individually. This does not significantly reduce performance.

H) The primary output of the register visualization simulation does not reflect the state of the internal registers. To visualize the internal registers, the technique according to the invention loads and stores from a specific location in SimPLE memory. After simulation, board-level instructions extract register values from these memory locations. Here, note the following two points.
(A) The location where the register actually resides in the memory of SimPLE 2.6 is not important and any location can be used. As long as the compiler and tools know where to store the register, you can use board-level instructions to extract that value and use it to visualize it. (B) Board level instructions are different from the instructions generated by the compiler. These instructions are (i) put the simulation vector in FPGA 2.2, (ii) put the compiler instruction in FPGA 2.2, (iii) FPG
It executes four functions: obtaining a result from A and (iv) obtaining a register value from FPGA 2.2.

I) Interface to general-purpose simulator The simulation processor is a general-purpose software
Can interface to the simulator. The technique of the present invention interfaces the simulation processor to a general purpose software simulator by switching the state of the design. For example, during the event-driven simulation using a software simulator, the user switches the entire circuit state to be simulated to SimPLE2.6, executes a functional simulation of many vectors, and then switches again to the final state. Can be returned to the software simulator. Therefore, SimPLE 2.6 can be a transparent back-end accelerator for software simulators.

It should be noted here that the state switching can be performed using a register visualization technique.

J) Binarization and quaternarization simulation In order to execute the quaternarization simulation, each wire of the simulation processor has a width of 2 bits.
A wire having a width of 2 bits can represent four states of 0, 1, X, and Z. The overall architecture of the simulation processor remains unchanged.

3. RTL Circuit Architecture As shown in FIG. 22, the technique according to the present invention is extended to RT.
It is easy to apply to the L circuit. The simulation processor architecture for accelerating RT-level circuit simulation is b bits wide each,
An arithmetic logic circuit (ALU) array (one of which is shown as 22.1) having functions of addition, subtraction, sign extension, comparison, and bitwise Boolean operation is provided.

Also, a signed multiplier array (one of which is shown as 22.2) that produces a result each having a width of b bits.
Also prepare. Furthermore, in the position close to the element processor,
It also has a distributed register file system 22.3.
This distributed register file system 22.3 has a small number of read and write ports and an access time equal to the interconnect latency. In addition, it has a main interconnect system 22.4 consisting of b-bit crossbar lines connecting all distributed register files. For each ALU, a separate bit-width carry register file 22.5 is provided to hold the carry value obtained from the ALU operation. Pipelined carry chain crossbar interconnection system 2
2.6 is a bit width carry register file 2
2.5 are connected together to allow carry propagation by pipeline processing between ALUs. Distributed memory system (Distributed register file system 22.3)
Are located in close proximity to ALU 22.1. An interface from the above architecture to an external memory is located on the board and consists of instructions and opcodes that specify the reading and writing of vectors and operations.

4. Compiler (1) Definition Before describing the compiler in detail, some commonly used terms are defined.

The "design" is a gate-level netlist to be simulated. The design may be fully self-contained hardware or it may represent part of a large netlist that requires accelerated simulation. The value set consisting of the primary inputs of the design represents the simulation vector. Several simulation vectors are commonly used when verifying the functionality of a design. For each vector, one output vector or result vector is obtained.

The design is represented by a directed graph. The nodes of the graph correspond to the hardware functional blocks in the design. A node can have multiple inputs, but at most one output. Design input ports are nodes with no inputs, and design output ports are nodes with no output. Wires (also called "nets")
Interconnect nodes. Each wire has a single source (driver) and multiple destinations (fanouts) called "pins".

In the description regarding the compiler, the allocation of one node to a specific functional resource (element processor) is called "scheduled". Element Processor (PE) to schedule nodes
Must be free and ready to perform operations on that node, and at least one register accessible to that PE must be free and ready to store the output of the node. . In addition, it is also necessary that the node's input be successfully connected to its source using the register file interconnects and register ports. The latter is called "input routing".

A node is always scheduled after all its sources have been scheduled in the previous step. Specifically, given an interconnect latency of L, in order for a node to be scheduled in the current step, all sources for that node must be scheduled at least L time steps before.

A node is said to be "ready" at a time step if it can be scheduled at that time step.
Generally, a node is in the ready state if all its sources have been scheduled in the previous step. However, in SimPLE with interconnect and memory latency constraints, additional conditions must be met for a node to be ready. If the interconnect latency is IL and the memory latency is ML, then node N is considered to be ready at its time step T only if the following conditions are met:

Each source node of N is already scheduled at time Ts (where T> = Ts +
IL).

A load for N source nodes loaded from memory is being performed at time step Tls (where T> = Tls + IL + M
L).

A node set that is ready at some point in the scheduling process is called the "ready front". The ready front consists of two types of nodes. The first type represents a node set whose source is the liveness register. The second type is
Nodes with some source registers spilled into memory
Represents a set. Such nodes are called "nodes with stored inputs."

The length of the schedule is the total number of time steps. The length of the schedule is also the number of instructions generated. Assuming that there is one design and set of compiled instructions, "utilization" means the percentage of processors that are performing operations, memory loads, or memory stores in a schedule. Due to architectural constraints, some processors are forced to idle and utilization is always 100%
Less than

(2) Scheduling Algorithm The compiler schedules the design under resource constraints. The compiler maps the nodes to element processors and the wires interconnect the nodes to registers. Registers are allocated such that utilization of the registers as a whole is minimized, subject to register port constraints. If the register file is full, the compiler chooses to spill the registers and store them in memory. These registers are reloaded as needed. Scheduling algorithms are deterministic and very fast (ref. <10>).

First, topological sort is executed on the netlist, and subsequently, buffers are inserted at several places to solve the constraint condition. This will be described in detail in section f) described later. The node is then scheduled for individual instruction. FIG. 6 shows the flow of the entire algorithm. In the following sections, each part of the flow will be described.

A) Node Scheduling In the compile process, the scheduling of each node in the design is performed while complying with all the constraints of the architecture. Node scheduling consists of the following steps.

Node selection. A node to be scheduled is selected from the ready front. This choice influences the future node selection order and is a very important factor in obtaining a compact schedule.

Input routing. Each ready front node can only be scheduled at a particular time step when it is ready to route all its inputs. Whether routing is possible between the value stored in the register file and the input of the PE is determined by the interconnect and the number of register read ports available. Once the crossbar interconnect is complete, one PE's register file and another PE's
It is possible to directly transfer data to and from the input of. However, because of the limited number of register ports, the number of values that can be read from a particular register file at a given time step is also limited.

Assignment of PE. Once input routing is complete, the node is scheduled on the element processor with the least number of used registers. This is a greedy scheme that seeks to minimize register utilization.

Register allocation. After the PE is allocated, the register released in the register file of the element processor in which the node is arranged is allocated for storing the node output. The availability of freed registers is guaranteed because nodes that do not have freed registers are never assigned to that PE.

B) Node Selection Heuristic The goal of the technique of the present invention is to simultaneously achieve the minimization of schedule and the maximization of utilization by speeding up the selection process by heuristics.
The execution time of the compiler increases as the optimality of the node selection heuristic increases.

The technique of the present invention evaluates the feasibility of scheduling by paying attention to the following two characteristics of the node N.

The number of registers released by scheduling N. Prioritizing nodes that release a large number of registers is a simple greedy strategy to minimize register utilization.

-N fan-out. Nodes with high fanouts increase the scheduling potential of the node at future time steps.

Therefore, a node that releases a large number of registers and has a high fanout is given priority. In Figure 7,
6 illustrates a node selection process.

C) Store registers in memory Nodes that do not have released registers cannot be scheduled in a time step. In addition, the time steps may be empty if the nodes included in the ready front do not meet the interconnect latency constraints. Under these circumstances, a store operation is scheduled in each element processor where the register file is full and freed.

The live register is released from the full register file by storing its value in scratchpad memory. Such an active register in the register file is the output of the already scheduled node N, but some of its fanouts remain scheduled. At this point, N is simply selected based on its number of fanout nodes present in the ready front. A usable first node is stored that has no fanout in the ready front. If no node in the register file satisfies this constraint, then the node with the least fanout in the ready front is selected and stored in memory. FIG. 8 shows the process of storing registers.

D) Load register from memory If the input of the node N is scheduled and temporarily stored in memory, it must be loaded before N is scheduled. Present on the lady front,
After all candidate nodes with no stored inputs have been scheduled, if there are element processors available, the node with the stored inputs is selected. The input of the selected node is loaded from memory, making that node a candidate for a schedule at a future time step. Node N is selected from the list of ready nodes with the stored inputs based on the following factors.

The number of registers released by placing N. The larger the number of registers, the better the node is for loading inputs and scheduling N.

The number of fanouts of the stored input in the ready state. This fanout number directly affects the number of nodes scheduled on input load. If a node has many nodes in its fanout in the ready state, it becomes a good candidate for loading.

FIG. 9 shows the process of loading the inputs of the nodes present on the ready front. Loads are scheduled first, followed by ready nodes in future time steps.

E) Processing of user-specified registers The registers in the netlist to be simulated must be processed by a special method. The method of the present invention distinguishes between user cycles and processor cycles in a manner similar to the definition given in document <16>.

The processor cycle is SimPLE.
2.6 means the speed at which it operates. This is one Si
It can be defined as the time required to complete the mPLE instruction. This is except for processing when the instruction word is time-shared (ie, the SimPLE instruction has more bits than the FPGA data I / O pin).
Identical to SimPLE 2.6 clock cycle on PGA 2.2. When the instruction word is time-divided, the effective speed of the operation decreases. For example, when the netlist is divided into N instructions by compilation, the instruction word size is I, the available pinout of FPGA 2.2 is P,
When the clock speed of the FPGA 2.2 is C, the time division coefficient F is I / P, and the clock speed of the processor is C / F. User cycle, on the other hand, means the time it takes to fully simulate a netlist for one vector. In the case of the above example, the user clock speed would be C / (F * N).

If the input of gate G in the netlist is a user register, the value to be used for the evaluation of this gate is the register value of the immediately preceding user cycle. If the register is the output of gate G in the netlist, the value to be stored in the register is G in the current user cycle.
Is a value calculated by. However, the last user
If you need to use the cycle register values,
This value must also be available in the current user cycle. Therefore, the user register R is scheduled in the following way.

[0162] · R is divided into two nodes _{(D R} and _{Q R).} D _R input of R, _{Q R} represents the output of the R.

Scheduling constraints are imposed on D _R. In other words, D _R must be scheduled in the time step later than the Q _R.

[0164] · D _R when scheduling, the value of the input is stored in the memory. This is the value of R for the current user cycle (used in the next user cycle)
Is.

[0165] of the · Q _R at the time of scheduling, the value of the input is loaded from memory. This is the value of R from the previous user cycle (used in the current user cycle). User registers indicates how the compiler handles user registers. FIG. 10 shows how the compiler handles registers.

F) Primary input (PI) and primary output (PO)
Processing gate level designs can have large numbers of PIs and POs, which can even amount to thousands of bits. PI
SimPLE to speed up loading and storing POs
The process of addressing individual bits to arbitrary locations in the memory is not performed. Instead, all PIs are loaded sequentially from consecutive memory locations. Similarly, all POs are stored sequentially from consecutive memory locations. Furthermore, when loading or storing from outside FPGA 2.2 (ie from board memory), PI and PO (via external software) can do memory word size (read from and write to memory). Units) are grouped into words. This makes it possible to load or store one word per cycle. This is much faster than loading the individual bits.

These assumptions further simplify the input-output interface of SimPLE 2.6, but result in constraints on the compiler. First, the constraint on the placement of PI and PO by the compiler becomes severe. This is because the scratchpad memory is divided into banks. Each bank has a narrow range of P
Only these PEs can span and access E. Therefore, the compiler
It must be assigned to a particular memory bank based on its index.

In addition, since PO represents a memory store, it must be placed in the same PE as the PO's direct (but in a later time step) source to store the register. Since the PO also needs to be stored in a particular memory bank, this imposes constraints on the direct originator of the PO. That is, the direct source of the PO is a constraint that it must be located within reach of the particular memory bank in which the PO is stored.

Due to the above restrictions, there is a possibility that some netlists cannot be scheduled. For example, if PI is shorted to PO (which can happen to some netlists after optimization), the indexes will be different from each other, which forces PI and PO to be stored in different memory banks. May be Such abnormalities are
Resolved by inserting a buffer. This consumes some resources, but increases scheduling flexibility.

PI and PO are stored in SimPLE 2.6.
It is organized into memory banks as shown in FIG.
Each memory bank has a portion dedicated to each of PI and PO and a general-purpose portion used for spill processing of registers during simulation. This organization of PIs and POs allows each PE to read primary input bits (or write primary output bits) at maximum memory bandwidth speed. This organization also prevents bits from being addressed to any memory location. Assembling the PI can be easily performed by the interface software.

(3) Compile Result and Analysis In the technique of the present invention, the result is analyzed by combining the industry standard, ISCAS, and other typical benchmarks.
For individual results of this work, four industry standard benchmarks (NEC1-4), PicoJava (R) processor integer and microcode units (IU and UCODE), ISCAS89, ITC99 literature <
20>, 6 large gate level combinations selected from common bus and USB controller and serial netlist. The size of the benchmark is 31,000 to 43 in terms of the number of 2-input gates.
It is in the range of 10,000.

A) Storage requirements Registers and memories are used to store temporary values generated during simulation. If there are not enough registers and memory, the circuit with too many temporary values is SimPL.
It cannot be simulated using E2.6.
However, in recent years FPGA 2.2, the amount of memory is extremely large. Looking at Figure 12, processor x 48, registers x 64, read port per register file x
The amount of storage required when targeting the SimPLE architecture with FPGA2.
It can be seen that the memory available on top of the 2 provides a margin.

B) Instruction Generation Complexity In the case of a netlist having n nodes, the number of ready front nodes is O (n). (2) In order for the heuristic in the b) node selection heuristic of the scheduling algorithm to select one node from the ready front, the number of released registers, the fanout, and the fanout number included in the ready front are set. I need. Both of these can be calculated in advance. Therefore, the time required to select one node is O (n). The technique of the present invention makes this a fixed time by the following method. At the start of the time step, the heuristics of all nodes included in the ready front are pre-computed and inserted into a table indexed by the heuristic values. The i-th entry in the table contains all nodes in the ready front with a heuristic value of i. Therefore, the time required to select these nodes is O (1) time. In Figure 13, Ul of 440MHz
1 illustrates the speed of a compiler running on traSparc 10.

C) Effect of SimPLE Parameters on Compile Efficiency Next, the effect of important SimPLE parameters on the number of instructions generated by the compiler will be evaluated. Since the size of each memory bank was fixed at 16K bits and the memory word size was 4 bits, both were Virtex-I.
A block RAM on the I FPGA can be used. The latency of memory and interconnects varied with the size of the instructions. F through interconnection and memory pipeline processing
The clock speed of PGA 2.2 is improved, but the compilation efficiency is reduced. Experiments have shown that two cycles of interconnect and memory latencies are required to achieve a sufficient clock speed on FPGA 2.2. This latency is converted into an FPGA cycle. Therefore, 1 FP processor cycle
If it exceeds GA cycles (ie, the SimPLE instruction requires time sharing), the compiler assumes that the interconnect and memory latencies are both one. This is because consecutive instructions are divided into units of 1 processor cycle, which corresponds to 2 FPGA cycles or more.

FIG. 14 shows fluctuations in the average number of instructions generated by the compiler due to fluctuations in the number of processors, the number of registers, and the number of register read ports included in SimPLE 2.6. That is, it shows the effect of increasing the number of register ports on the compilation efficiency. X-axis is P-
Here, r is the number of processors in the SimPLE implementation example, and r is the number of registers in the SimPLE implementation example.

It should be noted here that the number of processors is three.
When the number of registers is 2 or more, the average number of instructions does not change even if the number of register ports exceeds 2. This can be explained by the fact that all netlists are mapped into 2 LUTs at compile time, and for 32 processors there is a sufficient amount of parallelism to minimize the duplication of values on the processor (single Duplicate values on one processor necessitate the use of multiple read ports). From FIG. 15, it can be seen that the number of CLBs consumed is increased by using the extra read port (Xilinx Virtex-II F).
Estimated by PGA). Here, FIG. 15 shows the effect of increasing register ports on the utilization rate of virtex-II CLB. The X-axis shows Pr, where P
Is the number of processors in the SimPLE implementation example, r is SimP
It is the number of registers in the LE implementation example.

Therefore, here, the limitation is limited to the SimPLE architecture of 2 read ports. Also, the memory configuration and the interconnect and memory latencies are fixed to the above values.

5. Prior to the FPGA synthesis simulation, Si on FPGA 2.2
It is necessary to configure mPLE2.6. You only have to do this once. Once this configuration is complete, any number of simulations can be run. It is also possible to previously generate several SimPLE architecture configuration bits and store them in a library. Therefore, FPGA2.
The simulation time is not affected by the time spent placing and routing SimPLE 2.6 on H.2. However, the FPGA clock speed affects the simulation speed. Therefore,
It is important to place and route SimPLE 2.6 on FPGA 2.2 while simultaneously achieving high clock speeds. This section describes the FPGA 2.2 placement and routing procedure.

The HDL generator produces a description of the behavior of SimPLE 2.6 with a particular set of parameters (number of processors, memory size, etc.). If necessary, extra hardware for time-sharing SimPLE instructions can be generated.
This description is synthesized by Synopsys FPGA Ex.
Virtex-2 done using press
Xili mapping, placement and routing on FPGA
nx Foundation 4.1i.

(1) FPGA placement / routing technique for SimPLE The placement of FPGA 2.2 is extremely important for proper routing. Previous studies have demonstrated that correct placement prior to routing reduces congestion and significantly improves clock speeds (ref.
12>, <4>). The technique of the present invention uses a regularity driven scheme to achieve good placement. SimPL
Each instance of E2.6 has an inherently high degree of regularity because all of the element processors, memory blocks, and register files are identical to each other. FIG.
Shows the hierarchy of SimPLE 2.6 with all rule units.

In the disclosed FPGA placement / routing technique, the following four steps are executed. These steps were: (i) identify the best repeat unit in the design, (ii) shorten pre-place the repeat unit as a single (relatively placed) hard macro, and (iii) use macros Placement of the entire design, (iv) overall final routing.

Experiments have shown that among the few macros possible in FIG. 16, the largest macro (ie the topmost macro) is the best. Larger macros show the best shortening rates and relatively less IO. Once identified, the macro is synthesized, mapped to the FPGA CLB and placed. The entire SimPLE description is instantiated as a macro and is mapped, placed and routed. Optimization is not performed across the boundaries of prepositioned macros. The entire macro flow is fully automated using scripts executed by interacting with FPGA tools.

Table 1 shown in FIG. 17 is a comparison of FPGA clock speeds with and without the macro strategy in the technique disclosed. All experiments are based on the latest Xilinx Foundation
n 4.1i. Up to a 3x improvement was observed using the techniques of this publication. When the structure shown in FIG. 16 is shortened to a macro, the distribution of components arranged in the FPGA 2.2 is improved, and the clock speed is less affected by the number of registers in PE.

The simulation speed can be calculated by Equation 2 using the number of compiled instructions, the instruction width, and the FPGA clock cycle. Fig. 18 shows various Si
The simulation speed (vectors / second) is shown for the FPGA memory bus width values of 256 and 1024 in the mPLE architecture. As can be seen from this figure, if the FPGA memory bus is 1024 bits wide, the processor × 48 architecture is the best. The wider the architecture, the more instructions that require time division, so the wider the width, the better. Architectures with small FPGA memory bus widths had about the same simulation speed. This is because if the FPGA memory bus width is small,
We show that the advantages of the wide architecture are offset by the disadvantages of the wide instruction range.

6. Experiments, Analysis, and Discussion In this section, a large Virtex-II FPGA
The speed gains actually obtained when SimPLE 2.6 is mounted on 2.2 and when the first prototype according to the technique of the present invention is mounted on a general-purpose board will be described.

(1) Virtex-II with 8 million gates, based on the results of the speed-up experiment on Virtex-II.
On the I FPGA (XV2V8000), element processors x 48, registers x 64 per element processor,
Register read port per register file ×
2, SimP with distributed memory system consisting of banks of 16 Kbits each spanning 2 element processors, memory word size 4 bits, and interconnect latency 2
An LE processor was synthesized. Foundry of Xilinx
ation tool.

A) Comparison with cycle-based simulation Ver ve is used as a cycle-based simulator.
A rilog compiler and Cyco were used. Ver reads the structural verilog and produces an intermediate form called IVF. Cyco reads IVF,
Generate a straight line C code that represents the structural verilogx. FIG. 19 shows an experimental tool flow according to the inventive technique for cycle-based simulation and SimPLE. Sparc V at 440MHz speed
UltraS with 9 processors and 1GB RAM
Compile the C code on a parc 10 system,
Ran It should be noted here that it took a long time (several hours) to compile the generated C code. In this way, the short compile time may cause S
This is an advantage of imPLE2.6.

FIG. 20 shows 440 MHz UltraSp.
Compared to a cycle-based simulator running on an arc workstation, SimPLE 2.6 with 48 processors, 64 registers running at 100MHz (most boards run at 100MHz, which limits this speed) The resulting speed improvements are shown. The right column of each benchmark shows the speed improvement achieved when the FPGA memory bus width is 1024 bits, and the smaller left column shows the speed improvement when the FPGA memory bus width is 256 bits. The range of speed improvement is 200 times to 3000 times for 1024 bit FPGA memory bus width, and 256 bit F
In case of PGA memory bus width, this magnification is 75 to 10
It is reduced to 00 times.

B) Comparison with Zero Delay Event Driven Simulation In this comparison, ModelS with zero gate delay is used.
Im version 5.3e was used. It was used. Each benchmark was optimized in exactly the same way as for SimPLE 2.6, then loaded into ModelSim and run event driven simulation. Again, 440MHz Ult for simulation
raSparc 10 was used. FIG. 21 shows the speed gain obtained for the same benchmark. The range of speed improvement is 300 times to 6000 times for the 1024-bit FPGA memory bus width.
In the case of A memory bus width, this magnification is 75 to 1500
Doubled.

(2) Speed Improvement Using Prototype AlphaData (www.alphadata.
co. general-purpose FPGA board (ADCRC100)
0) was used to implement the prototype. This board is
Xilinx with 128-bit FPGA memory bus width
It comprises a Virtex-E 2000 FPGA. We have a fully operational simulation environment and a graphical user interface that allows the user to compile and simulate the netlist and display the selected signals, which we will experiment with. used. Speed enhancements were measured on a small prototype board for two designs. One design is 40
The 10,000 gate sequential benchmark, the other design is part of the PicoJava® processor's pipelined datapath. In both designs, the prototype board has 30 times the cycle time of ModelSim.
It was 12 times faster than the base simulator.

(3) Reason for speed improvement The main reasons for this speed increase are (i) parallelism and (ii) S.
A large number of registers and memories in imPLE, (i
ii) Wide bandwidth between FPGA and substrate memory, and (iv) High FPGA clock speed.
It is a point. A superscalar processor using dynamic parallelism technology usually has two to one cycle.
Executes three instructions. However, SimPLE can execute the same number of instructions as one element processor per cycle. SimPLE has a large number of registers (32 or more registers dedicated to one element processor), which reduces memory operations.

Further enhancing the efficiency of the simulation process is the high bandwidth between the FPGA and the substrate memory. Thus, even a wide SIMPLE instruction can be transferred quickly. Finally, the regularity of the SimPLE architecture enables high speed implementation on FPGAs. As the FPGA size increases, a larger SimPLE architecture can be implemented,
Further speed increase can be realized.

From the disclosure herein, other modifications and variations will be apparent to those of ordinary skill in the art. Thus, while only a few embodiments of the invention have been specifically described herein, it will be apparent that numerous modifications can be made without departing from the spirit and scope of the invention.

[0194]

As described above, according to the present invention,
It is possible to realize a hardware acceleration system having four advantages: (i) low cost, (ii) high performance, (iii) low turnaround time, and (iv) high scalability. In other words, while achieving cost, scalability, and turnaround time comparable to simulators, it achieves extremely excellent performance.

[Brief description of drawings]

FIG. 1 is a diagram showing a cost and performance comparison between a system to which the present invention is applied and a conventional simulator and emulator.

FIG. 2 is a diagram illustrating a concept for simulating a large netlist on a single FPGA using the SimPLE intermediate architecture according to an embodiment of the present invention.

FIG. 3 is a block diagram showing an overall system configuration according to the present invention.

FIG. 4 is a diagram showing an example of an architectural model of SimPLE with element processors, memory banks, wide register files with read ports, and crossbars.

FIG. 5 illustrates the maximum number of median netlist values when scheduled using the ASAP heuristic.

FIG. 6 is a flowchart showing an example compiler that performs scheduling and instruction generation.

FIG. 7 is a diagram showing an example of node selection for scheduling.

FIG. 8 is a diagram showing an example of spill processing of a register to a memory.

FIG. 9 is a diagram showing an example of loading an input of a node in the ready front.

FIG. 10 is a diagram showing an example of processing a user-specified register.

FIG. 11 illustrates allocation of primary input and primary output bits to specific slots within a memory system.

FIG. 12 is a diagram showing storage requirements of a SimPLE implementation example.

FIG. 13 is a diagram illustrating a compilation speed of a SimPLE implementation example.

FIG. 14 is a diagram showing the effect of increasing register ports on compilation efficiency.

FIG. 15: Increase in register port is virtex-
It is a figure which shows the influence which it has on the utilization rate of II CLB.

FIG. 16 is a diagram showing a maximum repeat unit in a hierarchy of SimPLE implementation.

FIG. 17 SimPL using a regularity driven arrangement
FIG. 6 shows an improvement in E FPGA clock speed.

FIG. 18 is a diagram showing simulation speeds (vectors / second) in various SimPLE mounting examples.

FIG. 19 is a diagram showing a tool flow in the case of simulating a gate level netlist using SimPLE in software implementation of cycle-based simulation.

FIG. 20 is a diagram showing the speed improvement of SimPLE compared to a cycle-based simulator.

FIG. 21 SimPLE compared to ModelSim
It is a figure which shows the speed improvement degree of.

FIG. 22 is a diagram showing the architecture of an RTL level circuit.

[Explanation of symbols]

2.1 Onboard memory 2.2 FPGA 2.3 DMA / PCI controller 2.4 Host 2.5 SimPLE compiler 2.6 SimPLE 2.31-2.34 PE 3.1 API 3.2 Gate circuit 3.3 Main memory 4.1 Distributed memory system 4.2 Distributed register file system 4.3 Crossbar

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Pranab Asher             New Jersey, United States             08540 Princeton, 4 Indie Pen             Dens Way NCE You               Inside the SAS ink F term (reference) 5B046 AA08 BA03 JA04

Claims (31)

[Claims] 1. A hardware acceleration system for functional simulation, comprising a general-purpose circuit board having a logic chip and a memory, wherein the general-purpose circuit board can be plugged into a computing device. , Computing ·
A device is adapted to direct a DMA transfer directly between the general purpose circuit board and a memory associated with the computing device, the general purpose circuit board configured using a simulation processor, the simulation processor comprising: A hardware acceleration system, which is programmable for at least one circuit design. 2. The hardware acceleration system according to claim 1, wherein the simulation processor is mapped to the FPGA. 3. The hardware acceleration system according to claim 1, wherein the netlist of the circuit to be simulated is compiled for the simulation processor. 4. The simulation processor comprises:
The hardware acceleration according to claim 1, further comprising at least one register processor including at least one element processor and one or more registers corresponding to the at least one element processor. system. 5. The simulation processor comprises:
A distributed memory having at least one memory bank
The hardware acceleration system of claim 4, further comprising a system. 6. The hardware acceleration system of claim 5, wherein the at least one memory bank is used for a set of elementary processors and their associated registers. 7. The hardware acceleration system of claim 5, wherein the register is capable of spilling on the memory bank. 8. The hardware acceleration system of claim 4, further comprising an interconnection system connecting the at least one element processor to another element processor. 9. The hardware acceleration system according to claim 4, wherein the processor element can simulate any two-input gate. 10. The hardware acceleration system according to claim 4, wherein the processor element is capable of performing RT-level simulation. 11. The hardware acceleration system according to claim 8, wherein the connection by the interconnection system is made through a register. 12. The hardware acceleration system of claim 11, wherein the interconnect system is pipelined. 13. The hardware acceleration of claim 8, wherein the register file is located close to an associated element processor.
system. 14. The hardware acceleration system according to claim 5, wherein the distributed memory system has a dedicated port corresponding to each register file. 15. The hardware acceleration system of claim 3, wherein the system can process the partitions of the netlist one at a time if the netlist does not fit in the memory on the memory board.
system. 16. The hardware acceleration system of claim 15, wherein the system is capable of simulating an entire netlist by sequentially simulating its partitions. 17. The hardware acceleration system of claim 3, wherein the system is capable of processing a subset of simulation vectors used in testing a circuit. 18. The hardware acceleration system of claim 17, wherein the system is capable of simulating an entire simulation vector set by sequentially simulating each subset. 19. The hardware acceleration system of claim 1, wherein the hardware acceleration system can be used interchangeably with a general purpose software simulator capable of exchanging the states of all registers in a design. 20. The hardware acceleration system according to claim 1, wherein both binarized and binarized simulations can be executed on a simulation processor. 21. The hardware of claim 1, further comprising an interface and an opcode, the opcode specifying read, write, and other operations associated with a simulation vector.
Acceleration system. 22. The simulation processor further comprises: at least one arithmetic logic circuit, zero or more signed multipliers, distributed registers each having at least one register associated with the ALU and the multiplier. The hardware acceleration system according to claim 1, comprising a system. 23. The hardware accelerator of claim 22, wherein the system comprises a carry register file for each ALU, the width of the register being the same as the width of the corresponding register. Ration system. 24. The hardware acceleration system of claim 23, further comprising pipelined carry chain interconnects connecting registers. 25. A method of performing a functional simulation of a circuit, comprising the following requirements. a) Compile the netlist corresponding to the circuit to generate the instruction set for the simulation processor b) Load the instructions into the onboard memory corresponding to the simulation processor c) Simulate on the onboard memory Transfer the vector set d) Stream the instruction set corresponding to the netlist to be simulated on the FPGA in which the simulation processor is configured e) Execute the instruction set to generate the resulting vector set f) Transfer the result vector to the host computer. 26. A method for performing functional simulation of a circuit according to claim 25, wherein if the instruction is wider than the bus connecting the onboard memory to the FPGA, the instruction is time-shared. . 27. A method of compiling a netlist of circuits for a simulation processor, comprising the following requirements. a) represent the design of the circuit as a directed graph where the nodes of the graph correspond to the hardware blocks in the design b) generate the readyfront subset of nodes ready for scheduling c) for the readyfront set topological·
Perform a sort d) select an unselected node up to the present e) complete the instruction and proceed to a new instruction if no element processors are available f) to perform the operation corresponding to the selected node , G) selecting the element processor with the highest number of associated free registers g) routing the operand from the register to the selected element processor i) repeating steps dh until there are no unselected nodes. 28. Based on a selection heuristic,
28. The method of claim 27, wherein the node having the largest number of registers released by scheduling the node and the largest fanout number of the node is selected. 29. The circuit netlist of claim 27, wherein when the register file is full, the register to be spilled is selected and stored in memory so that it can be loaded as needed. How to compile. 30. The method of claim 29, wherein if no registers are available in step f, the registers are stored in a memory bank by spilling. 31. The register selected for spill processing has the maximum number of registers previously scheduled based on the selection heuristic and released by the scheduling of the node and the maximum fanout number of the node. 30. The method for compiling a netlist of a circuit according to claim 29, wherein the register is a register which is an output of the node.