Stream Compilation for Real-Time Embedded Multicore Systems

Abstract

Abstract-Multicore systems have not only become ubiquitous in the desktop and server worlds, but are also becoming the standard in the embedded space. Multicore offers programability and flexibility over traditional ASIC solutions. However, many of the advantages of switching to multicore hinge on the assumption that software development is simpler and less costly than hardware development. However, the design and development of correct, high-performance, multi-threaded programs is a difficult challenge for most programmers. Stream programming is one model that has wide applicability in the multimedia, signal processing, and networking domains. Streaming is convenient for developers because it separates the creation of actors, or functions that operate on packets of data, from the flow of data through the system. However, stream compilers are generally ineffective for embedded systems because they do not handle strict resource or timing constraints. Specifically, real-time deadlines and memory size limitations are not handled by conventional stream partitioning and scheduling techniques. This paper introduces the SPIR compiler that orchestrates the execution of streaming applications with strict memory and timing constraints. Software defined radio or SDR is chosen as the application space to illustrate the effectiveness of the compiler for mapping applications onto the IBM Cell platform.

An empirical characterization of stream programs and its implications for language and compiler design

“…For example, MP3 reorders and adds data across large (>1000 item) sliding windows; 802.11 and Trellis do short (3-7 item) bit-wise operations as part of an error-correcting code; Vocoder and Audiobeam use peeking to skip N items (by default [1][2][3][4][5][6][7][8][9][10][11][12][13][14], analogous to an inverse delay; ChannelVocoder performs a sliding autocorrelation and threshold across N items (by default 100).…”

“…This enables a new understanding of the fundamental properties of stream programs, without struggling to extract those properties from a general-purpose programming model. We utilize the StreamIt language [53], a mature system that is rooted in the synchronous dataflow model [33] and has been used as a research infrastructure for many projects outside of the StreamIt group [13,23,24,25,26,35,41,45,47,55,56]. Our benchmark suite consists of 65 programs and 33,600 lines of code, which were developed by 22 programmers during the last 8 years.…”

Communication-aware mapping of stream graphs for multi-GPU platforms

“…Therefore the SW code in Figure 4.4(d) is exactly the same as that of (b). Second, since the SW is the same, and G2 is only a scaled-up version of G1 with the exactly same architecture-the only differences being (i) GPU core clock, (ii) GPU memory clock, and (iii) stream multiprocessor count-we can expect the performance difference between Cases (d) and (b) to be very similar to that of the GPUs, which is between 23% (memory-bound) and 29% (compute-bound) 1 . This of course applies to Cases (a) and (c), too.…”

“…[2], the STI Cell processor [1,8] and FPGAs [3]. Those techniques often focus on exploiting task-level parallelism and balancing workloads among multiple processors.…”

Parallelizing with BDSC, a resource-constrained scheduling algorithm for shared and distributed memory systems

“…The SPIR (Signal Processing Intermediate Representation) compiler [36] takes a sequential dataflow program as input and generates a multithreaded parallel program for a multicore system. First, SPIR builds a stream graph where a vertex corresponds to a kernel function call or to the condition of an "if" statement; an edge denotes a transfer of data between two kernel function calls or a control transfer by an "if" statement (true or false).…”