2009 12th Euromicro Conference on Digital System Design / Architectures, Methods and Tools

An on Chip Network inside a FPGA for Run-Time Reconfigurable

Low Latency Grid Communication

Jochen Strunk∗ , Toni Volkmer∗ , Wolfgang Rehm∗ and Heiko Schick‡

∗
Chemnitz University of Technology
Computer Architecture Group
Email: {sjoc,tovo,rehm}@cs.tu-chemnitz.de
‡
IBM Deutschland Research & Development GmbH
Email: schickhj@de.ibm.com

Abstract can be realized. Accelerating a Quasi-Monte Carlo

In this paper a low latency, on chip communication
network (NoC) for a run-time reconfigurable (RTR)
grid inside dynamically and partially reconfigurable
(DPR) FPGAs is proposed, which supports the ar-
bitrary placement of run-time reconfigurable modules
(RTRM) inside the grid. The dedicated, fully meshed,
silicon network should support the arrangement of
communication channels between the RTRMs within
the different partially reconfigurable regions (PRRs)
on the FPGA. The design of the network guarantees a
low latency communication of RTRMs without mutual
interference of each other. In comparison with an im-
plementation using FPGA resources the dedicated sil-
icon network could save an huge amount of resources
in terms of transistors. The new degree of parallel
communication provided for a RTR grid with arbi-
trarily placeable RTRMs offers new application fields
for DPR capable FPGAs. Multiple user applications
with inter-communicating offload compute kernels can
be loaded on a host coupled FPGA accelerator, a
real-time (RT) system with concurrent communication
tasks are possible and enhancing the functionality on
demand for embedded systems is conceivable. A case
study was conducted for proof of concept and for the
verification of the run-time environment system, which
manages the configurable network.
1. Introduction
FPGAs are utilized in various fields of application. In
high performance computing they have gained access
as special purpose accelerators for offloading compute
kernels. Due to the highly parallel fine grained archi-
tecture of FPGAs massive parallel processing engines
Simulation by the factor of 50 compared to a CPU
solution was shown by Woods et al. [1]. A speedup
of 25 was presented by Zang et al. [2] using another
Monte Carlo Simulation. A high performance imple-
mentation of a pattern matcher and a pseudo random
number generator based on a Mersenne Twister had
been implemented as offload functions on a FPGA in
[3]. In the field of embedded systems FPGAs are used
for real-time and stand-alone solutions.
Partially reconfigurable FPGAs offer a new degree
of flexibility. Partially reconfigurable regions (PRR) on
DPR capable FPGAs (e.g. Xilinx Virtex FPGAs) can
be reconfigured during run-time without inference of
the remaining parts, which remain fully functional.
The rest of the paper is organized as follows:
Section 2 focuses on related work covering run-time
reconfiguration. In section 3 the costs of dealing with
arbitrarily placeable RTRMs are discussed in relation
to communication latencies, bandwidth and the number
of configuration bit stream files. Section 4 describes the
configurable fully meshed network supporting RTRMs.
The network architecture, the interface, the protocol,
latencies, the logical and physical implementation are
shown. A case study conducted in section 5 describes
the verification and the run-time environment system
managing run-time reconfiguration and the config-
urable network. Section 6 concludes the results of this
paper.
2. Related Work
Utilizing the feature of run-time reconfiguration im-
poses requirements on the design, the communication
with RTRMs, the design flow, the synthesis tools and
run-time environment system. Different approaches

978-0-7695-3782-5/09 $25.00 © 2009 IEEE 539

