Next: 9 References Up: Appnotes Index Previous:7 The Software Development Process

RASSP Autocoding for DSP Control Application Note

8.0 Application Experience

The Application Specific Interface Builder (AIB) was used on both Benchmark (BM) 3 (Sonar application) and Benchmark 4 (Image Processing application). A very preliminary version was used on a simplified Benchmark 2 (Radar application). In all cases AIB was used to generate more than 50% of the CP source code. The mode / submode abstractions proved appropriate for each benchmark domain and Application Specific Interface (ASI) level software did not need to be tailored for any of the examples. None of the Benchmark CPs were distributed applications nor did they involve complex mode/submode level state transition logic. Consequently, ObjectGEODE was not employed to generate the Enhanced Finite State Machine (EFSM) layer of any of the CPs.

8.1 BenchMark 2

As an initial proof of concept, a simple version of AIB together with ADI's Beacon tool was used to generate a simplified version of the BM 2 CP. The Signal Processing Program (SPP) was generated by MCCI's signal processing autocoding tool. At the time of the experiment, the MCCI Command Program Interface (CPI) was not completed so a simple CPI allowing the CP to run / stop / load a parameter was created by modifying a similar existing interface. Since the CPI and UI level software were in Ada, the proof of concept AIB was programmed to generate Ada. The Beacon tool, which also had an Ada generation capability, was used to generate the EFSM level. The combined autocode CP and SPP application was successfully demonstrated at the November 1996 RASSP conference.

Layer	Generation Tool	Lines (approx)
User Interface (UI)	Heritage	200
Execute Finite State Machine (EFSM)	Beacon	100
Application Specific Interface (ASI)	AIB	500
Command Program Interface (CPI)	hand	?

Table 8 - 1: Benchmark 2 Source Code

Following the success of the BM 2 proof of concept AIB was rewritten to generate C compatible with the GEDAE™ CPI. This version was used on both BM3 and BM4.

8.2 BenchMark 3

The Benchmark 3 (BM3) program provided the opportunity to demonstrate AIB on a Mode with multiple submodes and to extend the code generated by AIB into the UI and EFSM layers. As can be seen from Figure 8 - 1: Schematic BM3 Top Level Graph, the BM3 SPP appears to naturally split into two submodes depending on the Switch Box control parameter. During graph testing however it became clear that BM3 should in fact be viewed as having four submodes. This is due to four distinct parameter sets being developed and the graph pipeline needing to be completely cleared of processing before changing each parameter set. In essence the CP path had two sub-configurations and the CW path also had two sub-configurations. AIB generated ASI layer software easily accommodated this change in perspective.

Figure 8 - 1: Schematic Benchmark 3 Top Level Graph

Although the BM3 application CP is ultimately intended to be embedded in a large UYS-2 CCS, for the acceptance test the CP needed to be a simple stand-alone program. This provided the opportunity to extend the scope of code generation in AIB to the UI and EFSM layers. AIB was extended to generate a "generic" CP where the User Interface was textual and was composed of a collection of menus that allowed the selection of submode and setting of all parameters visible to the CP. This generic CP proved to be sufficient, with minor tailoring, for the BM3 acceptance test. As can be seen from Table 8 - 2, BM3 Source Code, the combination of AIB generated ASI software and the AIB generated generic CP reduced the amount of handwritten software for the CP to less than 10%.

Layer	Generation Tool	Lines (approx)
User Interface (UI)	AIB	1200
Execute Finite State Machine (EFSM)	hand AIB	200 200
Application Specific Interface (ASI)	AIB	3500
Command Program Interface (CPI)	GEDAE COTS	750

Table 8 - 2 Benchmark 3 Source Code

Additionally, a second simplified BM3 command program was constructed using ObjectGEODE. The purpose of this experiment was to validate the ability to easily integrate AIB generated source code, ObjectGEODE generated source code and the GEDAE™ CPI into a single command program to control a GEDAE™ graph. The results showed that this process was straight forward.

8.3 BenchMark 4

Benchmark 4 (BM4) provided the opportunity to verify that AIB generated software could cross application domains and be easily integrated into a command program largely composed of heritage software. The BM4 program sponsor, MIT Lincoln Laboratory, provided an executable specification and test bench for the application. The test bench included a process known as "highClass" that controlled a process known as "Candidate". Most of the processing in Candidate was to be moved to 72 SHARC processors with the SPP generated by GEDAE™.

Layer	Generation Tool	Lines (approx)
User Interface (UI)	Heritage Hand	400 100
Execute Finite State Machine (EFSM)	Heritage Hand	400 100
Application Specific Interface (ASI)	AIB	500
Command Program Interface (CPI)	GEDAE COTS	750

Table 8 - 3: Benchmark 4 Source Code

Since highClass already possessed all of the UI and EFSM level code to interact with the rest of the test bench, it was natural to transform highClass into the command program. This transformation process proved straight forward and largely consisted of removing software that had interfaced with Candidate, moving some Candidate software into highClass, restructuring the main program loop and adding calls to ASI level software. The code sizes shown in Table 8 - 3, Benchmark 4 Source Code, indicate that approximately 50% of the command program was constructed from AIB generated software. Note that AIB generated additional functions, totally another 1000 lines, were not needed for this particular application. Also note that a significant amount of Interprocessor Communication Software employed to communicate between the CP and the rest of the software test bench is not included in Table 8 - 3. (It was reused without modification.)

A number of conclusion can be reached from the RASSP benchmark projects:

The Application Specific Interface Builder (AIB) simplifies CP construction by autocoding the Application Specific Interface layer that is error prone and tedious to implement manually. The ASI layer is needed by all command programs.
The Application Specific Interface Builder generates an easily tailored generic CP that can serve as a basis for demonstration and test command programs.
ObjectGEODE generated code is easily integrated with AIB generated code to form CPs that control GEDAE™ generated graphs.

Additional work is required on the Application Specific Interface Builder to prepare it for inclusion with the GEDAE™ commercial product line. The ASI layer abstractions require further refinement and the generic command program concepts need to be extended. Some of this work will be performed in 1998 and 1999 under the Navy/Lockheed Martin ATL DUAP program.

Next: 9 References Up: Appnotes Index Previous:7 The Software Development Process

Approved for Public Release; Distribution Unlimited Dennis Basara