The RASSP Digest - Vol. 3, September 1996

An Application Configuration Language for Multicomputer Tool Development

by Barry Isenstein, Michael Krueger and Arlan Pool

Abstract

Developing software applications for scalable, heterogeneous platforms is a highly specialized, time consuming task. This paper discusses a new development that provides an interface for developers and is an intermediary for innovative application development tools. A 'component software' approach insulates both the application developer and tool developer from platform issues while facilitating high-performance execution of applications. Central to the development is a new open application framework that uses an application configuration language based on the well-known Tool Command Language (Tcl), written by John K. Ousterhout of Sun Microsystems and UC Berkeley. Adoption of the framework by advanced tools potentially offers a dramatic programming productivity gain over existing practices.

1. An Application Framework

An open application framework provides a pre-existing application structure to assist the developer in creating portable applications. The application framework described herein should be readily understood by RASSP developers since it provides a software development methodology analogous to the methodology applied in computer aided engineering (CAE) tools for developing complex chip or board designs. Hardware designers approach a complex design as a set of interconnected components as opposed to a monolithic entity. Users of CAE tools have various text-based and visual-based methods for representing a design. Early and often modeling and simulation of a design is essential for development. Portability and reuse are inherent in the CAE tool flow and further amplified by the establishment of standards.

The application framework addresses the requirements of software engineers who implement single-program multiple-data (SPMD) and multiple-program multiple-data (MPMD) scalable systems. For example, the framework is applicable to digital signal processing (DSP), image processing, simulation, or any application modeled as series of data transformations or as event-driven processes.

2. Application Configuration Language

Central to this development is the definition of a robust scripting language for expressing the relationships between the software application and a heterogeneous processor configuration called the Application Configuration Language (ACL). ACL is implemented as an extension of Tcl. Tcl is a procedural language that provides a complete set of control statements (e.g., lists, arrays, variables, procedures).

Talaris is a project name at Mercury Computer Systems for an ACL application framework for developers and high-level tools for RACE multicomputers. ACL, however, is system independent, and other ACL frameworks for different targets are underway. The points about the Talaris Framework will apply to other ACL frameworks.

The Talaris Framework uses component software concepts to provide a software reuse model and an application building mechanism that replaces the use of cumbersome make and shell scripts. These are the Talaris Framework characteristics:

  • Centralizes hardware and software configuration information.
  • Expresses assignment, data flow, and scale information algorithmically in a rich and natural manner.
  • Supports scaling of heterogeneous system components without imposing an application design model.
  • Remains independent of system-specific APIs and supports legacy executable programs.
  • Eliminates all target-specific setup and initialization code.
  • Enables fast turnaround of configuration changes.
  • Supports deployment.
  • Creates open framework interfaces that leverage standards.

Talaris reduces application building efforts by providing a ACL script and an inventory of software Programs and Modules. Software Programs are self-contained executable files (e.g., image files) whose interaction is opaque to the Framework. Software Modules are functions or subprograms that have Ports. Each module will run as its own thread. Ports represent how a Module sends messages, shares memory, transfers data, or synchronizes with other Modules. ACL does not impose any particular Port API and can use generic mechanisms.

3. Framework Structure

Figure 1 shows the Talaris Framework. The Generator receives input from three sources: 1) ACL commands, 2) reusable Modules, and 3) executable Programs. ACL commands may be user interactive, recorded in a user-written script, or produced from a tool client. ACL describes the hardware configuration and the software application. For example, ACL describes how Modules connect to each other. In the CAE analogy, a Module is comparable to an integrated circuit (IC), a Port to a pin on that IC, and the connection of Ports to a wire that connects pins.

The Generator, which runs on a workstation, creates a Launch Kit. By interpreting the ACL commands, the Generator builds executable images from Modules as needed. The Generator also places run-time setup information into each Launch Kit.

The Launcher, which runs on a designated processor, analyzes the Launch Kit. The Launcher then loads images, sets up the global interprocessor communication environment, and spawns each process. The application is now running. Embedded applications require only a Launch Kit(s) and the Launcher.

Figure 2 introduces the concept of Talaris Domains. Domains are containers for components and are useful for dealing with heterogeneity, application scale, and configuration. It is desirable that changing any one of these aspects result in only a minimal effort. Connections take place within a Domain. Assignments are across Domains.

The four Domains are as follows:

Software Domain

The Software Domain is where instances of Modules and their Port connections are created. Heterogeneity is supported by specifying that Modules are either written in a portable language or for performance reasons, critical Modules have an optimized version for each processor type. In a modeling environment, Modules are behavior models of the function instead of functional components. The Software Domain represents the functionality of the application.

Process Domain

The Process Domain depicts the assignment of Modules to processes. Process scheduling policies are parameterized in this Domain. The Process Domain places an executable software structure on the functional application.

Target Domain

The Target Domain describes the ideal assignment of processes to Compute Environments (CEs). The Target Domain expresses the ideal scalability assignment of an application that might prove useful for actual hardware assignment.

Hardware Domain

The Hardware Domain is the processor assignment that represents the actual hardware present. Connections of components within the Hardware Domain (not shown in Figure 2) represent the processor connection topology. In a modeling environment, the Hardware Domain represents simulation models of existing or future hardware.

4. More on ACL

ACL includes all standard Tcl commands. A partial list of Tcl commands illustrates usefulness for implementing embedded command processing:

variables: set, $x, array, $x(y), incr, argv, env
control: if, for, foreach, while, exit
lists: list, lappend, llength, lindex, lreplace, concat
strings: string, join, split, append, format
functions: proc, return
I/O: open, close, eof, gets, puts, cd
other: catch, eval, exec, expr, trace