DOI 10.1109/DSD.2009.133
have been proposed which make use of the DPR
capability of FPGAs. The design, i.e. hierarchy and in-
terfaces, depend on the synthesis tools and frameworks
used. Most of the tool-flows are built upon the Xilinx
design flow (cf. [5]) and partial synthesis software
for Virtex FPGAs. The design methodology is based
on a point-to-point communication with RTRMs using
hard macros. A tool-flow for more complex structures,
e.g. homogeneous communication infrastructure, was
presented by Hagemeyer et al. [6], which is based
upon the Xilinx design flow. In contrast a tool named
ReCoBus-builder, which is not dependent on the Xilinx
design flow, builds static buses between RTRMs and
was proposed by Koch et al. [7], [8]. Only Virtex-II and
Spartan-3 FPGAs are supported so far. For increasing
throughput and allowing more than one RTRM to
communicate at the same time topologies with routers
have been examined in [9], [10]. Beyond methodolo-
gies of creating a run-time reconfigurable infrastructure
on the FPGA, run-time management systems for the
integration of FPGAs into a host system have been
proposed.
ReconOS [11], a real-time OS with static FPGA
threads, is based on memory mapping and targets
embedded systems. BORPH [12] runs on the embed-
ded PowerPC and communicates through the UNIX
IPC mechanism. For dealing with host coupled ac-
celerators, including FPGAs, a common interface was
designed, built on top of a virtual file system (ACCFS)
supporting run-time reconfiguration for HyperTrans-
port coupled FPGAs (cf. [3]).
3. Communication and Arbitrary Place-
ment of RTRMs
In this section the costs of dealing with arbitrarily
placeable RTRMs on a fixed mesh of PRRs, which
is defined during design time, will be assessed. The
goal is to find a manageable solution for the arbitrary
placement of RTRMs, which on the one hand keeps the
number of partial configuration bit stream files small
and on the other hand provides constant low commu-
nication latencies and multiple communication access
of the RTRMs at the same time. Figure 1.a shows
an example, where RTRMs are logically grouped in
communication domains and Figure 1.b represents a
valid placement of these RTRMs in PRRs on a FPGA.
3.1. Costs of Communication with RTRMs
Different approaches have been proposed. The FPGA
manufacturer Xilinx uses hard macros, also known as
bus macros, even though it provides a single directed
540
1 3
3 4
1 3 4 1 2
4 3
1/2/3/4 4
2 1
1 4
2 4 1
(a) Logical view of RTRMs (b) Actual placement of
in a RTR grid grouped in RTRMs grouped in com-
communication domains munication domains lo-
cated inside a FPGA
Figure 1. Logical and physical placement of
RTRMs in a RTR grid grouped in communication
domains
point to point connection to a RTRM or a static module
and not a bus with more than two participants. The
module based partial design flow with hard macros
is described in [5]. Tri-state buffers, which can be
used in a bus, implemented with AND-OR logic in
Virtex-2 (Pro) FPGAs (cf. [13]) are no longer avail-
able in Virtex-4/-5/-6 FPGAs, presumably because of
high latencies due to long routing delays between the
most distant logic blocks (slices). Another technique
of providing inter module communication, called Re-
CoBus (cf. [7]), connects all peers in a long directed
combinatorial ORed chain with local AND gates to
enable master read operations. Only Virtex-2 (Pro)
and Spartan-3 FPGAs are supported and homogeneous
PRRs are assumed.
All buses have in common that there can be only one
transmitter at the same time. If more than one message
is allowed to travel through the network routers are
used, cf. [9], [10]. Due to the reason that low and
constant latencies are difficult to achieve on routed
topologies and buses suffer from single message trans-
mission, a fully meshed network, where each RTRM
has an extra communication path to each of the other
RTRMs, is considered. If non arbitrary placement of
RTRMs is assumed, the implementation costs of the
communication infrastructure based on FPGA logic
and routing resources for a fully meshed network
consist only of routing resources if communication
paths are unregistered (unbuffered). All interconnect
topologies for communication with RTRMs have in
common that the amount of communication is limited
in bandwidth and latencies could be high compared to
a fully static design.
 RTRM 1 RTRM 2
3.2. Costs of Arbitrary Placement of RTRMs sb_out[5] sb_out[5]
sb_in[5] sb_in[5]

data_out[32] data_out[32]
For the calculation of the amount of configuration bit data_in[32] data_in[32]

stream files needed, we make the following assump- valid_out valid_out

valid_in valid_in
tions: Due to the heterogeneity of the different PRRs wr/rd_out wr/rd_out
it is not possible to copy a configuration bit stream file wr/rd_in wr/rd_in

for a fixed PRR to another PRR. The heterogeneity rq/rp_out rq/rp_out

