HighClass Prototype Hardware Integration and Test

Introduction

The HighClass prototype hardware integration and test activities were focused on two areas:

Figure 1: Overview of BM4 Hardware Integration Activities

The SAIP test environment integration activities were initiated during the Architecture Hardware/Software Codesign cycle using the SAIP system emulator and ATM interface cards provided by MIT/LL. The HighClass prototype hardware assembly and integration was initiated early in the second half the Architecture Codesign cycle and completed during the Detailed Design, Integration and Test cycle. The following paragraphs describe the implementation of the BM4 test environment and integration of the final SAIP HighClass prototype hardware.

Installation and Integration of the SAIP HighClass Test Environment

MIT-LL provided an integrated SAIP testbench that emulated the SAIP ACTD system and HighClass processor using SUN workstations. The testbench software included all of the functions to emulate the SAIP system interfaces with the HighClass processor and served as a reference for the final BM4 system integration. The software consisted of five Unix processes. Three processes (tsDispatch, imageSrvr0, and partner) emulated the SAIP system and two processes (highClass and candidate0) executed the HighClass image processing functions.

The SAIP emulator was installed and tested in two steps. First all five processes were installed and verified on a single workstation using UNIX sockets as the inter-processor data communication mechanism. Following this initial verification, the SunATM - 155 SBus ATM adapters, provided by MIT/LL, were installed in two workstations to checkout the ATM interface. The ATM link setup was straightforward. The emulator software was divided and installed on the SAIP system emulator workstation and a BM4 HighClass prototype emulator workstation. Once the SAIP emulation/HighClass code was installed on the two workstations we were able to quickly duplicate the MIT-LL SAIP emulation. This second installation verified the ATM communication link and established the integration environment for the final BM4 system.

Figure 2 SAIP Emulator Hardware/Software Interfaces

3.0 SAIP HighClass Prototype Hardware Development, Integration and Test

The final prototype hardware configuration was defined by the COTS boards selected during the Architecture Hardware/Software Codesign cycle. During this cycle, two efforts were established to selects the hardware implement the SAIP HighClass prototype. One effort was directed at selecting the basic chassis, a single board computer (SBC) control processor, the ATM network interface card, a hard disk drive and peripheral hardware needed to support the BM4 prototype integration. The second effort was associated with identifying and selecting the COTS DSP boards that would perform the HDI and MSE image processing functions.

Selection of the basic BM4 chassis and control processor components was reasonably straightforward. A standard VME chassis produced by Electronic Solutions was chosen to house the prototype system. The chassis selected provided 20 VME board slots along with two peripheral bays and a standard 500 watt power supply. The SBC selected as the HighClass control processor was a VME 6U FORCE Computers, Inc. CPU-8VT/64 170 MHz TurboSPARC-II. It contained 64 MB of DRAM for storing of the SAIP system message data and HighClass processing results. The SBC had two SBus ports, one was occupied by a standard SBus video adapter daughter card and the other contained the FORE Model SBA - 200E/OC3SC ATM adapter. In addition to the chassis, SBC and ATM adapter, a hard disk drive, monitor, keyboard and mouse were needed to support the BM4 system development and integration effort. Once these basic components of the BM4 prototype were identified a purchase order was placed to acquire them.

As part of the HDI Functional Analysis Optimization and Implementation Tradeoffs, the candidate COTS DSP boards were evaluated based on the memory, vector processing function library, and communication bandwidth requirements for the HDI and MSE image processing functions. The results of these tradeoff activities was the selection of the Analog Device ADSP - 21060 (Sharc) as the basic DSP based on its optimized vector processing capabilities. These design studies also verified the HDI and MSE processing requirements could be met using the Sharc's 500 Kbyte on chip memory and built-in Sharc link communication ports.

Based on the selection of the Sharc DSP, a comparison was made of the available COTS Sharc boards. The three candidate Sharc DSP boards evaluated were the Mercury Computer Systems Inc. MCH6, Ixthos, Inc. IXZ8 SBC, and Alex Computer Systems, Inc. SHARC6222 - 16. A summary comparison of the candidate DSP board characteristics versus the BM4 requirements is provided table 1.

  Requirement Mercury Sharc Board Ixthos Sharc Board Alex Sharc Board
Processors per Board Approx 66 Sharcs to meet SAIP Rqmts 12 8 18
Communication Network High Speed Network
not Required
Raceway Network Sharc Link Network Sharc Link Network
External Board
Memory Rqmts
Approx 3.2 MB for LRC
and HRC templates
64 MB 16 MB 16 MB
External Sharc
Memory Rqmts
None required 5.33 MB 128 KB None
Cost per Board N/A 1.5x 2.1x 1x
Cost per Sharc N/A 2.3x 4.7x 1x
Total Hardware Cost N/A 2.3x 4.7x 1x

Table 1 Comparison of Candidate Sharc Boards versus BM4 Requirements

Along with the technical and economic evaluation, a comparison of the built-in testing provisions was conducted to determine if any strong differences existed in this area. In general, it was found that all of the COTS boards are tested extensively by the vendors using specialized testing routines and that the test routines can be invoked by user command. As a result, all candidates were considered equivalent from the testability point of view.

The Ixthos board candidate was quickly rejected, based on the limited number of Sharcs per board and high costs. The Mercury boards had been used extensively at ATL and a high level of comfort for their use existed. However the Mercury board included an unnecessary Raceway network interface and external Sharc memory that added both cost and complexity to the board. The final selection was the Alex Computer Systems SHARC6222 - 16 boards based on their ability to meet the BM4 requirements and significant cost advantage. Based on this selection, an order was placed for four SHARC6222 - 16 processor motherboards and eight PAC82 octal SHARCPACs with 8 Sharcs each.

