Figure 7 illustrates the major elements of the MSI. Applications are written in one or more of the SAPI source languages. The target platform and the set of possible configurations of the target platform are described using the PCA machine model metadata context, described below. The Morphware Forum has begun defining a metadata context for application information including such elements as performance requirements (e.g., computational throughput, latency and power), input rates, and module interconnections. This metadata context is currently undefined, and no existing high-level compiler uses this context. Currently all high-level compilers optimize for execution time, and do not support specific performance requirements.
Figure 7. Elements of the MSI.
The high-level compiler is responsible for selecting the desired platform configuration, and for converting the SAPI source code to SAAL code. The high-level compiler performs coarse-grained parallelization of the input application, based on the granularity appropriate to the target platform. In order to accomplish this effectively, the high-level compiler must have a description of the target platform. This description is provided in the PCA machine model metadata context [14], where the capabilities and resources of PCA platforms are described in terms of a common, high-level model that allows the high-level compiler to perform accurate performance estimates. The output from a high-level compiler is SAAL code and a desired initial platform configuration. Depending on the application source language, the SAAL intermediate code may be Streaming Virtual Machine (SVM) code, User Virtual Machine (UVM) code, or Threaded Virtual Machine-Hardware Abstraction Layer (TVM-HAL) code, described below.
The low-level compiler is an architecture-specific build tool that accepts the SAAL code and desired platform configuration metadata output by the high-level compiler and produces native machine code suitable for execution on the target PCA platform. If a performance constraint, resource requirement, or desired configuration is unobtainable by a low-level compiler, that low-level compiler fails and reports the error.
The Stable Architecture Abstraction Layer
The SAAL is composed of a number of parts, each
addressing particular aspects and requirements of application programs and the
high-level compilers. Streaming code is
primarily translated into an intermediate language described by the Streaming
Virtual Machine [15]. The SVM
supports the mapping of kernels and streams onto virtualized processing and
memory resources. Conventional code and
the control code for the streaming languages are translated into an
intermediate language described by the Threaded Virtual Machine. The TVM includes support for numerous
non-streaming activities. A portion of
the TVM, called the Hardware Abstraction Layer (TVM-HAL) [16], defines a thin abstraction layer for low-level
hardware services such as memory mapping and exception handling. Many TVM capabilities, such as access to
privileged instructions, are used only by operating system functions. Therefore, a User Virtual Machine (UVM)
interface has been defined that contains somewhat restricted functionality that
is intended to be used directly by application code and libraries [17].
Application programmers will not normally interact with
any of the interfaces at the SAAL level.
This code is either produced by the high-level compilers, or is
contained in special-purpose libraries or operating system code written by
expert library programmers. Figure 8 depicts the relationships between the various
interfaces.
Figure 8. The relationships between applications, SAAL layer interfaces, and the underlying PCA hardware architecture.
Stream Virtual Machine Overview
The streaming virtual machine is the portion of the SAAL API that implements streaming functionality on virtual resources. The SVM allows streaming applications to be expressed in terms of operations on the set of streaming virtual resources described below. These resources are mapped directly to physical resources in a PCA system by the low-level compiler.
The virtual resources within the SVM API are:
· Streams are sequences of data elements of a specified type. Streams are used for sequential production and consumption of data elements.
· Kernels are computational engines that consume zero or more input streams, and produce zero or more output streams. Kernels are described using a subset of C, and also maintain execution state information.
· Blocks provide random, indexed access to a fixed set of data elements.
· Controls are independent computational engines that can initiate, monitor and control the state of, and terminate kernels. Controls are described with a subset of C.
· Data elements are primitives supported by a particular platform, arrays of fixed length, or fixed-sized structs containing primitives and arrays.
The SVM API is a C API that can be implemented as a library, if desired, for testing and debugging purposes. The SVM API is described in detail in the document titled “PCA Morphware Virtual Machine Specification” [15].
Thread Virtual Machine Overview
The thread virtual machine is comprised of two major elements, the TVM Hardware Abstraction Layer, and the User Virtual Machine. The TVM-HAL provides a SAAL level virtual machine interface for threaded portions of PCA applications and libraries. The TVM-HAL is a privileged interface that provides a thin layer of abstraction on the available PCA architecture and presumes total control over the available resources. The UVM is also a low-level interface, but does not presume total resource control over the platform. This allows a more direct mapping from application code, but also requires a richer interface to allow user-level response to changes in resource availability, or failure to obtain requested resources. The UVM and TVM-HAL together address the major areas of processor control, exception handling, and memory management, as well as several other low-level requirements to support general purpose threaded software.
Processor control and exception handling in the UVM and TVM-HAL include support for exception vectoring of up to 255 exceptions, with special state maintenance code for exception handlers; instructions to convert a processor from a threading mode to streaming mode; and a scheduler activation interface. The scheduler activations interface [18] provides a communication mechanism between a kernel-level scheduler and application code. This interface provides for a set of callbacks to user code when a processor has been assigned to or taken away from a process, or when a thread has become blocked or unblocked (for example, while waiting for I/O).
PCA architectures differ from conventional architectures in that they have many distinct blocks of memory distributed across the system. This requires special handling for memory addressing in the UVM and TVM-HAL interfaces. Memory management in the UVM and TVM-HAL includes support for segmented memory as well as paged memory. Paged memory control is available in the TVM-HAL but not in the UVM. The segmented memory model allows for virtual addressing and configuration of individual segments, including whether a segment is visible to a particular processor, initial virtual and physical addresses, and caching control.
The UVM and TVM-HAL support several other control constructs including active DMA, multiprocessor synchronization, mutex locks, cache memory control, performance counters, IEEE 754 floating point control, and condition variables.
PCA systems are designed to meet a variety of goals and constraints, and to function on a wide variety of platform configurations. PCA applications require a large amount of information in addition to the procedural definitions of programs in source languages. Examples of this information are the computing resources available on a particular host platform, the set of possible configurations of these resources, desired optimization goals for a particular piece of software, and computing resources required by a particular piece of compiled software. This set of descriptive and extra-functional information is known collectively as metadata.
Each of the specific uses for metadata within the MSI is known as a metadata context. At this writing, the PCA machine model is the only defined metadata context. Others are under consideration by the Morphware Forum, for example an application information metadata context and a context describing high-level compiler output assumptions and decisions.
In order to ease the development of build-chain tools and speed the development of PCA applications, the MSI includes a standard method for describing metadata contexts, as well as a standard method for expressing and storing metadata. For example, metadata is stored in XML text files. The PCA metadata system is fully described in the document titled “PCA Metadata System” [13].
Machine Model Metadata Context
A PCA machine model is a generic model used to describe specific PCA platforms. The primary purpose of the machine model is to describe PCA platforms in a common manner to the various tools in the MSI framework. The consumers of this description are high-level compilers, which are responsible for dividing applications into appropriately sized portions for a target platform. The parameters of these models are communicated to the compilers and other tools as metadata in the machine model metadata context, which is formalized in the document titled “PCA Machine Model” [14].
A PCA machine model contains three types of elements: resources, ingredients, and morphs. A resource is a description of a discrete device with well-defined functionality. There are three kinds of resources in a machine model. These are:
· Processors: anything that consumes, produces, or moves data. Examples of processors are functional units, DMA engines, and I/O devices.
· Memories: Any resource that stores data. Examples are RAM, FIFOs, and cache memory.
· Network Links: Any communication pathway between resources. Network links may have an arbitrary number of senders and receivers.
Resources have a variety of parameters to allow detailed descriptions of their capabilities.
An ingredient is a description of an arbitrary, configurable division of underlying hardware. An ingredient can be configured, possibly in concert with other ingredients, into one or more resources. Ingredients provide a mechanism for identifying resources that cannot coexist on the physical platform.
Finally, a morph in the machine model is a description of a state into which a PCA platform may be configured. The metadata describing the morph defines how the machine model ingredients can be configured into resources by the compiler. More than one morph may be active at once, but no two morphs that share an ingredient may be active at once.