rq/rp_in rq/rp_in
for example originates in the different amount of
BlockRAMs (BRAMs), multiplexer and orientation of
Figure 2. Application defined interface of com-
module interconnects to the internal network in a PRR.
ports
Each RTRM has a single network port (snp) to access
the communication partners. If n is the amount of
RTRMs we want to place in r PRRs, then n times r
4. Configurable Fully Meshed Network on
(cf. equation 1) configuration bit stream files (csnp ) are
needed for the arbitrary placement of the RTRM and Chip
when the RTRMs are able to access the communication
partners on the same way. 4.1. Network Architecture

To enable arbitrary placement of RTRMs with a fully

csnp (n, r) = n · r (1) meshed network topology a configurable fully meshed
network (cFMN) is needed. This means that the route
For a fully meshed network topology which has of the outgoing and incoming communication of a
multiple network ports (mnp) per RTRM, the ports RTRM to others must be directed (switched) in such
are directly connected point to point and arbitrary a way that no change is needed to the RTRMs i.e. the
placement is provided, the amount of configuration bit configuration bit stream file itself. The network switch
stream files (cmnp ) is shown in equation 2. When n is is automatically configured in a way that the RTRMs
equal to r each permutation of the possible placements always communicate with their defined communication
of RTRMs is needed to ensure that the communication partners independently of their actual placement on
is done to the predefined ports. These are costs in the FPGA (cf. Figure 1.b). A fully meshed network
terms of the amount of configuration bit stream files for allows constant low latencies for most communication
the arbitrary RTRM placement without a configurable patterns, e.g. single transaction (unicast), multicast and
fully meshed network, i.e. directly connected point to all-to-all communication. The bandwidth is directly
point routed. It should be noted that such a solution proportional to the number of signals within a com-
is not feasible, e.g. for n = r = 16 the amount of munication channel.
configuration files are 16! (≈ 21 trillions).
4.2. Interface and Protocol


 n! n=r The interface and the protocol should be as universal

as possible to allow common standard protocols to be


  
r

used. Therefore only the width of a communication

n! · n<r

cmnp (n, r) = n (2) port which is connected to a communication channel

is set at a fixed size defined for the architecture. We


  
n

propose a width of 40 bit for Virtex-5 FPGAs, which

 r! · n>r


r allows to transfer 32 bit at one clock cycle and leaves
enough signals left for control, status signals and side
If we supply the fully meshed network with band signals (sb). Figure 2 depicts a typical interface
outgoing and incoming switches on each RTRM port defined by an application module (e.g. RTRM) and the
we can adjust the route during run-time when a new connection to another module. The speed of a clocked
RTRM is added or replaced. This leads to the massive transmission can be chosen potentially different for
reduction of configuration bit stream files from the each communication channel. In this paper we assume
one stated in equation 2 to the one in equation 1. an overall synchronous clock for driving the commu-
nication channels.

541
 Network 1 operating modes
com−port S reg S reg R com−port R

S1 S2 1 non registered
clk
A.1 D 2 registered at sender side
Figure 3. Schematic view of the communication of 2 3 registered at receiver side
two RTRMs through the communication channel 4 registered at both sides
A.2 B D
A.1 sender transmit
3

4.3. Adjustable Latencies A.2 sender transmit to sender reg

A.3 C D A.3 sender transmit to receiver reg

To allow asynchronous (unregistered) as well as syn- 4 B in internal sender reg

chronous (registered) data transfer through the com- C in internal receiver reg

munication channel the operation mode can be chosen A.2 B C D

