The RASSP Digest - Vol. 3, September 1996

Autocoding Update

by Christopher B. Robbins

Abstract

Management Communications and Control, Inc. (MCCI) is developing autocoding tools under subcontract to Lockheed Martin, Advanced Technology Laboratories, Camden (LM/ATL). Under the technology base program, MCCI has developed the Graph Translation Tool (GrTT). These tools are intended to complement each other and will be integrated in MCCI’s autocoding toolset. The alpha version of our toolset has recently been evaluated by comparing the autocoded RASSP synthetic aperture RADAR (SAR) benchmark with an earlier hand optimized implementation. MCCI has recently completed work under its RASSP tech base contract on the Graph Translation Tool (GrTT). In technical testing, we used the same SAR benchmark. This article reviews the autocoding process and describes the combined use of GrTT and the autocoding toolset. A summary of the LM/ATL evaluation and MCCI’s GrTT testing is presented.

1. Autocoding Process

The autocoding process translates the data flow graph software architecture specification to an efficient parallel application for the target hardware architecture. Inputs to the autocoding process are application specifications in the form of a Processing Graph Method (PGM) data flow graph and hardware architecture specifications. Application graphs are target independent. This is an open API, specifying applications in a form that may be automatically coded for all RASSP targets. PGM is a target independent specification method. Target independent domain primitives are specified as the node executables. The autocoding process is applied in two levels; top level design and detailed design and coding.

In top level design, the Equivalent Application Generator Tool is used to partition input graphs into a connected set of component graphs specifying execution and functional behavior that is identical to the original graph. If allocations are not already specified, application graphs may be partitioned into software allocation and hardware partition graphs. The tool is then used to generate PGM graphs for each hardware partition and the entire software allocation. The software allocation graph is then repartitioned to the programmable elements of the target architecture. An equivalent application graph for the software allocation is created. In the equivalent application graph, each equivalent node replaces a software partition. At the ports of the equivalent nodes, the equivalent application graph behavior will be identical to that of its respective partition graph. The equivalent application graph and the set of hardware and software partition graphs complete the top level software specification. A performance assessment of the equivalent application graph is generated. The performance assessment may be used to quickly reject unfeasible designs.

GrTT is used in top level design to validate requirements capture from the algorithm development stage of codesign. GrTT accepts a partition graph with enumerated sets of external graph controls as its input. GrTT generates Ada graph behavior models that exhibit input graph behavior for all enumerated values of control. Behavior consists of a procedure implementing a sequence of domain primitive executions and intermediate queue states. A GrTT test support utility is provided that executes GrTT procedures as single node applications. GrTT behavior models are executed on test vectors generated by higher level design tools to verify requirements capture by the top level design. This feature may be used to verify both software and hardware partitions. Because of the closeness of Ada and VHDL syntax, GrTT behavior models may be reused as VHDL behavior architectures for hardware partitions.

The second level of the autocoding process is a generation of source code for the partition executables and a configuration file for the equivalent application graph. Configuration files are target architecture specific application descriptions binding graphical equivalent application entities to specific target hardware realizations. A load image specification is then created specifying the complete application to the compiler supporting the target architecture. Unit testing of executables is supported at this level.

Using the MPID Generator tool, each partition graph is translated into ‘C’ source code for an executable program implementing the partition behavior. MPIDs (Multi Processor Interface Descriptions) are optimized implementations of partition behavior utilizing the math library primitives supported by the target processor. MPIDs become the primitives of the equivalent nodes. Test images of the MPIDs are created. These are single node applications used in validation testing of what are in effect the application’s CSUs. Unit testing results are compared with GrTT test vectors to validate partition translation. With its executables validated, correct execution of the application can be expected.

The Application Generator generates configuration files from the equivalent application graph and the hardware description file. Hardware description files are automatically built from the input architecture description and may subsequently be edited by the user. A run-time support (RTS) utility is provided with the tools. The RTS provides application management, execution, and external control interface support. When instantiated, executable and controllable images of the application are created by the RTS from the application’s configuration file. A load image specification consisting of all configuration files in the application system, all supporting MPID source files, and necessary system files is then automatically generated.

2. Autocoding the SAR Benchmark

Engineers at LM/ATL Camden recently completed an evaluation of the alpha version of our autocoding tools. In this evaluation, the RASSP SAR benchmark was implemented using our toolset. The work required to develop the application and the code performance was compared with that of the previously hand coded effort. Demonstration cases were developed with GrTT for inclusion in the technical report for our tech base effort. We used the same benchmark to demonstrate use of GrTT in the context of an application development scenario.

This image is linked to a larger version.

Since the alpha version of our tools does not include the Equivalent Application Generator, partition graphs were manually created from the input software allocation graph. Figure 1 shows the allocation graph. It includes range processing and azimuth processing subgraphs. The range processing and azimuth processing partition graphs and equivalent application graph created from the allocation graph are also shown.

For best visibility this image must be printed.

GrTT behavior models were generated from the range partition graph to demonstrate GrTT in the context of the benchmarked development scenario. Figure 2 shows an excerpt from the GrTT behavior for the range partition. MPID source files were generated for the partition graphs using the MPID Generator tool. Figure 3 shows an excerpt of the MPID generated from the same range processing partition graph. The GrTT behavior model was exercised using the GrTT test utility on input data supplied by the LM/ATL benchmark development team. MPIDs were tested using the unit tester and validated against the same test vectors. Figure 4 shows a comparison of GrTT behavior model testing and MPID source testing using the common input test vector. An application image was created using a prototype application generator. Input and output procedures were written to interface the software allocation to the hardware implementation of the input/output processing. These are user written procedures; however, input/output service routines provided with the tools were utilized that perform graph functions; e.g., enqueueing data. Two design iterations were completed during the evaluation period to optimize the autocoded implementation’s performance on the available test hardware. The autocoded applications executed correctly without the need for a run-time test and fix effort.

For best visibility this image must be printed.

3. Summary of Evaluation and Test Results

Table 1 summarizes the results the evaluation and compares them with the hand coded optimized implementation. MCCI’s autocoded implementation of the benchmark required an additional processor for its memory. Features not included in the alpha version of the toolset will make memory usage comparable to the hand coded version when incorporated. GrTT testing was accomplished by MCCI independent of LM/ATL’s evaluation. Results are compared with the validation testing accomplished by LM/ATL to illustrate its future integration.

4. Progress Towards 4x Productivity Improvement

LM/ATL’s evaluation of the alpha version of the autocoding tools demonstrated that MCCI’s autocoding tools will generate application code with performance comparable to optimized hand coded implementations with an order of magnitude improvement in development productivity. This will meet the productivity enhancement goals required in the software generation elements in LM/ATL’s productivity improvement model. Further improvements are anticipated as our tools mature. A reevaluation of the beta version of the autocoding tools is planned for July '96. Further improvement in run-time performance and productivity should be observed. We believe this additional improvement beyond the requirements will have beneficial synergistic effect with other elements of the codesign process.

Christopher B. Robbins
Management Communications and Control, Inc.
2000 North 14th Street, Suite 220
Arlington, VA 22201
crobbins@mcci-arl-va.com

Newsletter Index

The RASSP Digest - Vol. 3, September 1996
newsletter/html/96sep/news_4.html