|
|
|||||||||||||
|
The term type architecture was introduced by Larry Snyder to refer to a model that is a ``region of consensus, … explicit about a few salient features [of a family of computers] and mute on everything else''. Type architectures define, in the most abstract terms possible, the resources, behavior1, and performance characteristics a programmer can rely on from any conforming computer, and what an implementer is obliged to provide in one form or another. Performance characteristics are defined by costs associated with operations within the model. Successful type architectures can serve as the central archetype for a variety of computers, languages and algorithms. However, type architectures that do not paint a realistic picture, such as the PRAM model for parallel computers, can lead to unrealistic expectations on the part of algorithm designers, and thus theoretically optimal algorithms that are not optimal on any realistic machine \cite{Snyder1986}.
The goal of the hybrid micro-parallel (HMP) type architecture is to improve the programmability of these hybrid computers. The HMP type architecture is an extension of the sequential von Neumann machine and accommodates a variety of computers, from FPGAs with embedded sequential processors, to hybrid reconfigurable computers based on architectures like PipeRench and RaPiD, and to some degree SIMD architectures like Imagine and vector processors. The components of the HMP architecture are illustrated in in the figure at the right. Execution is performed by two distinct components: a sequential, von Neumann, processor on the left and a micro-parallel engine, on the right. The hybrid architecture executes a single program with a single thread of control; the locus of execution can switch from the sequential processor to the micro-parallel engine and back, according to the kind of computation currently being executed. Abstractly, these two execution engines share all memory resources.
The micro-parallel engine contains a ``workspace'' memory, an array of functional units, and control resources of some sort. The number and type of the functional units available is unspecified and will vary from implementation to implementation. As a rough guideline, programmers should expect tens to hundreds of functional units.
The workspace memory models all the registers and memories distributed throughout the micro-parallel engine. The size of workspace memory is implementation-dependent, but is always much smaller than the main memory. An example of workspace memory are the block RAMs, lookup tables, and registers distributed throughout the fabric of an FPGA. The internal data bandwidth within the micro-parallel engine is high enough to sustain maximum parallelism, while the bandwidth between the main memory and the micro-parallel engine is limited in the same way that this bandwidth is limited in the sequential processor. The communication between main memory and the workspace memory is, in many cases, specialized to support high bandwidth for typical memory access patterns. For example, programmable DMA channels are a simple way to support the predictable memory accesses made by most signal and media processing algorithms.
The workspace memory of the type architecture explicitly exposes one of the major challenges encountered in programming a HMP computer: that of ordering the computation so that the required data is in the workspace memory when it is needed. Note that automatically managed caches, commonly found in sequential processors, are not present in most micro-parallel engines, and are not the most efficient way to exploit the simple, predictable communication patterns that exist in most micro-parallel algorithms.
The rules governing the execution of the HMP model, like its basic components, are an extension of the rules governing the von Neumann machine. When a program begins executing, it runs just as a program on the von Neumann machine would. However, special instructions can cause the machine to transfer from sequential mode to micro-parallel mode. In micro-parallel mode, the sequential processor is inactive and the controller in the micro-parallel engine orchestrates execution in the spatial fabric. When the micro-parallel engine finishes its task, control transfers back to the sequential processor. The micro-parallel engine cannot transfer control back to the sequential processor in any way other than ending its current task--the two components are not peers in this regard.
1The behavior of a type architecture is often referred to as an execution model.
|
UW
Embedded Research Group Last modified: Wed Jun 7 16:38:57 PDT 2006 |