on demand during runtime. On both sides, i.e. sender
and receiver, the use of a register where the data is
buffered can be selected, cf. Figure 3 for a schematic
view of the communication channel. The four different
modes of selecting respectively deselecting the register
on the sender and receiver side are depicted in Figure 4.
When the registered path is selected on the sender side
the data is clocked into the register at the first clock
cycle and clocked to the communication partner in the
second. The asynchronous mode (unregistered) is most
suitable for a path which originates inside a RTRM
M1 at a register, runs through combinatorial logic,
reaches the communication port, travels through the
communication channel, presumably to another stage
of combinatorial logic at the receiver side at RTRM
M2 targeting a register and this all within one clock
cycle. It should be noted that this mode of operation
requires special attention by the synthesis software to
ensure that the signal reaches the destination in time
for RTR support. The earliest setup time tsetup is
predetermined by the logic at the receiving RTRM and
the latest hold time thold is defined by the sending
RTRM. The time ∆tn is subtracted from tsetup as
worst case network latency through the communication
channel and the remaining time ∆tm should be divided
and assigned equally to both RTRMs (cf. Figure 5).
Registered communication leverages the constraints for
the place and route FPGA software and is most suitable
to achieve higher clock cycle frequencies.
4.4. Physical Implementation
To allow arbitrary placement of RTRMs in a fully
meshed network under the conditions stated in equa-
tion 1, the network needs the property to assign out-
going communication ports of a RTRM at run-time,
whose amount is the number of P RRs − 1 (= r − 1)
at the maximum for each RTRM, to a desired incoming
communication port of another RTRM without inter-
fering the other selected communication paths of the
network. To achieve such a behavior two switches are
D available for receiver
Figure 4. Communication through com-ports de-
pendent on the operating mode
t hold t setup
clk
tm tn
1
2 tm 1
2 tm
tm tm
1 2
Figure 5. Asynchronous path from one RTRM to
another through the network
used per RTRM respectively per PRR. The first one
used for all outgoing communication is able to choose
the communication partner (i.e. distant RTRM) at a
communication port of the sending RTRM defined by
the RTRM itself. The second one routes the incoming
data from a distant RTRM to a local communication
port, which is defined by the receiving RTRM. Figure 6
shows the schematic view of a configurable, fully
meshed network for four RTRMs. The interconnection
between the switches is chosen in such a way that the
configuration (config) for the switches can be easily
determined for a specific route. For each outgoing
port on the network side (i.e. behind a switch for
sending), one of the RTRM’s sending ports can be
selected. The same applies to the receiving switch but
here the configuration is done in the way that the
communication port of a RTRM can decide which
network connection from a distant RTRM should be
used. If for both, the sending and the receiving port,
equal port numbers are taken, i.e. that data is sent on
port p of the sending ports of RTRM M1 to RTRM
M2 and data is received also on the incoming port p of
the receiving ports of M1 , an easy transformation from
the configuration setting of the sending to the receiving
switch is possible. Different clock speeds of communi-
cation ports are possible but not discussed further here.

542
 com−port 1 reg reg com−port 1

com−port 2 reg reg com−port 2

com−port 3 reg reg com−port 3

clk config config clk

RTRM 1 RTRM 2
com−port 1 reg reg com−port 1

com−port 2 reg reg com−port 2

com−port 3 reg reg com−port 3

clk config config clk

com−port 1 reg reg com−port 1

com−port 2 reg reg com−port 2

com−port 3 reg reg com−port 3

clk config config clk

RTRM 3 RTRM 4
com−port 1 reg reg com−port 1

com−port 2 reg reg com−port 2

com−port 3 reg reg com−port 3

clk config config clk

Figure 6. Schematic view of a configurable, fully meshed network for 4 RTRMs

For the physical silicon implementation of all switches,
sending and receiving, 2 · r · (r − 1) · w multiplexers
of (r-1)-to-1 can be utilized, where r is the maximal
amount of RTRMs which can be placed on the FPGA
at the same time and w the width of a single communi-
cation port. The amount of transistors can be reduced
further if tristate buffers are utilized. This is possible
because the transmission is only unidirectional, point
to point and can be terminated at the receiver side. The
buffers are neither load dependent nor depend on the
length of the transmission line, which should be made
equal for all communication channels, independently
of the physical location to ease the timing analysis
during the place and route process of a customer
design using RTRM designs. The number of tristate
buffers for a configurable fully meshed network with
r PRRs/RTRMs is 2·r·(r−1)2 ·w. For a schematic view
of an outgoing and incoming switch implemented with
tristate buffers confer Figure 7. The implementation of
a fully meshed silicon network for 16 to 24 RTRMs is
feasible with 40 bit port width, if we compare this
to the number of transistors used for Virtex-5 (1.1
billion) and Altera Stratix IV (2.5 billion) FPGAs. An
implementation with 16 (24) RTRMs by 40 bit width
(with registers for buffers and config for switches)
using tristate buffers takes about 1.4‰ (4.4‰) of the
Virtex-5 FPGA transistors or about 2.4‰ (8.1‰) for
the multiplexer solution. Table 1 shows the amount
of transistors needed for the silicon implementation
of a configurable, fully meshed network on chip for
different sizes of RTR grids with 40 bit communication
port width. The consumption of transistors used for
the switches and D-Flip-Flops (D-FF) for buffers and
config registers are listed in detail. The fully meshed
network is a silicon hard block and exposed to a
RTRM through communication channel hard blocks
(primitives), one for each communication partner. The
location of the hard blocks of the communication ports
must be within a PRR respectively clock region of a
FPGA. The sending and receiving ports can be equally
distributed over the PRR (cf. Figure 8.a) or placed near
the center of the FPGA (cf. Figure 8.b), which is the
preferred variant to allow additional RTRMs working
at a slower speed behind a master RTRM. Building
larger PRRs allows channel combining to double the
bandwidth (cf. Figure 9.a and Figure 9.b for 8 RTRMs
with 16 communication channels). The silicon solution
provides a high speed, i.e. low jitter, low latency path,
compared to a FPGA routed fully meshed network
design which needs up to 10 ns (cf. [14]) to reach
the most distinct RTRMs.
4.5. HDL Design
RTRMs which want to utilize the configurable, fully
meshed network have to instantiate the communication
channel primitive COM CHANNEL for each con-
nection to a distant RTRM (cf. Figure 10) in HDL
(e.g. Verilog or VHDL). This is comparable with the
instantiation of a BlockRAM (BRAM) or multiplier

