Feature Archives | Feedback

Evaluating Alternative Hardware/Software Architectures for the JSF Common Avionics Platform using Omniview Cosmos

Todd Steeves, Research Scientist, Honeywell Corporate Technology Center and Charles Buenzli, Senior Vice President, Omniview, Inc.

This is a hypertext document. Readthe section abstracts below and link to the sections you findmost interesting.

Introduction
This article describes the challenges in performance modeling of processing elements for the Joint Strike Fighter and how Omniview Cosmos was used to meet those challenges.

Selecting processing elements and mapping software tasks
The magnitude of the design effort to meet the goals of selecting the optimum set of processing elements and mapping the software tasks is enormous.

Spiral modeling
In the spiral model, simple models consisting of a latency and data-dependent throughput term may be used to get a first cut at the system performance.

The Hot Spot Analyzer
The Hot Spot Analyzer uses a pseudo temperature scale to color the blocks in the hardware architecture to show how a performance metric, such as utilization, varies over time.

Co-simulation of VHDL behavioral models with performance models
It is possible to co-simulate VHDL behavioral models with the performance models to validate the detailed design process

Introduction

(Back to top)

The architecture of the Joint Strike Fighter (JSF, formerly JAST) is a radical departure from the classical approach for military aircraft. Instead of many individual chassis performing a single function, such as navigation, the JSF architecture has a single chassis with 70 to 100 processing elements on a high-speed backplane. Approximately 120 software tasks distributed across these processing elements perform the required functions, e.g., threat analysis, navigation, and graphics display. Maintainability goals and economy of scale dictated that a small set of processing elements, ideally only four or five, be selected from the vast assortment of general-purpose processors, digital signal processors, and ASIC implementations of special functions such as FFTs. Since this Common Avionics Platform Integrated Core Processor (ICP) architecture is a significant departure from current practice, performance models of alternative hardware/software architectures for the ICP were developed early in the design process by the Honeywell Technology Center to determine the smallest optimum set of processing elements and the optimum mapping of the software tasks to processors, and to ensure that all task latency and deadline requirements are met.

Since the development of the ICP is a large, multi-vendor, multi-year effort, it was critical to select a performance-modeling methodology that supports sharing of libraries, models, and data among the JSF participants, and that transcends different stages of the design. In addition, the ICP performance models would become part of design documentation to be used over the life of the JSF, which could easily exceed 20 years, to support upgrades and modifications. Therefore, the performance-modeling methodology must be based upon well-accepted industry standards and must have a life span equal to that of the JSF. To meet these requirements, the performance-modeling team, consisting of Honeywell, Texas Instruments, TRW, and Litton, selected a methodology based upon the VHDL Performance Modeling Library (PML) developed by Honeywell under the DARPA RASSP program and commercialized by Omniview, Inc. in its Omniview Cosmos (formerly called PMW) product.

Selecting processing elements and mapping software tasks
(Back to top)

The magnitude of the design effort to meet just the first two goals of selecting the optimum set of processing elements and mapping the software tasks is enormous. For the first goal, consider the large number of possible design combinations necessary to optimally select implementation for 120 different functions from a set of five possible processing choices. This set of processing types includes RISC, two digital signal processor types, programmable ASIC (PASIC) and ASIC. To satisfy the second goal, all these functions must be optimally mapped onto the actual set of available processors, which usually will include several different processor types. These steps, put together, will yield a massive number of possible combinations. Evaluating all these alternative architectures would be prohibitive, so Honeywell developed a genetic algorithm-based design-synthesis capability to develop and select candidate architectures to be modeled, and to evaluate their performance by Omniview Cosmos.

Hardware and software architectures are normally captured graphically in Omniview Cosmos using build-in editors and elements from the Omniview Cosmos library. This library contains generic, parameterized VHDL performance models of processors, memories, communications elements, input and output devices, and software that can be characterized to eliminate the need to write custom models. A unique feature of Omniview Cosmos is that it allows early analysis of both the hardware and software architectures. A Mapping Editor performs the assignment of software tasks to processing elements, making it easy to evaluate different hardware/software mappings. Importing architectures and mappings from upstream tools is also supported by Omniview Cosmos, and this is the route that was taken by Honeywell.

Spiral modeling
(Back to top)

