SAIP HighClass Control Program Development and Integration

The HighClass Command Program (CP) software development employed the RASSP layered command program model, depicted in Figure 1, the RASSP Autocoding Environment, shown in Figure 2, and the RASSP CP Software Development Process depicted in Figure 3. This section of the Case Study will discuss the BM4 CP software development experience in view of these RASSP tools and processes. For a more general discussion of the Command Program model, environment and process, see Autocoding for DSP Control - Application Note. A brief overview of the model, environment and process follow.

Figure 1: Layered Command Program Architecture

The Layered Command Program Architecture, reflects the bridging role played by the command program between the SAIP system and the High Definition Imaging and Classifier graphs. The bottom two layers address the graph perspective while the top two layers address the SAIP system perspective. The bottom most layer is the Command Program Interface (CPI) layer and consists of the generic set of graph control functions provided by GEDAE. This layer can be viewed as Commercial off the Shelf (COTS) software from the perspective of the CP. The next layer is the Application Specific Interface (ASI) layer. It is generated by the Application Interface Builder (AIB) and provides a high level set of functions used to instantiate, control, and configure the Benchmark4 top level graph. The next layer up is the Executive Finite State Machine layer that reflects the state of the signal processing application. For this application the state machine layer is trivial since the delivered application supports only two radar modes. The User Interface layer, however, is extensive. This layer manages all communications with the SAIP system environment including receiving and decoding frame messages and image chips and encoding and issuing completed frame messages. The challenge in the BM4 application was determining how to most effectively implement the UI layer; it will be discussed in subsequent sections.

Figure 2: System Software Developed with AIB and GEDAE™

Figure 2, System Software Developed with AIB and GEDAE, shows the overall development environment. The GEDAE application is used to develop and test the SAIP graph to be controlled by the CP. Under control of the GEDAE application, and totally independent of the CP, the developed graphs can be executed on the embedded Alex boards. Once a graph is completed and tested in the ™ environment, ™ will build an application specific launch package. The launch package contains the DSP executables as well as corollary information needed for program instantiation and initialization under CP control. For early command program testing the graph executables were targeted to the Solaris development environment, for later integration and test they were retargeted for execution on the SHARC processors on the embedded Alex boards. The AIB user provides a small text file describing the mode/launch package association and parameter set filename. The launch package corollary information is readable by AIB and provides AIB with a description of all queue and parameter names and their data types. AIB then constructs the ASI functions, which can then be integrated with EFSM and UI level source code to complete the CP.

Figure 3: Software Development Process

The development process used for the SAIP command program is shown in Figure 3, Software Development Process. These steps are summarized next and discussed in detail in subsequent sections.

STEP 1: Command Program Development

Command Program development starts with overlaying the application mode/submode structure onto the top level graph definition, which enables the execution of AIB. Once the Application Specific Interface has been generated by AIB, the construction of the Enhanced Finite State Machine (EFSM) and the User Interface (UI) layers is performed, since either might invoke AIB generated functions

STEP 2: Command Program Top Level Graph Integration

Following CP development, the CP is integrated with the top level graph. The Top Level graph at this stage only needs to perform data flow adequate to exercise the command program. Since graphs can easily be retargeted in ™ this integration can be performed on the CP development host.

STEP 3: Command Program Target Integration

The goal, at this development step, is to verify that the actual command program executes as expected with the target hardware and in cooperation with the rest of the command and control system. This is performed independently from the detailed signal processing. The approach is to again use the Top Level graph but to retarget its execution to the final target hardware; this is easy to do in the ™ development environment

STEP 4: System Integration

Concurrent with Step 3, Command Program Target Integration, DSP application target integration has been occurring. When this critical step is complete, the final system integration uniting CP and final graphs may occur.

Figure 4: Command Program External Interfaces

External Interfaces

Figure 4, CP External Interfaces, shows the command program external interfaces. Processes tsDispatch, imageSrv, and partner are all Test Bench processes. The CP external interfaces where designed to leave these interfaces totally unchanged. The target processing rate is 30 chips /second. The basic information flow is as follows:

Template sets are downloaded to graph on mode changes
tsDispatch sends a Frame message containing a set of image chip identifiers to be processed
CP requests each image chip from the image server.
CP forwards each image chip plus some corollary processing data to the graph
Graph returns enhanced images and classification results to the CP
CP constructs a new frame message containing all enhanced images and classification results and forwards the frame message to partner.

Command Program Source Code Development