543
 com−port 1 reg R S S R R S S R

com−port 2 reg

com−port 3 reg

clk config
RTRM 1

com−port 1 reg

com−port 2 reg

com−port 3 reg

clk
(a) Location of hard blocks (b) Location of hard blocks
config
equally distributed inside a near the center of the FPGA
PRR
Figure 7. Tristate buffer solution for the sending
Figure 8. Location of com-ports as hard blocks for
and receiving switch in a RTR grid with a cFMN
a RTR grid with 16 PRRs/RTRMs
#PRRs
cFMN (40 bit/port) 2 4 8 16 24
R S S R R S S R
#transistors for
tristate sol. (mil.) 0.00 0.01 0.13 1.15 4.06
#transistors for
multiplexer sol. (mil.) 0.00 0.02 0.25 2.30 8.13
#transistors for
regs (D-FF) (mil.) 0.00 0.02 0.07 0.31 0.71
#transistors for
config (D-FF) 0 768 5376 30T 88T
P
transistors for
tristate sol. (mil.) 0.00 0.03 0.20 1.49 4.86
P
transistors for
muxer sol. (mil.) 0.00 0.04 0.33 2.64 8.92
Virtex-5 transistors
tristate util. (%) 0.00 0.00 0.01 0.14 0.44
(a) Location of hard blocks (b) Location of hard blocks
Virtex-5 transistors
equally distributed inside a near the center of the FPGA
muxer util. (%) 0.00 0.00 0.03 0.24 0.81
PRR
Table 1. Resource utilization for RTR grids with
Figure 9. Location of com-ports as hard block for
different amount of PRRs using a NoC - both with
a RTR grid with 8 PRRs/RTRMs
40 bit / com-port

done on the largest Virtex-5 FPGA XC5VLX330.

(DSP Slice). The COM CHANNELs are hard blocks
located inside a PRR respectively a clock region on
a FPGA. Designs where the hard block is located
near (not inside) a PRRs are also possible but not
recommended due to likely higher routing delays. The
synthesis tool (placer) decides which physical hard
block is to select for the actual PRR.
5. Case Study
5.1. Proof of Concept
To get an assessment what device utilization is needed
for a configurable, fully meshed network with 16
PRRs (RTRMs) and 40 bit port width built on con-
figurable logic blocks (CLB), an implementation was
The utilization respectively the count of transistors
should then be compared with a dedicated silicon
NoC solution. The utilization is about 40% for the
configurable, fully meshed network only and about
7% for the RTRMs themselves for FSMs. Figure 11.a
shows a placed design with PRRs located at adjacent
regions, which could not be routed. Confer Figure 11.b
for a routed design, where the PRRs are distributed
over the FPGA. The utilization of about 40% for the
configurable, fully meshed network corresponds to the
theoretical minimal resource utilization of 38% shown
in Table 2. The theoretical resource utilization for
24 PRRs using FPGA resources is 152% minimum
(cf. Table 2). Figure 12 presents the comparison of
transistors needed for a configurable, fully meshed
network for different RTR grid sizes implemented with

