19-06-2012, 02:28 PM
Challenges of Multi-FPGA Development
[attachment=24805]
I. INTRODUCTION
Conventionally, FPGAs have been used within embedded
systems to provide function acceleration without the need for
costly ASIC development. FPGA capacities have increased to
enable general architectures (including softcore and embedded
CPUs) to be implemented on the device; together with large
complex accelerators. As the capacities (and performance)
of FPGAs has increased, their use in domains other than
embedded systems has been proposed, including general and
scientific computing.
The use of FPGAs poses significant challenges, not least
in terms of the time required to place and route a design.
As FPGA capacity sizes increase, the inherent computational
complexity of the bin-packing problem dictates exponential
rises in place and route times that have been largely countered
by corresponding increased speeds of workstation speeds (and
memory sizes); together with vendor support for modular place
and route of components of the design (eg. Xilinx PlanAhead).
However, for general and scientific computing it is clear
that the development methods, languages and tools refined
largely to address the specific needs of utilising FPGAs as
co-processors within embedded systems, are not necessarily
appropriate. Such systems could contain a large number of
FPGAs may exist within a system, eg. the SGI supercomputer
built from multiple SGI RC200 blades, each with Xeon CPUs
and FPGAs; the Maxwell with 64 interconnected FPGAs.
Currently, we are investigating the problems of programming
Multi-FPGA architectures from two viewpoints:
Architecture – trade-offs between static architectures (ie.
CPU softcores – application independent) and application
specific architectures (ie. conventional application specific
co-processors). The former offers less performance,
but the latter need to be place and routed whenever the
source program changes.
Language – domain appropriate languages and abstractions
for general and scientific computing on FPGAs; the
trade-off between mapping a single application program
across all FPGAs, and having individual programs for
each FPGA.
In terms of programming, we are building on our previous
work mapping Ada [1], SR [2] and Java methods [3] to FPGA.
Currently we are extending Java to include the abstractions
of scientific programming languages such as OpenCL and
OpenMP. This will result in a language that is accessible
to general programmers and that can exploit the potential
Fig. 1. Quad FPGA Board
of FPGA platforms. Likewise, this will enable the scientific
computation community to utilise multi-FPGAs via a common
language extended appropriately for their domain.
II. YORK QUAD FPGA BOARD
The current Multi-FPGA rig at York includes 8 quad-FPGA
boards (a single board is shown in Figure 1), each board with
the following capability:
4 x Xilinx Spartan XC3S4000
Static SSRAM: 4M x 32bits per FPGA
DDR SDRAM: 512MB per FPGA
100Mbit Ethernet PHY per FPGA
Xilinx Virtex4 FX12 module
Communication between FPGAs is twofold. Between each
pair of FPGAs are on board dedicated communication lines
that can be configured according to application need. Each
FPGA contains hard ethernet MAC endpoints, one of which
is linked to a ethernet PHY chip and J45 header. All FPGAs
within the rig are connected to a switch, giving point to point
ethernet links between any pair of FPGAs in the rig. The FX12
module is used to download bitfiles to individual FPGAs.
The FX12 is connected to the development platform via an
ethernet switch; each FPGA on the quad board is individually
connected to the FX12 board via JTAG.
To place and route individual designs, and to generate
bitfiles, the Xilinx ISE toolset is used.
[attachment=24805]
I. INTRODUCTION
Conventionally, FPGAs have been used within embedded
systems to provide function acceleration without the need for
costly ASIC development. FPGA capacities have increased to
enable general architectures (including softcore and embedded
CPUs) to be implemented on the device; together with large
complex accelerators. As the capacities (and performance)
of FPGAs has increased, their use in domains other than
embedded systems has been proposed, including general and
scientific computing.
The use of FPGAs poses significant challenges, not least
in terms of the time required to place and route a design.
As FPGA capacity sizes increase, the inherent computational
complexity of the bin-packing problem dictates exponential
rises in place and route times that have been largely countered
by corresponding increased speeds of workstation speeds (and
memory sizes); together with vendor support for modular place
and route of components of the design (eg. Xilinx PlanAhead).
However, for general and scientific computing it is clear
that the development methods, languages and tools refined
largely to address the specific needs of utilising FPGAs as
co-processors within embedded systems, are not necessarily
appropriate. Such systems could contain a large number of
FPGAs may exist within a system, eg. the SGI supercomputer
built from multiple SGI RC200 blades, each with Xeon CPUs
and FPGAs; the Maxwell with 64 interconnected FPGAs.
Currently, we are investigating the problems of programming
Multi-FPGA architectures from two viewpoints:
Architecture – trade-offs between static architectures (ie.
CPU softcores – application independent) and application
specific architectures (ie. conventional application specific
co-processors). The former offers less performance,
but the latter need to be place and routed whenever the
source program changes.
Language – domain appropriate languages and abstractions
for general and scientific computing on FPGAs; the
trade-off between mapping a single application program
across all FPGAs, and having individual programs for
each FPGA.
In terms of programming, we are building on our previous
work mapping Ada [1], SR [2] and Java methods [3] to FPGA.
Currently we are extending Java to include the abstractions
of scientific programming languages such as OpenCL and
OpenMP. This will result in a language that is accessible
to general programmers and that can exploit the potential
Fig. 1. Quad FPGA Board
of FPGA platforms. Likewise, this will enable the scientific
computation community to utilise multi-FPGAs via a common
language extended appropriately for their domain.
II. YORK QUAD FPGA BOARD
The current Multi-FPGA rig at York includes 8 quad-FPGA
boards (a single board is shown in Figure 1), each board with
the following capability:
4 x Xilinx Spartan XC3S4000
Static SSRAM: 4M x 32bits per FPGA
DDR SDRAM: 512MB per FPGA
100Mbit Ethernet PHY per FPGA
Xilinx Virtex4 FX12 module
Communication between FPGAs is twofold. Between each
pair of FPGAs are on board dedicated communication lines
that can be configured according to application need. Each
FPGA contains hard ethernet MAC endpoints, one of which
is linked to a ethernet PHY chip and J45 header. All FPGAs
within the rig are connected to a switch, giving point to point
ethernet links between any pair of FPGAs in the rig. The FX12
module is used to download bitfiles to individual FPGAs.
The FX12 is connected to the development platform via an
ethernet switch; each FPGA on the quad board is individually
connected to the FX12 board via JTAG.
To place and route individual designs, and to generate
bitfiles, the Xilinx ISE toolset is used.