The major issue in command program source code development was the development of the UI layer. Three options were considered: 1. Use VerilogÕs ObjectGEODE graphical programming and simulation tool (See Autocoding for DSP Control - Application Note) 2. Reuse MIT Lincoln Lab (MIT/LL) Executable Specification Software 3. Use traditional handcoding The evaluation of these options began with a careful review of the executable specification (several C++ programs) provided by MIT/LL, since it contained the detailed requirements to be levied on the CP. The review concluded that reuse of a portion of the executable specification was the most technically sound, least risk and most cost effective approach. The executable specification was found to be well structured and contained a program called "highClass" that already performed all of the UI level functions. Significantly, highClass was already integrated with the MIT/LL Test Bench Software. Due to the clean structure of highClass it was determined that AIB generated ASI calls could be easily incorporated and that the modification required to interact with the graphs could be included without altering the Test Bench interfaces or the underlying Inter Processor Communication (IPC) software. The use of ObjectGEODE was rejected because the strengths of the tool were not well matched to this particular CP problem. One of the strengths of ObjectGEODE is managing communications among concurrent threads. In this case the concurrent threads would naturally be the command program, and the Test Bench processes. To use ObjectGEODE on only the CP program portion of the application would forfeit a major strength of the tool. A second ObjectGEODE forte is representing heavily state oriented applications, but in this case the EFSM layer was trivial so again the application was not well matched to ObjectGEODE. Since the highClass program was a cleanly written, easily understood small program with a clean interface into the IPC software it was clear that there would be significantly lower labor costs and risks to modify highClass than to rewrite it from scratch.

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

Table 1: Benchmark 4 Source Code

The transformation of highClass proved straight forward and largely consisted of removing software that had interfaced with an Executable Specification Process called Candidate , moving some Candidate software into highClass, restructuring the main program loop and adding calls to ASI level software. (Most of the processing in Candidate was moved to the 72 SHARC embedded processors and generated by ™.) The code sizes shown in Table 4, Benchmark 4 Source Code, indicate that approximately 50% of the command program was constructed from AIB generated software. Note that additional functions generated by AIB totaling 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 4. (It was reused without modification.)

CP - Top Level Graph Integration

The early development of the Top Level Graph (discussed in an early section of this Application Note) allowed early and iterative CP program graph integration. The goal of this step was to validate CP -graph interfaces. The interfaces were designed to preserve the original highClass - candidate interface so logic was developed in the GEDAE graph to decode a "flattened" control message (candidateStart & image) and to encode a "flattened" result message (candidateDone). This logic was easily validated with the top level graph running embedded on a Sun Workstation rather than on the embedded hardware.

The second goal at this stage was to validate Test Bench - CP - Graph interaction. Again for initial integration a simple top level graph executing on a Sun Workstation was sufficient. This step was also easily validated since the CP reused the highClass process from the executable specification, which had already been integrated with the Test Bench. The system was ready for initial tests on the embedded processors.

CP - Target Integration

As was the case in the previous phase, the early development of the Top Level Graph allowed early and iterative CP - Target integration. The goal of this step was to validate that the CP could correctly interact with the graph when the graph was running on the embedded processors. The key issue was whether or not the host (CP) to board (Graph) communication rate was sufficient to sustain a 30 chip per second processing rate. The basic command program loop was:

Fetch image from image server
Download image to graph
Fetch processed image and classification from Graph

Reaching the 30 chip per second rate ( approximately 3 Mbytes/sec) proved to be a challenge that required considerable fine tuning of the host to board communication protocol. A significant benefit of the early use of the top level graph was that it allowed this key issue to be addressed prior to final system integration.

Final CP - Target integration utilized a version of the top level graph that returned canned HDI results and calculated Classification results for a limited set of image chips. Processing delays were built into the graph such that the processing time was the predicted time. In this way, the top level graph was indistinguishable from the final graph to the CP. Once the host to board communication was tuned, this step was straight forward (TO BE VERIFIED (TBV)).

CP - Final Graph - Target Integration

(TBV) The goal of this stage was to integrate the CP, final graph, Test Bench and embedded hardware. The development process on the graph side (See Figure 3) shows that by this stage the graph developers had validated final graph execution when running embedded under the control of the GEDAE environment. The CP had been fully integrated with the top level graph. From the perspective of the CP, the only difference between the final graph and the top level graph was the addition of a few visible parameters in the HDI subgraph. These were managed by the AIB generated ASI functions so the highClass software was totally unchanged from earlier versions. The previous process steps on both the CP and graph sides made this step trivial. For more details on final system integration see Section TBD of this Application Note.

Challenges and Lessons Learned

Minimize high bandwidth communication between host and embedded processors. The preferred approach is to use embedded I/O boards whenever possible.
Develop a top level graph early in the program and use it extensively for Command Program testing.
Exploit graph retargeting between development host and embedded boards.

Approved for Public Release; Distribution Unlimited Bill Ealy