544
 c o m c h a n n e l i n s t : COM CHANNEL
g e n e r i c map (
CHANNEL NUMBER => n u m b e r p e r m o d u l e ;
p o r t map (
d a t a s e n d => r t r m c o m d a t a o u t ;
d a t a r e c e i v e => r t r m c o m d a t a i n ;
c o n f i g => c o n f i g ;
c l k => c l k ;
};

Figure 10. Instantiation of a communication chan-

nel primitive
#PRRs
cFMN (40 bit/port) 2 4 8 16 24
#slices for
cFMN muxers 0 240 2240 19200 77280
#slices for (a) Non-routable design (b) Routed design
cFMN registers 40 240 1120 4800 11040
#slices for Figure 11. RTR grid with 16 RTRMs and fully
cFMN config regs 0 12 84 480 1380
P meshed network (40 bit / com-port) implemented
slices for
cFMN 40 252 2324 19680 78660 with FPGA resources on a XC5VLX330
P
transistors for
cFMN (mil.) 0.8 5.3 49.3 417.6 1669.1
Virtex-5 transistors
utilization (%) 0.1 0.5 4.5 38.0 151.7 FPGA resources
10000 muxer
Table 2. Minimal resource utilization for RTR grids tristate
1000
with different amount of PRRs implemenated with
#transistors (mil)

FPGA resources at 40 bit / com-port 100

10

0.1
configurable logic on a FPGA and a dedicated silicon
network on chip solution. Due to the long synthe- 0.01

sis runs a smaller configuration with 8 PRRs and a 0.001

smaller FPGA (XC5VLX50T) was chosen to verify the
port interface definition, communication protocols, the
multi-port HDL design and simultaneous transmissions
(particularly all-to-all communication).
5.2. Run-Time Environment System
A FPGA application is called a process at run-time,
which consists at least of one RTRM. A process can
create new threads (RTRMs) within its own process.
All threads within a process belong to the same com-
munication domain. RTRMs within the same commu-
nication domain can build a fully meshed sub network
for all threads.
The task of the run-time environment system is to
load the configuration data of a RTRM, to partially
reconfigure the PRR and to adjust the routing of the
communication channels as intended by the applica-
tion. The run-time environment system can pursue dif-
ferent strategies dependent on the field of application.
Three different fields have been determined, i.e. a
run-time reconfigurable FPGA accelerator in a host
system, a real-time system and an embedded system.
2 4 8 16 24
#PRRs
Figure 12. Resource utilization in transistor count
for cFMN with FPGA resources and cFMN with
NoC (multiplexer and tristate) - both with 40 bit /
com-port
Different requirements need to be satisfied for each
type. In an accelerator environment for offloading com-
pute kernels a multi-user, multi-process functionality
is desirable. The number of threads within a process
is most likely fixed. The run-time environment system
for accelerators is throughput respectively performance
driven. In contrast a run-time environment system for
real-time applications is event driven, has to abide to
deadlines and should allow dynamic thread (RTRMs)
creation. For embedded systems the run-time environ-
ment system is generally demand driven. Additional
functionality is loaded on demand to exchange or
enhance functionality. In a verification process for the
overall concepts a run-time environment system was

545
tested on a host system in conjunction with a Xilinx
XC5VLX50T FPGA PCI Express card.
6. Conclusion
In this paper a solution has been presented for the
arbitrary placement of RTRMs in a RTR grid on DPR
capable FPGAs based on a dedicated silicon commu-
nication network. The implementation, configuration
and utilization of the dedicated, silicon, configurable,
fully meshed network was shown. The silicon network
provides a high speed, i.e. low jitter, low latency, so-
lution and consumes only a tiny amount of transistors
compared to an implementation with FPGA resources.
The communication infrastructure allows different
applications built on RTRMs to coexist and commu-
nicate without interference compared to other known
bus or routed network solutions for FPGAs.
The communication channels are customizable to
the requirements of the application, which is able to
run self-defined protocols over the channels. For real-
time applications the communication channels provide
a constant and low latency. Additionally the run-time
environment system for managing such a network has
been presented for different fields of applications.
7. Future Work
In this paper we have concentrated on a network design
with only one network clock frequency for all modules.
Communication channels working at different clock
speeds seem to be promising.
8. Acknowledgment
The project is performed in collaboration with the Cen-
ter of Advanced Study Böblingen, IBM Deutschland
Research & Development GmbH in Germany.
References
[1] N. A. Woods and T. VanCourt, “FPGA Acceleration of
Quasi-Monte Carlo in Finance,” in FPL. IEEE, 2008,
pp. 335–340.
[2] G. L. Zhang, P. H. W. Leong, C. H. Ho, K. H. Tsoi,
C. C. C. Cheung, D.-U. Lee, R. C. C. Cheung, and
W. Luk, “Reconfigurable Acceleration for Monte Carlo
Based Financial Simulation,” in FPT, G. J. Brebner,
S. Chakraborty, and W.-F. Wong, Eds. IEEE, 2005,
pp. 215–222.
[3] J. Strunk, A. Heinig, T. Volkmer, W. Rehm, and
H. Schick, “Run-Time Reconfiguration for Hypertrans-
port coupled FPGAs using ACCFS,” in proceedings
of the Workshop on HyperTransport Research and
Applications (WHTRA), 2009.
546
[4] P. Chen and A. Ye, “The effect of sparse switch
patterns on the area efficiency of multi-bit routing
resources in field-programmable gate arrays,” in Field
Programmable Logic and Applications, 2008. FPL
2008. International Conference on, Sept. 2008, pp.
427–430.
[5] Xilinx, “Two flows for partial reconfiguration: Module
based or difference based,” in Application Note: Virtex,
Virtex-E, Virtex-II, Virtex-II Pro Families (XAPP290),
2004.
[6] J. Hagemeyer, B. Kettelhoit, M. Koester, and M. Por-
rmann, in Design of Homogeneous Communication
Infrastructures for Partially Reconfigurable FPGAs
(ERSA). CSREA Press, 2007.
[7] D. Koch, C. Beckhoff, and J. Teich, “ReCoBus-Builder
a Novel Tool and Technique to Build Statically and
Dynamically Reconfigurable Systems for FPGAs,” in
Proceedings of International Conference on Field-
Programmable Logic and Applications (FPL 08), Hei-
delberg, Germany, 2008.
[8] D. Koch, C. Beckhoff, and J. Teich, “A Communi-
cation Architecture for Complex Runtime Reconfig-
urable Systems and its Implementation on Spartan-
3 FPGAs,” in Proceedings of the 17th ACM/SIGDA
International Symposium on Field-Programmable Gate
Arrays (FPGA 2009). Monterey, California, USA:
ACM, Feb. 2009, pp. 233–236.
[9] J. Surisi, C. Patterson, and P. Athanas, “An efficient
run-time router for connecting modules in FPGAs,”
in Proceedings of International Conference on Field-
Programmable Logic and Applications (FPL 08), Hei-
delberg, Germany, 2008.
[10] T. Pionteck, C. Albrecht, K. Maehle, E., Hübner, M.,
and Becker, J., “Commuication Architectures for Dy-
namically Reconfigurable FPGA Designs,” in Proceed-
ings of IEEE International Parallel and Distributed
Processing Symposium, IPDPS USA, 2007.
[11] E. Lubbers and M. Planner, “ReconOS: An RTOS
Supporting Hard-and Software Threads,” Field Pro-
grammable Logic and Applications, 2007. FPL 2007.
International Conference on, pp. 441–446, Aug. 2007.
[12] H. K.-H. So and R. Bordersen, “File System Access
From Reconfigurable FPGA Hardware Processes In
BORPH,” in Proceedings of the 2008 IEEE Interna-
tional Conference on Field-Programmable Logic, FPL
2008, 8-10 September, Heidelberg. IEEE, 2008.
[13] “Virtex-II Platform FPGAs: Complete Data Sheet,”
Xilinx DS031, vol. 3.5, p. 20, 2007.
[14] J. Strunk, T. Volkmer, K. Stephan, W. Rehm, and
H. Schick, “Impact on Run-Time Reconfiguration on
Design and Speed - A Case Study Based on a Grid of
Run-Time Reconfigurable Modules inside a FPGA,” in
proceedings of the Reconfigurable Architectures Work-
shop (RAW) / IPDPS, 2009.