Following is a list of the ACL commands:

types: declare, get_type, delete
instances: create, delete
assignments: assign, deassign
connections: connect, disconnect
properties: set_property, get_property, delete_property
scale: set_scale, get_scale
run-time environment: target
information: query
application construction: generate
application control: load, initialize, start, run

It is not within the scope of this paper to explain detailed ACL examples. We refer the reader to the ACL tutorial and other documents available at http://www.mc.com/technology.html.

Figure 3 shows an illustrative example of a simple Software Domain connection to a Hardware Domain assignment (explicit Process and Target Domain assignments are optional).

5. ACL Development Scenario

An ACL development scenario starts with an inventory of Modules and Programs. Modules are supplied as libraries by vendors, created with code generation tools, or manually written. This inventory provides a reusable code base for concurrent and future projects.

An ACL script is required that 1) defines and creates Modules and Programs, 2) defines and creates Processes (optional), 3) describes the Target (optional) and Hardware Domains, and 4) makes the assignments between Domains. The ACL script could represent a manual effort, an automatic task from a high-level tool, or a combination of manual and automatic efforts.

The ACL script is then loaded into the Generator. The Generator incrementally builds a model of the application and database of connections and assignments. The Generator is eventually given the ACL command to “generate,” and the following two step process takes place:

Step 1: The Generator analyzes the application

  • determines what runs where
  • devises a plan for initializing connections
  • performs additional validation
  • links Modules and Agent Module to form generated executables
  • creates the Launch Script used later to initialize and start the application

Step 2: The Generator creates the Launch Kit with

  • Launch Script (loading, spawning, IPC setup)
  • executables for generated programs (made from Modules)
  • executables for user programs (Programs)

The single ACL command “run” instructs the Launcher to do its job. In summary form, the Launcher

  • analyzes the Launch Kit
  • extracts and executes the launch script
  • loads executables
  • sets up global IPCs
  • spawns threads in processes
To accomplish its function, the Launcher uses a special Module provided by Talaris called the Agent Module. The Agent Module is linked into generated programs and provides the “main()” entry point. The Agent Module uses data in the Launch Kit provided by the Launcher to create and initialize local IPCs and prepare Modules for execution. The Agent Module then reports back to Launcher, and when directed by the Launcher, starts the Modules.

6. Comparision to Conventional Development

Table 1 illustrates the comparison of a conventional software development cycle to using the Talaris Framework. As indicated in Table 1, ACL, the Generator, and the Launcher replace, or obviate, many of the conventional development tasks.

Although Talaris supports legacy code through the Program entity, achieving the main benefits of the Framework occur when employing Modules (boxed area in Table 1). The Framework allows the code developer to concentrate on application code rather than learning platform-specific API protocols. Application development can then be focused on functional correctness (i.e., making connections in the Software Domain), scheduling policies (parameterized in ACL Software and Process Domains), and on application mapping (i.e., making assignments across Domains).

Connections and assignments can be expressed algorithmically using powerful Tcl and ACL constructs. For example, it is possible to create a process-to-processor mapping algorithm in ACL that responds to parameter changes in hardware interconnect, scale, and heterogeneity.

The developer determines the optimum assignment and mapping, either by an algorithmic or a manual approach. The Talaris Framework does not impact application performance since no generated code is added to the application. Modules are directly connected as if they were coded manually. The application performance will depend on the effectiveness of the assignment and scheduling, and the platform’s implementation of the Port APIs.

7. Talaris as a Tool Intermediary

The Talaris Generator presents itself as an interactive shell on the development system. A Talaris project goal is to facilitate rapid third-party development of advanced tools by eliminating many of the platform-specific build and run issues that are typically a large portion of a tool porting effort.

Advanced tools will “hide” the ACL framework from the application developer. Software Modules become reusable components for quick and easy manipulation by the developer using innovative tools with clever user interfaces. A tool presents a helpful interface(s) (e.g., data-flow GUI) to the programmer for connecting and assigning software and hardware Modules. Code generation tools could be invoked to create software Modules. Intelligent tools may assist the developer in offering semi-automated hinting to complete automation of Module assignment to hardware elements. The tool appropriately issues ACL commands to a framework and when directed, the framework dutifully constructs and runs the resulting application.

With an ACL framework ported to other platforms, a single tool can offer portable execution by simply directing output to a different target system.

8. Future Work

Work with Talaris Framework will focus on three areas: 1) robustness and standardization, 2) high-level tool development, and 3) research for large-scale systems.

Talaris represents a new approach which has been a missing ingredient in the effort to develop scalable systems. With sufficient experience by both application developers and tools vendors, formal standardization of ACL will be pursued so that control of the interface will be passed to a public body.

Mercury will assist vendors and research organizations interested in interfacing existing high-level GUI-based tools to the Talaris Framework. Mercury expects various types of tools to be available in the areas of performance modeling and application building, in addition to porting the Talaris Framework to other hardware platforms.

The most promising aspect of the framework is the potential to solve difficult large-scale system problems. Topic areas include automated scheduling, assignment, dynamic reconfiguration, and fault resilience.

Barry Isenstein, Michael Krueger and Arlan Pool
Mercury Computer Systems, Inc.
199 Riverneck Road
Chelmsford, Mass. 01824
barry_isenstein@mc.com

Newsletter Index
The RASSP Digest - Vol. 3, September 1996
newsletter/html/96sep/news_3.html