One of the important features of Omniview Cosmos is its support for the spiral model of incremental refinement. In the spiral model, simple models consisting of a latency and data-dependent throughput term may be used to get a first cut at the system performance. As the design is refined, more detailed models are substituted where necessary to get more accurate predictions of performance. At the most detailed level, "fine-grained" models find problems other performance analysis tools overlook, such as bus contention on a local processor bus. Honeywell took extensive advantage of the spiral model and the fine-grain processor models in their evaluation of processing-element alternatives.

The processor model is a good example of the depth of modeling that is possible with Omniview Cosmos. The processor model is broken down into seven sub-models shown as blocks in the upper half of Figure 1. The parameters that model instruction execution are shown in the lower half of Figure 1. For example, the FLSIN instruction on the SHARC processor requires 38 cycles to execute, uses the standard SHARC memory access, and has the standard SHARC interrupt behavior. Figure 2. shows the same processor model with the model parameters for the on-chip memories in the lower section. Up to three on-chip memories and three on-chip cache memories may be modeled. The access time is modeled independently for read, write, and read/write operations. By filling in these forms with information found in a processor's data sheet, a user can generate a VHDL performance model of any processor automatically and even model a hypothetical processor if needed.

Software in Omniview Cosmos may be modeled at three levels of fidelity, paralleling that of the hardware models. First, the most abstract level is a fixed overhead plus a data-dependent term. These parameters may be determined by measuring the task-execution times on an actual system, or by estimation. This level of modeling is often used at the early stages of a design.

Second, a more detailed model can be created by counting instructions by type and modeling the latency and throughput of each instruction. At this level, the impact of inter-task communications, I/O operations, and high-level flow control may be modeled. Instruction count models are the preferred level of abstraction for Omniview Cosmos software modeling since they simulate quickly and make it easy to compare processor performance.

Third, the most detailed level of software modeling is to include the actual code written in either VHDL or a subset of C. Except for very small applications or portions of an application, this level of modeling results in long simulation times. Only the first two levels of modeling were used by Honeywell to manage the complexity of the ICP model.

Omniview Cosmos automatically generates a VHDL source-level performance model of the system, which is instrumented to collect performance metrics. This model is simulated on an external VHDL simulator, and performance metrics are captured in a transcript file. This transcript is interpreted and displayed graphically by Omniview Cosmos. The analysis tool suite includes Hot Spot Analyzers, Performance Metric Analyzers, Histograms, and Activity Timelines.

The Hot Spot Analyzer
(Back to top)

The Hot Spot Analyzer uses a pseudo temperature scale to color the blocks in the hardware architecture to show how a performance metric, such as utilization, varies over time. At a glance, the designer can identify potential bottlenecks by their red color and underutilized blocks by their blue color. Once the problem is localized, detailed analysis tools, such as Performance Metric Analyzers, Histograms, and Activity Timeline Analyzers can be brought into play.

An Activity Timeline from one of the ICP candidate architectures is shown in Figure 3. In this plot, the position and length of the bar on the time scale corresponds to the starting and stopping times, and the duration of software execution on each processor. The color of the bar indicates the processor utilization. Missed task deadlines and task latency are also easily determined from the Activity Timeline.

Co-simulation of VHDL behavioral models with performance models
(Back to top)

Since the design and its performance are documented in VHDL, it is possible to co-simulate VHDL behavioral models with the performance models to validate the detailed design process. Also, these models can be rerun later in the design process to evaluate any design changes, and can be used in the future to evaluate modifications and upgrades.

Since the design and its performance are documented in VHDL, it is possible to co-simulate VHDL behavioral models with the performance models to validate the detailed design process. Also, these models can be rerun later in the design process to evaluate any design changes, and can be used in the future to evaluate modifications and upgrades.

Honeywell successfully developed architectures and VHDL performance-level models for the ICPs ranging from 70 to 100 processors executing approximately 120 software tasks, and validated their performance versus the JSF operational requirements. This virtual prototype enabled the selection of an optimal set of processing elements, and proved the feasibility of the ICP concept and its cost effectiveness.

Additional Information

Refer to http://www.omnivw.com/products/cosmos.html,
http://www.htc.honeywell.com/projects/rassp
and http://www.omnivw.com for additional information.


		Click here to get your listing up.