Today’s climate of rapidly evolving asymmetric threats is forcing the U.S. military to quickly adapt in order to maintain tactical situational awareness. However, the traditional dependence on custom, stove-piped digital signal processing (DSP) system implementations consisting of application-specific integrated circuits (ASICs) and application-specific standard products (ASSP) is restricting the agility of U.S. military intelligence, surveillance and reconnaissance (ISR) operations.

To address these limitations and volatile threats, the Department of Defense (DoD) is increasingly funding ISR Quick Reaction Capabilities (QRC). However, this new acquisition model challenges tactical ISR system developers to rapidly prototype cost-effective, high-performance DSP systems, while meeting stringent size, weight and power (SWAP) program requirements. 

The ISR Collection-Analysis Gap 

Over the past few years, the increased demand for ISR capabilities has led to an exponential increase in data collection capacity that shows no signs of slowing in the foreseeable future. However, ISR data processing, exploitation and dissemination (PED) capabilities have only improved linearly over the same period, leaving a critical gap between collection and analysis capabilities as shown in Figure 1. To close the collection-analysis gap, the DoD needs high-performance DSP-based ISR systems. These systems enable automated, real-time processing of massive amounts of data and the dissemination of actionable intelligence directly to the warfighter in the field.

High-end ISR applications such as real-time, automated PED push the limits of state-of-the-art DSP technology. Throughput requirements may exceed tens of tera-ops/s. New many-core graphics processing unit (GPU) and general-purpose processor (GPP) architectures are theoretically capable of satisfying high-end performance requirements. It is, however, extremely difficult to develop parallel software algorithms to fully exploit more than only a fraction of the peak performance of many-core architectures.

Many Challenges

The rapid prototyping of cost-effective system implementations that meet extreme performance requirements under severe SWAP constraints is a monumental task. Detailed trade-off analysis and extensive architectural exploration during the architecture selection and partitioning stage is critical to accomplishing this goal. Hardware resource slack margins must be optimized to provide maximum performance while minimizing software development cost. Table 1 shows a comparison of many-core GPU, multi/many-core GPP, multicore DSP and field-programmable gate array (FPGA) with respect to processor-specific software tool availability, processor peak throughput and power efficiency. 

Most current ISR systems follow the “waterfall” development method, which dictates a sequential process. The waterfall-type design processes for high-performance ISR systems impose a number of limitations, including: limited architectural exploration; lengthy prototyping times; high cost of design; lack of systematic hardware/software reuse; in-cycle hardware fabrication and testing. 

Most design automation activities leverage tool support for detailed system behavioral design, as opposed to early architecture design where much of the system cost is committed. Current industrial practice predominately relies upon designer experience to select system architectures and allocate algorithm functionality. Furthermore, for fully customized ISR systems, hardware and software subsystems are not integrated until after hardware is fabricated, making design errors very costly. 

COTS-based Rapid Prototyping

The increased frequency of ISR system development cost overruns and schedule delays has compelled the DoD acquisition community to investigate more effective solutions. The DoD has launched numerous initiatives encouraging contractors to better leverage commercially available DSP hardware boards and system components. 

In commercial hardware-based systems, the time and cost of software development can dominate the schedule and budget. One innovative solution garnering attention in the industry is a rapid prototyping methodology. The methodology exploits the use of commercial hardware/software signal processing technologies and software cost modeling, achieving significant reductions in total ISR system cost and development time. 

This approach leverages a library-based optimization framework that trades off throughput, hardware/software development costs and schedule, procurement costs and SWAP. The rapid prototyping methodology maximizes system architectural exploration at the front-end of the design process. The resulting solutions are cost-effective DSP embedded systems that exploit the flexibility of many-core GPU, multi/many-core GPP, multicore DSP and/or FPGA technologies, while satisfying stringent SWAP constraints dictated by mission objectives.

Figure 2 illustrates this rapid DSP system prototyping methodology. The process starts by translating written system requirements into executable requirements and specifications. This is achieved with signal processing libraries and integrated graphical user interface (GUI) toolkits, such as those available in MATLAB. The executable requirements and specifications provide an early prototype, allowing the customer to validate original requirements and remove ambiguities. The feedback captures any requirement alterations as early as possible, which is critical to minimizing the high cost of requirements creep, one of the most common risks in software projects. 

Focus on Costs

After the validation of system requirements, system-level cost parameters, application requirements and performance statistics, these components feed the architecture selection and partitioning optimization process. System developers can use parametric cost models, such as COCOMO II, to drive the architecture trade-off analysis, producing hardware/software architectural candidates that minimize total system cost and development time.

Cost parameters include: software cost driver attributes (size, product, platform, personnel, project), hardware procurement costs, product deployment deadlines, schedule constraints, and labor costs and constraints. Application requirements include SWaP, environmental, precedence and real-time constraints, as well as functional, memory and communication requirements. Performance statistics consist of benchmark time measurements of DSP primitives (such as the fast Fourier transform) executing on the DSP processor boards (for instance, many-core GPU, multi/many-core GPP, multicore DSP, FPGA) contained in the reuse library.