Benchmark 4 Prototype Hardware Installation and Checkout

Once the BM4 prototype hardware was received, installation and checkout of the individual components was initiated.

Figure 3 BM4 HighClass Prototype Hardware Configuration

First the SBC was installed in the VME chassis. Two slots were required to accommodate the SBus video and ATM daughtercards. The ATM connections were made using the FORE ATM interface and a the Sun ATM board installed in the SAIP emulator workstation. The major effort in this area was matching the configuration setup of the two different adapters to complete the link. Physical installation of the SBC and ATM interface was followed by loading of the UNIX (Solaris version 2.5) operating system on the local disk drive, making the SBC the equivalent of a SPARC 5 workstation.

Performance of the SBC board was verified by performing typical local and remote UNIX operations on the SBC. Then the ATM card was configured and the fiber optic communication link with the SAIP emulator workstation was verified. Successful verification of the ATM communication was followed by execution of the two workstation version of the SAIP emulator software with the SBC executing the HighClass and candidate0 emulation functions while the SAIP emulation processes (tsDispatch, imageSrvr0, and partner) were executed on the Sun ULTRA SPARC 1 workstation.

Once the BM4 control processor and ATM interface boards were installed and checked out, the four Alex SHARC6224 - 16 boards were installed in the VME chassis. The chassis backplane was specially modified to handle the higher current draw of the Alec 18 processor boards by adding extra +5 volt and ground wires to the VME P2 connector. It was estimated that each board could draw up to 14 amperes (70 watts maximum) when operating at full processing capability.

The Alex boards required configuration by assignment of a VME address to each addressable board or collection of boards. The initial installation used three separate VME addresses/partitions to support independent HDI, MSE and top level DFG development efforts. Two of the boards were setup and configured to allow testing of the top level HighClass DFG using 36 Sharc processors. Two one board (18 processor) partitions were also setup to allow independent development of the final HDI and MSE DFGs. In the case of the two board partition, one board received a VME address and functioned as a master while the other was set to the slave mode allowing inter-processor communication only through the Sharc links. The slave was not VME addressable and was connected to the master board using a Sharclink jumper that connected the link ports of the motherboard root Sharcs. Master/slave mode assignment and VME address assignment are selectable by switches on the Alex motherboards.

Alex board operation depends heavily on the APEX-Lite software provided by Alex to allocate test or application code across the 18 processors. APEX-Lite is a parallel development environment for a Sharc multiprocessor array. The version installed was release 2.1 for a FORCE VME host running Solaris V2.5. The software was installed in a dedicated directory and added to the machine path to provide access to the parallelizing functions. The "worm21k" built in test program, one of the utilities included with APEX-Lite, was used to test proper operation on the Sharc boards immediately after software installation. The "worm21k" program displays the results of testing the interconnection of all the processors as well as the memory distributed throughout the network. The configuration of the three processing subsystems was validated using the Alex worm21k utility. Execution of the command worm21k verified configuration of Sharc processors for each partition.

Along with the Alex APEX-Lite software the Analog Devices SHARC compiler, linker, and loader software Version 3.3 was also installed. The loader provided by ADI in Version 3.3 turned out to be non-functional and ADI instructed ATL to use the version 2.1 of the loader.

Once all of the SBC and Alex DSP board hardware and software was installed and check out the system was made available to the software development team for the final development, integration and test of the HighClass, HDI and MSE DFG software.

Acceptance Test Plan/Software Development

The final BM4 prototype hardware integration effort was the development of the BM4 Acceptance Test Plan (ATP) and acceptance test software. Significant effort was dedicated to developing an effective test plan. The test plan outline supplied in the MIT-LL RASSP Benchmark 4 Acceptance Test Description was used as the starting point for the ATP. This document was reviewed and modified as needed to ensure that the capabilities of the BM4 system could be measured to demonstrate conformance to the requirements. Modifications were reviewed with MIT-LL and government personnel to ensure that the test plan satisfied the intent of the government.

The test plan consisted of a descriptive document (the Benchmark 4 Acceptance Test Description) and a test record (the Benchmark 4 Test Record) to be used during execution of the acceptance test. The description defined the intent of the tests and the procedures to be used during testing. The test record is used to document results of specific tests as they are performed during the final acceptance test.

To support the BM4 acceptance testing, software and test scripts were developed to automate the individual test procedures. The basic BM4 acceptance test software consisted of variants of the MIT/LL SAIP emulator software. The tsDispatch function was modified to command the BM4 prototype to perform specific HighClass image chips processing sequences required by the Acceptance Test Plan. Individual test programs were written to test:

  1. the image chip processing classification results and scores
  2. the visual quality of the HDI enhanced image chips
  3. the SAIP system control modes, and
  4. the final image chip processing rates.
The imageSrvr0 emulator software was also modified to provide the specific image chip data sequences for each of the individual tests. Finally, the SAIP emulator partner function was modified to format and store the processing results for review and analysis by the government acceptance test review committee. All of the individual acceptance test procedures and software elements were developed and tested using the SAIP and HighClass emulator software to verify their performance. Once the final HighClass software development and integration was completed, the BM4 Acceptance Test Plan and software was used to demonstrate the BM4 prototype system performance. A summary of the BM4 acceptance performance is provided in the
Final System Hardware/Software Integration and Test section of the case study.

Approved for Public Release; Distribution Unlimited Bill Ealy