07-07-2012, 11:23 AM
An overview of FPGAs and FPGA programming; Initial experiences at Daresbury
[attachment=27060]
Introduction
FPGAs and HPC
A Field-Programmable Gate Array or FPGA is a silicon chip containing an array of configurable logic
blocks (CLBs). Unlike an Application Specific Integrated Circuit (ASIC) which can perform a single
specific function for the lifetime of the chip an FPGA can be reprogrammed to perform a different
function in a matter of microseconds. Before it is programmed an FPGA knows nothing about how to
communicate with the devices surrounding it. This is both a blessing and a curse as it allows a great
deal of flexibility in using the FPGA while greatly increasing the complexity of programming it. The
ability to reprogram FPGAs has led them to be widely used by hardware designers for prototyping
circuits. Over the last two to three years FPGAs have begun to contain enough resources (logic
cells/IO) to make them of interest to the HPC community. Recently HPC hardware vendors have
begun to offer solutions that incorporate FPGAs into HPC systems where they can act as co-processors,
so accelerating key kernels within an application. Cray were one of the first companies to produce
such a system with the XD1, a system originally designed by OctigaBay [1].
FPGA Performance
While the headline performance increase offered by FPGAs is often very large (>100 times for some
algorithms) it is important to consider a number of factors when assessing their usefulness for
accelerating a particular application. Firstly, is it practical to implement the whole application on an
FPGA? The answer to this is likely to be no, particularly for floating-point intensive applications
which tend to swallow up a large amount of logic. If it is either impractical or impossible to implement
the whole application on an FPGA, the next best option is to implement those kernels within the
application that are responsible for the majority of the run-time, which may be determined by
profiling. Next, the real speedup of the whole application must be estimated once the kernel has been
implemented in a FPGA. Even if that kernel was originally responsible for 90% of the runtime the
total speed-up that you can achieve for your application cannot exceed 10 times (even if you achieve a
1000 times speed up for the kernel), an example of Amdahl’s law [12], that long time irritant of the
HPC software engineer. Once such an estimate has been made, one must decide if the potential gain is
worthwhile given the complexity of instantiating the algorithm on an FPGA.
Programming an FPGA
Although FPGA technology has been around in some form for many years it is only in the last two to
three years that the technology has begun to make any inroads into the HPC market. In the past the
vast majority of FPGA users would have been hardware designers with a significant amount of
knowledge and experience in circuit design using traditional Hardware Description Languages (HDL)
like VHDL or Verilog. These languages and many of the concepts that underpin their use are
unfamiliar to the vast majority of software programmers. In order to open up the FPGA market to
software programmers, tools vendors are providing an increasing number of somewhat C-like FPGA
programming languages and supporting tools. These pseudo-C languages all provide a more familiar
development flow that, in many cases, may provide a significant level of abstraction away from the
underlying hardware. A number of traditional hardware design languages/tools and pseudo-c
languages/tools are covered in greater depth later in this report.
HPC Software Practice
Despite the above comments, to the experienced HPC software engineer the design flow of the two
paradigms does not seem to be fundamentally dissimilar. Though for hardware there are appreciably
more steps, in general this is more often due to having to explicitly perform steps that are nowadays
redundant or hidden in the software case. After all it is not so long ago that one of the authors was
debugging software on a simulator!
[attachment=27060]
Introduction
FPGAs and HPC
A Field-Programmable Gate Array or FPGA is a silicon chip containing an array of configurable logic
blocks (CLBs). Unlike an Application Specific Integrated Circuit (ASIC) which can perform a single
specific function for the lifetime of the chip an FPGA can be reprogrammed to perform a different
function in a matter of microseconds. Before it is programmed an FPGA knows nothing about how to
communicate with the devices surrounding it. This is both a blessing and a curse as it allows a great
deal of flexibility in using the FPGA while greatly increasing the complexity of programming it. The
ability to reprogram FPGAs has led them to be widely used by hardware designers for prototyping
circuits. Over the last two to three years FPGAs have begun to contain enough resources (logic
cells/IO) to make them of interest to the HPC community. Recently HPC hardware vendors have
begun to offer solutions that incorporate FPGAs into HPC systems where they can act as co-processors,
so accelerating key kernels within an application. Cray were one of the first companies to produce
such a system with the XD1, a system originally designed by OctigaBay [1].
FPGA Performance
While the headline performance increase offered by FPGAs is often very large (>100 times for some
algorithms) it is important to consider a number of factors when assessing their usefulness for
accelerating a particular application. Firstly, is it practical to implement the whole application on an
FPGA? The answer to this is likely to be no, particularly for floating-point intensive applications
which tend to swallow up a large amount of logic. If it is either impractical or impossible to implement
the whole application on an FPGA, the next best option is to implement those kernels within the
application that are responsible for the majority of the run-time, which may be determined by
profiling. Next, the real speedup of the whole application must be estimated once the kernel has been
implemented in a FPGA. Even if that kernel was originally responsible for 90% of the runtime the
total speed-up that you can achieve for your application cannot exceed 10 times (even if you achieve a
1000 times speed up for the kernel), an example of Amdahl’s law [12], that long time irritant of the
HPC software engineer. Once such an estimate has been made, one must decide if the potential gain is
worthwhile given the complexity of instantiating the algorithm on an FPGA.
Programming an FPGA
Although FPGA technology has been around in some form for many years it is only in the last two to
three years that the technology has begun to make any inroads into the HPC market. In the past the
vast majority of FPGA users would have been hardware designers with a significant amount of
knowledge and experience in circuit design using traditional Hardware Description Languages (HDL)
like VHDL or Verilog. These languages and many of the concepts that underpin their use are
unfamiliar to the vast majority of software programmers. In order to open up the FPGA market to
software programmers, tools vendors are providing an increasing number of somewhat C-like FPGA
programming languages and supporting tools. These pseudo-C languages all provide a more familiar
development flow that, in many cases, may provide a significant level of abstraction away from the
underlying hardware. A number of traditional hardware design languages/tools and pseudo-c
languages/tools are covered in greater depth later in this report.
HPC Software Practice
Despite the above comments, to the experienced HPC software engineer the design flow of the two
paradigms does not seem to be fundamentally dissimilar. Though for hardware there are appreciably
more steps, in general this is more often due to having to explicitly perform steps that are nowadays
redundant or hidden in the software case. After all it is not so long ago that one of the authors was
debugging software on a simulator!