System developers can simulate the resulting architectural candidates using dynamic performance modeling tools to verify that an architecture meets system-level requirements. After performance modeling, the system architect feeds communication overhead parameters such as communication queuing delays and bottlenecks back to the architecture selection stage for refinement. The methodology produces new architecture candidates with the updated model parameters and repeats the process until the architecture meets performance requirements, no longer changing between successive iterations. 

The refined hardware/software architectural candidate moves on to the detailed architecture design stage for detailed software and/or firmware design, hardware/software interface design and commercial hardware technology procurement. Depending on the DSP hardware platform and architecture selected, the DSP software and/or firmware design process heavily leverages reusable libraries developed in previous projects. The cost of assessing, selecting, assimilating and modifying the reusable component must also be minimized to significantly reduce software development cost and time. 

System designers can refine the candidate architecture’s Simulink performance model and high-level MATLAB algorithms into Embedded MATLAB code to permit automatic code generation into the C programming language or a hardware description language. To enable the use of automated code generation tools, sufficient hardware resource slack margins and high-level software tool support must exist for the target DSP board architecture. 

The high-level virtual prototypes of the system developed in MATLAB and Simulink allow the system designer to catch hardware/software integration errors early in the design process. This approach allows for low-level performance limitations to be identified and corrected before costly hardware packaging assembly and field testing. 

Case Study: Synthetic Aperture Radar Processor

Synthetic Aperture Radar (SAR) is an important tool for the collection of high-resolution, all-weather image data and is applicable to tactical ISR systems. In addition, SAR can identify man-made objects on the ground or in the air. Such object identification typically requires real-time processing by means of a high-performance, embedded signal processor. Most SAR image and product formation algorithm steps are independent and separable, making them good candidates for parallel computation on multi/many-core processing platforms.

This case study considers the design of an SAR processor that must form high-resolution images in real time on board an aircraft. The algorithm’s three principal stages are video-to-baseband IQ conversion, range processing and azimuth compression processing. Each SAR data pulse consisting of 8,192 data real video samples is converted to complex samples at baseband. Range processing transforms each complex SAR data pulse into a compressed range pulse consisting of 4096 complex samples. Then, azimuth compression, using cross-range convolution filtering, places compressed range pulses in time sequence into a 2D (4096 x 2,048) processing array and convolves each row of the array with a row-specific reference kernel. The convolution outputs are saved in an image array, which becomes the output strip-map image of the SAR.

The SAR processing system then applies ISR specific processing to the output strip-map image including auto-focusing, polarimetric whitening filtering and target detection processing. Autofocus algorithms improve image focus by removing phase errors present after conventional motion compensation. Polarimetric whitening filters improve SAR radiation resolution by reducing image speckle after auto-focusing. Automatic target detection techniques then process the enhanced SAR images, identifying time-sensitive ISR targets in real-time. 

ISR-Specific Processing

At its maximum Pulse Repetition Frequency (PRF) of 4,535 Hz, the radar delivers 1,024 pulses with 8,192 data samples for each of the four polarizations in 226 milliseconds. The processor must form a 1,024-pulse image for each of four polarizations in real time with a latency not greater than two seconds. Given a maximum PRF of 4,535 Hz for the radar, the real-time constraint on video-to-based IQ conversion and range-processing tasks is 221 microseconds, and the real-time constraint on the azimuth processing and ISR specific processing tasks is 226 milliseconds. The computational requirement of the algorithm is about 85 Gflop/s. The memory requirement is approximately 3.4 Gbytes.

Table 2 provides a SAR processor implementation comparison of many-core GPU, multi/many-core GPP and multicore DSP technologies. Each SAR processor platform implementation is compared with respect to hardware procurement cost and software development cost and time. The comparison is restricted to single board processor implementations that can satisfy the real-time algorithm computational requirements, while minimizing SWAP. To minimize SAR processor development and lifecycle costs, which have traditionally been prohibitively expensive for FPGA and ASIC implementations, software-only solutions are highlighted in this comparison. 

The COCOMO II software cost model was used to compute the software development cost and time estimates. Table 1 provides software tool usage effort multiplier values for the selected processor architectures. Table 2 includes software size estimates and execution time effort multipliers for each processor. For simplicity, all other software cost drivers are rated as nominal. The SAR case study comparison illustrates the impact that software tool support, DSP software library support and hardware platform constraints have on software development cost and time for high-performance ISR applications. 

Table 1
System developers must optimally trade off the maturity of software tool support with hardware performance and power efficiency to meet high-end ISR application requirements.

Table 2
The SAR processor case study illustrates the impact that software size, COTS DSP software library support, processor-specific software tool support, and processor throughput constraints have on software development cost and time.

Real-Time Intelligence Analysis

Traditional DSP implementations for ISR systems can no longer keep pace with today’s rapidly evolving threats. IvySys Technologies’ Real-Time Intelligence Analysis methodology fully leverages this rapid prototyping methodology to help the DoD and Intelligence Community detect and thwart continuously evolving threats and maintain tactical situational awareness. We automate the architecture selection and partitioning by incorporating software cost and development time models into a design optimization framework. This optimization approach exploits hidden efficiencies such as the front-end design process, which is typically less than 10 percent of the total prototyping time and cost, but accounts for more than 80 percent of the system’s lifecycle cost. In turn, it reduces development time and cost by as much as a factor of four.  

IvySys
Arlington, VA.
(703-) 414-5665.
[www.ivysys.com].