It discusses Vforce (VSIPL++ FOr Reconfigurable Computing). Vforce is designed to allow the same application code to run on different reconfigurable computing platforms, and to permit the runtime binding of applications to hardware. The authors believe that application-level code needs to be separated from platform-specific code, so that no hardware-specific code is required in the application code. Vforce is based on VSIPL++, the Vector, Signal and Image Processing Library, which provides an object-oriented library of commonly used signal and image processing algorithms via a C++ API. VSIPL++ is a standard API designed to provide application-level portability between microprocessor-based platforms. The diagram below shows the abstraction layers of Vforce.

Under the VSIPL++ layer, we can see the software stack that supports the VSIPL++ software API. Some implementations are built on an ANSI C VSIPL implementation, which is in turn built on an implementation of the standard C library libc (and other standard libraries). In this case the libc implementation seems to be optimised for the PowerPC architecture. VSIPL++ may also sit atop libraries such as Mercury’s Scientific Algorithm Library (SAL). Vforce is above the VSIPL++ stack, but it also leverages a separate special purpose processor (SPP) stack. An SPP in this case is an FPGA, though it could be taken to mean any exotic processing technology. The FPGA-oriented SPP stack would normally consist of the RC platform vendor’s own API for accessing the hardware. To achieve their goal of portability and runtime binding, the authors have further divided up the SPP stack as shown below:

Depending on the availability of hardware, Vforce implemented functions may either run in software (as Vforce or as VSIPL++ functions) or in hardware. For hardware implementations, the authors have implemented an Internal Programming Interface (IPI), hidden from the end user. This allows them to use a single standard interface that is translated to the underlying vendor APIs for different RC hardware. The application code is portable because it only contains calls to a generic hardware object. The dynamically linked shared object library (DLSO) holds platform-specific API code. Hardware implementations of functions are provided in a processing kernel library for each hardware platform. The RTRM is the run time resource manager, and it hides hardware-specific information, manages hardware resources and binds application tasks to physical hardware. The RTRM also arbitrates when multiple Vforce applications run in parallel.

Users are likely to wish to accelerate functions at a coarser level than the single VSIPL++ function level, to avoid the repeated initialisation and data transfer costs that come with the chaining of calls to VSIPL++ functions.

A nice feature is that Vforce processing objects catch exceptions coming from the hardware and invoke the software version, so that application code doesn’t need to catch hardware errors.

To add support for more platforms, developers need an RTRM that will run on their RC’s operating system (there are POSIX and MCOE versions at present). They will also need a new hardware DLSO for ther API that communicates with the FPGA-based element of the platform. A library of kernel bitstreams must also be produced for that specific platform.

The authors acknowledge two limitations of Vforce. One is that the overhead of Vforce adds to the computation time. However this overhead is neglible in comparison to a bitstream load, and Vforce can in many cases avoid unnecessary bitstream loads. The second limitation is the reliance on a pre-built library of hardware implementations and processing objects.

In the paper are two example applications. One is a 1D FFT implemented on a Cray XD1. The other is an adaptive beamforming application implemented on a Mercury 6U VME system.

The FFT implementation was limited by data transfer times and communication latencies, and did not outperform the software (for both the native Cray API and Vforce).  The results indicated that Vforce adds very little overhead compared to the native API, while providing ease of programming.

The beamforming application, where computation was partitioned between the host microprocessor and the FPGA compute node showed speedup of between 2× and 200×, depending on the configurations of the application. Hardware processing time was again dominated by data transfer.

The authors stated they were implementing the same beamforming application on the Cray XD1 to illustrate portability. The authors also intend to tackle a wider range of RC platforms and applications, and to port existing VSIPL++ applications to Vforce.

The authors advocate managing the co-operation of software and hardware in reconfigurable computers by having asynchronous software and hardware threads that interact as peers, with shared global memory. POSIX threads (pthreads) are the basis for their work, to which they have hardware threads and named the result hthreads. The authors are looking to take operating systems and middleware layer abstraction across the CPU/FPGA boundary and into the FPGA itself. Hardware threads can be created either by hand in HDL, or via the authors own C-to-VHDL tool. In this paper of January 2008, the system has been implemented on Virtex-II Pro FPGAs. At present the software threads are implemented on the PowerPC core that is on the V-II Pro die, so the entire system is on a single chip (off-chip memories notwithstanding). Future incarnations will accomodate multiple cores, and soft cores such as Microblaze for software threads. The diagram below shows an example of how the system operates in practice.

The PowerPC core is configured for the processor local bus (PLB) , and all the hthread cores and hardware threads are on the on-chip peripheral bus (OPB).

From the introduction comes this section:

[Current RC design approaches] treat the FPGA as a coprocessor on which low-level instruction- and data-level parallelism can be mapped as an extension of the execution stream running on the CPU. These approaches are concerning for the reconfigurable computing community, as lessons learned from historical parallel processing efforts clearly indicate the need to provide portable parallel programming models composed of unaltered high-level languages, operating systems, and middleware libraries]

Anyway, on to some interesting things I picked out from the paper:

The main point made is that FPGAs have more of an advantage at implementing floating-point calculations over microprocessors than comparisons of + & × performance at single and double precision would suggest. We need to ask how best to use FPGAs for the implementation of floating-point algorithms. FPGAs may have significant advantages over microprocessors in implementing algorithms that require less or more precision than is provided by microprocessors. The authors discuss an inductivity calculation as an example application. It consists in computing the inductance of a set of coils used for the magnetic stimulation of the nervous system.They work through how one would approach the implementation of this algorithm, aiming to pipeline as much of it as possible. They advocate thinking about the precision that is necessary to the end user. In this case only a few digits of final precision are required. One needs knowledge of an algorithm’s end precision requirements, and awareness of a number of techniques and rules of thumb for managing precision within an algorithm’s calculations. With this knowledge you can get the same or better precision as you would get with double-precision implementations, but with lower area and latency costs.

The authors describe floating-point accumulators that are built primarily from wide fixed-point additions that occur within a single clock cycle (in the case of the smaller sized accumulators). It makes the implementation of pipelined accumulate units less costly in terms of latency and area. Furthermore, it promises greater precision than is currently possible using standard floating-point addition units.

The authors discuss the advantages of merging operators to create compound operators such as:

The best area and performance results obviously come when the internal precision and general architecture of the compound operator is custom designed. Less obvious was what happened if one naively instantiated the operators +,√ and × in HDL creating a single operator and presenting everything to the synthesiser in HDL (not in pre-synthesised netlists such as NGCs or EDIFs). It turns out the logic synthesiser is smart enough to signficantly improve the resource consumption.

Some other interesting points made by the authors:

• They find it unlikely that we will soon be able to fully automate floating-to-fixed point conversions when implementing algorithms on FPGAs.
• They briefly discuss a method for obtaining exact results for dot-product, and related matrix and vector operations. They invite suggestions of applications that require such precision
• The authors are investigating generators for producing HDL of elementary function cores
• The authors do not advocate implementing hard double-precision arithmetic units on FPGA dies, seeing more value in the implementation of cascadable shifter/normaliser units. (See Underwood et al’s work for more background on this)

P.S. I used Roger’s Online Equation Editor to format the equation in this post, it’s a nice useful website