Stream Computations Organized for Reconfigurable Execution

Abstract

Reconfigurable systems can offer the high spatial parallelism and fine-grained, bit-level resource control traditionally associated with hardware implementations, along with the flexibility and adaptability characteristic of software. While reconfigurable systems create new opportunities for engineering and delivering high-performance programmable systems, the traditional approaches to programming and managing computations used for hardware systems (e.g., Verilog, VHDL) and software systems (e.g., C, Fortran, Java) are inappropriate and inadequate for exploiting reconfigurable platforms. To address this need, we develop a stream-oriented compute model, system architecture, and execution patterns which can capture and exploit the parallelism of spatial computations while simultaneously abstracting software applications from hardware details (e.g., timing, device capacity, and microarchitectural implementation details) and consequently allowing applications to scale to exploit newer, larger, and faster hardware platforms. Further, we describe hardware and software techniques that make this late-bound platform mapping viable and efficient.

On the costs and benefits of stochasticity in stream processing

“…To this end, the RAMP project at Berkeley is developing a massive FPGA-based emulator to study large-scale behavior of many-core systems [11], recently reaching the 1008-processor milestone [6]. However, current supercomputers integrate 300,000 cores, and "supercomputers with 100 million cores are coming by 2018" [28].…”

“…Streaming is effective in reconfigurable systems [11] and when each processing stage is im-plemented in dedicated hardware [24], e.g., 200 specialized stages in modern GPU pipelines. Wireless communications, cryptography, and video decoding are processed by deep pipelines with such dedicated stages as FFT, DCT, convolution, Viterbi coding, AES, motion estimation.…”

“…For example, an inorder pipeline with execution times 1,2,3 is 33% idle. Perfect balance can be impossible with irregular input [8,11,24], e.g., audio frames with a busy signal decode faster than normal voice frames; some video frames exhibit less motion than others. The performance of GPGPU programs processing irregular data is greatly affected by stochasticity due to (i) long graphics pipelines and (ii) increasing user-hardware separation encouraged by CUDA programming.…”

“…Unlike in [10], (i) no end-to-end latency deadlines are imposed and, (ii) our FIFO inter-stage queuing model does not provision for explicit communication, simplifying EEL computations. Stochastic stage completion times arise in several contexts [8,11,24]: (i) sensitivity of runtime to the complexity of input data, (ii) non-determinism due to randomized algorithms, shared resources, interrupts, and cache misses, as well as (iii) the lack of accurate information about (possibly deterministic) stage completion times. These diverse circumstances are analytically modeled by random varibles for stage completion times, making EEL a random variable.…”

VLIW-SCORE: Beyond C for sequential control of SPICE FPGA acceleration

“…In this paper, we propose a unified spatial methodology based on VLIW-SCORE. We use the existing, high-level SCORE [3], [5] (Stream Computation Organized for Reconfigurable Execution) framework described in Section III and couple that to a custom, hybrid VLIW architecture described in Section III-C. This allows us to compose the complete accelerator system entirely on the parallel FPGA fabric without resorting to sequential offload or excessively burdening the programmer.…”