The Lockheed Martin ATL RASSP program approach to satisfying the RASSP goals is based on implementing the three technology thrusts: methodology, Model Year architecture, and infrastructure. The methodology is based on a concurrent/ collaborative approach that embraces the full hierarchy, from requirements to manufacturing product data descriptions. The Model Year Architecture focuses on the leveraging of COTS technology, coupled with designing flexible, functional interfaces to enable regular, low-cost technology upgrades. The infrastructure (Enterprise) system enables the methodology and Model Year Architecture approach across multi-discipline, concurrent-engineering teams by providing integrated workflows, data, and network services. The resulting capability is a much greater capability than the sum of its parts, enabling the concurrent/collaborative virtual corporation of the future.
At this milestone in the program we believe it would have been impossible to have made the advancements to date without leveraging the significant ongoing investments of our team members. While many of our team members are commercial vendors with their own sets of tools, the RASSP focus has been to develop standards-based processes, architectures and information standards to support reuse, design interchange, and the ability to customize instantiations of RASSP for individualized corporate use, as shown in Table 1. Because tools will have the shortest half-life on the program, one of RASSP's legacies will be the interoperability standards developed.
Contributions of these developments toward the 4X goals of the program are further described in another RASSP paper being presented at the Second Annual Conference [6]. Additionally, proliferation of these early developments is ongoing. Installation/use of RASSP methodology and tools is already being planned/adopted by key Government and Industry organizations. This includes a number of internal Lockheed Martin sites and commercial companies (TRW, Allied Signal, Honeywell, Litton Data Systems, Rockwell, and Westinghouse). Several Army installations (ARL, Ft. Monmouth and NVL, Ft. Belvoir) also plan participation.
A summary of the more detailed developments is provided in the following sections for the major portions of the Lockheed Martin program.
The RASSP Design Process starts with the System Definition Phase. The primary functions being addressed in this portion of the design process are these:
The Architecture Process transforms processing requirements into candidate architectures composed of hardware and software elements, with support for codesign and co-verification at all steps. A conceptual view of the RASSP codesign and virtual prototyping approach is shown in Figure 3. The process truly embraces a hardware/software codesign methodology by taking functional processing requirements and iteratively allocating them to hardware/software in an experimentation/verification process. The process is inseparable from the software process, sharing in generation and verification of detailed code. The architecture process results in a detailed behavioral description of the processor hardware and definition of the software required for each processor in the system.
This part of the design is done by using a hardware/software (HW/SW) codesign approach, which refers to the simultaneous consideration of hardware and software within the design process [7]. The process begins with an architecture-independent data flow graph(s) representing the signal processing. During the process of selecting an architecture, the nodes of the data flow graph(s) are allocated to hardware or software. The graph nodes allocated to software are mapped to the multiple processors in the architecture, and performance estimates are generated based on timing information associated with the processing primitives from which the graphs are constructed. Alternative hardware architectures are developed and the system is optimized using execution times estimated for the target hardware. Functional simulation is used to verify that the generated code is consistent with the functional baseline. Performance simulation provides the next level of assurance that all throughput requirements are met by using lower level models, including the operating system, scheduling, and support software characteristics [8]. Finally, hierarchical architecture verification of the architecture is established using selective performance and functional simulation at the ISA and/or Register Transfer Level (RTL) level.
In the Detailed Design process, selective performance and full functional simulation are performed again. At this point, however, the design has progressed to the point where simulation at the RTL and logic levels is most appropriate. Verification of the designs at this level is necessary prior to release to manufacturing. It is important to note that pieces of the design may be in different stages of the overall process, based on the risk analysis performed in each development cycle. For example, if it is obvious to the designers during systems analysis that they will need a new custom hardware processor to meet the requirements, they may accelerate the design of the custom processor while the overall signal processor design is still in the architecture process.
Modular Software Architecture -- A software architecture that is readily portable and upgradable because of its modularity, standardization on a required set of services. This architecture supports a new paradigm for application software generation, which promotes automated re-generation of HOL code from tar get-independent primitives instead of porting existing HOL code for processor upgrades.
During this year, the team has defined the key Model Year Architecture concepts of encapsulation, functional interfaces, and layering and is implementing and refining them through a number of ongoing experiments. The team is also finalizing baseline specifications, which include the SVI Specification, Hardware Architecture Specification, Software Architecture Element Specification, and the Model Year Architecture Reuse Element Specification. Additionally, implementation experiments, which involve writing VHDL encapsulations to implement the SVI for several processors and buses, have been performed.
Integration of the Model Year Architecture Framework into the Design Methodology and Enterprise Framework to achieve the required synergy between the elements of the technology triad is ongoing. The initial integration of the Model Year Architecture Framework based on these baseline specifications is expected by the end of 1995.
Systems -- The system definition process is a front-end engineering task, where signal processing concepts are developed and top-level tradeoffs are performed to determine the signal processing subsystem requirements. As a part of the RASSP program, the team is performing integration of multi-discipline capabilities into true concurrent engineering environment. This environment consists of three major tools:
Architecture -- A set of tools to assist the designer in partitioning and mapping a functional application onto a potentially large number of computing nodes is a major requirement for meeting RASSP's time-to-market and reuse goals. JRS's NetSyn tool is the first available tool to assist in performing HW/SW codesign for architectural trade-offs. The RASSP team is currently integrating NetSyn with tools from other disciplines to enable designers to perform concurrent engineering trade-offs. The resulting RASSP capability will be the ability to efficiently evaluate a number of varying architecture approaches for a particular application and to generate top-level size, weight, cost, reliability, and performance estimates.
Once an architecture has been selected, more detailed verification of the implementation is required, which will likely be composed at any point in time of existing hardware and software elements, existing models, and new components. What is required at this level of the design hierarchy is a robust simulation capability that allows the designer to iteratively verify the design in a hierarchical manner, as shown in Figure 5. The RASSP program is making multi-domain simulation capabilities available through the productization of the Ptolemy-based Heterogeneous Simulation Interoperability Mechanism (HSIM) by Berkeley Design Technologies. Estimates indicate that the integration cost using HSIM was reduced by a factor of 8 over traditional integration approaches. Additional cross-domain integrations performed to date include integration of HSIM to the Precedence simulation backplane, as well as integration of VHDL and emulation (QUICKTURN) environments into the backplane. During Year 3, the team will develop a graphical user interface to support efficient hierarchical simulation partitioning, invocation, and visualization. The ATL RASSP team has demonstrated flexible application mapping and code verification on multiprocessor testbeds this year using Lockheed Martin's Graphical Entry Distributed Application Environment (GEDAE).
One of the design approaches that has developed over the past year is the use of VHDL to convey design information from the initial multiprocessor system concept through synthesizable chip descriptions. The team's efforts have focused on developing a VHDL Performance model interoperability standard and object-oriented extensions to support high-level modeling. This year, the team defined a Performance Model interoperability standard and developed an example (SAR benchmark) model using this approach. Models have been distributed to several organizations (TRW, Vista, HTC, Uva, JRS, and MIT) and have demonstrated more than 100X improvement in simulation time over traditional, ISA-level approaches. Honeywell is developing readily reconfigurable, generic libraries, with initial libraries already delivered, to support rapid trade-offs.
Object-oriented extensions to VHDL to support higher levels of abstraction in model definition and to support reuse have been developed. The approach taken has been to develop an object-oriented preprocessor that results in fully compliant IEEE 1076 VHDL code. VISTA has developed and demonstrated a prototype version of this preprocessor, which is now undergoing detailed evaluations.
Software -- One of the key developments on ATL's RASSP program is the development and implementation of a library-based, data-flow-graph-driven autocode process, which abstracts signal processing software generation and maintenance to the graph level. Data flow graphs represent the required signal processing using the Processing Graph Method (PGM). This representation is totally architecture-independent. Thus, as hardware is upgraded, the application description at the graph level remains constant.
During architecture selection, the processing represented by the nodes in the graph is allocated to hardware or software using various programmable processors in the architecture. The description of the architecture, the mapping information, and the PGM graph are seamlessly passed from NetSyn to the Autocode tools. Connected groups of primitives assigned to the same processor represent graph partitions, which are automatically translated (using the MCCI-developed Autocode tools) to source code for the processor type to which the partition has been mapped. This translation uses the optimized math and signal processing libraries for the specified target processor. Along with the Autocode tools, MCCI has completed the design and is currently implementing a Run Time System to support the management and execution of the autocoded graphs on the target hardware. The Run Time System is being built with an open interface to operating system microkernels to facilitate porting to commercial products. The first integrated version of both the Autocode tools and the Run Time System will be released in 4Q95 and will support the MCOS operating system and Mercury signal processing application library (SAL). The Autocode tools and Run Time System will provide the recently initiated AN/UYS-2A upgrade program with both the ability to easily retarget PGM software to the new hardware and the ability to upgrade the hardware without modifying the software at the graph level. This effort will represent the first real application of automated code generation and run-time support targeted to commercial processors.
Hardware/Design for Test (DFT) -- Integration of DFT activities are focused on knitting together chip to system testability over the entire product life cycle from design verification and manufacturing acceptance through field support. The DFT methodology contributes to achievement of the overall RASSP goals in two ways. First, adoption of DFT practices, such as being developed and practiced within industry , results in reduced cycle time, reduced cost, improved quality, predictable schedules (including integration and test), improved time-to-market, and most importantly time-to-profit. Secondly, the structured DFT methodology provides improvement of the DFT process itself compared to current industry practice. This is achieved by the introduction of proven system engineering practices, such as the consolidation of test requirements. It is also achieved by leveraging top-down development of the overall RASSP methodology to flow-down the test strategies and architecture from the system to chip packaging levels and across life-cycle phases of the product.
The team has captured the blueprints for the process enhancements in the recently completed DFT Methodology and Testability Architecture documents. Additionally, activities to implement the process enhancements are proceeding.
The Enterprise System integration effort has made significant progress and has resulted in a concept of operations, which has been used to drive the vision of our detailed developments. The team has completed enterprise-level integration of several of the elements of the methodology, which includes implementation of the workflows into the Intergraph Design Methodology Manager integration of the tools associated with those workflows into the Desktop manager and integration of the tool's data into the RASSP Product Data Management System. The methodology/workflows for the complete hierarchy of design steps will be completed early in Year 3.
The Enterprise Data Management portion of the Enterprise System was updated with the new Intergraph DM2.0 Data Management tool (Metaphase Data Management tool). DM2.0 is the central part of the RASSP Product Data Management System, and is an Object-Oriented Data Management tool that supports the RASSP Configuration Management and Authorization Models and policies that were developed this year. The use of DM2.0 ensures that RASSP is supported by a viable commercial approach that will be distributed by a commercial supplier.
Aspect and Lockheed-Martin are developing the RASSP Reuse Design Object Classification Hierarchy for hardware, software, architecture, systems, VHDL model, and algorithm design objects. Aspect Development is working closely with ATL to standardize this hierarchy as a product of the RASSP program. The specific Reuse Data Management approach being pursued takes full advantage of Aspect's Object-Oriented Component Library System and the latest reuse tool, referred to as Explore-CIS. An example browser window is shown in Figure 7.
The RASSP Enterprise System is addressing the Design-to-Manufacturing Interface requirements. During the second year, the team has implemented an approach for interfacing the RASSP board design tool outputs through a STEP AP210 approach. The Manufacturing Interface portion of the development is also leveraging the SCRA PreAmp development toolset developed under a NIST program. The RASSP Design-to-Manufacturing approach is being implemented at the Lockheed Martin Ocala Manufacturing Facility in Florida. The design-to-manufacturing effort is looking at building a bridge between STEP and EDIF.
RASSP funding also supports extensive design tool and data integration. Tool integrations, which enable bi-directional data exchange and synchronization through the graphical user interface and in batch modes, include:
The final area being addressed in the Enterprise System is the Network Services. The ATL RASSP team member responsible for supplying Enterprise System Network Services is Enterprise Integration Technologies (EIT). The EIT group will be making a secure network server available for supporting the Design-to-Manufacturing Interface Experiment being run at the Lockheed Martin Ocala PWA shop. During the third year, the number of RASSP sites using the EIT capability will be expanded to allow demonstrating the distributed design and manufacturing approach that is being developed. This capability will be used to demonstrate the virtual corporation being developed for the RASSP program.
TRW is using the RASSP system to develop a Spread-Spectrum Preprocessor (SSPP) targeted for the requirements of the Integrated Sensor System (ISS) and Joint Advanced Strike Technology (JAST) programs [9]. Spread-spectrum processing is a key part of many communication links, including JTIDS, EPLRS, GPS, and WNA. The JAST mission is to create affordable strike warfare systems. Several of JAST's methods to achieve its goals are parallel to RASSP, such as commonality, improved practices, reduced upgrade costs, and simulation. Specific cost savings goals are 33% O&S, 64% production, and 6% R&D. TRW has developed one virtual prototype SSPP optimized for maximum COTS usage. Three more virtual prototypes are planned for this year. In 1996, TRW will add more features and build one of the virtual prototypes in end-item hardware that will be available to the ISS and JSAT program for flight tests.
The KINDLING Demonstration is a small effort to apply portions of the RASSP process to a classified application. Use of graph-based autocode generation capabilities has demonstrated almost 10X improvement in algorithm software generation for pieces of this application. The team is also working on the definition of an Executable Specification, which is being considered as a potential Government procurement approach for upcoming programs.
The use of the RASSP methodology and design tools were used to design the Benchmark 1 Virtual Prototype [10]. The Benchmark 1 experience has lead to demonstrating an approach for applying VHDL to model full computing systems that contain upwards of hundreds of processor elements. A central theme is the promotion of true hardware/software codesign through the independent specification of the software and the hardware to support the rapid exploration of various software applications and mappings on many architectural candidates. Reduction of the design cycle-time to less than a half-hour for relatively complex applications such as the Synthetic Aperture Radar (SAR) allows multiple design iterations per day .
The team completed successful architecture verification and optimization of a full SAR DSP system containing 24 cooperating processor nodes running multiple iterations of the SAR application algorithm, which span several seconds of simulated real time. The system models provide early design verification via data-flow-graph-driven simulation of software as partitioned, mapped, and executed on the hardware architecture. This verified the RASSP virtual prototyping approach by providing early design verification of software as partitioned, mapped, and executed on the hardware architecture, prior to hardware manufacture. The benchmark also demonstrated hierarchical simulation and testbench data from virtual prototype to verify RTL-level descriptions of custom boards and FPGAs.
The team also implemented the RASSP methodology and demonstrated an object-oriented approach to autocode generation of command program for SAR. Benchmark 2 demonstration will show ease in retargeting the application for a Model Year product upgrade (i860 transition to 21060).
The demonstrated capability to develop the first model year release of the system with a small perturbation in time and cost has convinced the ATL RASSP team that the virtual prototyping paradigm being pursued has fully proven its benefits. A minimum of 2X improvement in the schedule and cost, while maintaining the quality of the design, was demonstrated. The ATL Benchmark team plans to implement the Model Year 2 approach using an improved processor that will substantiate the Model Year Architecture methodology being pursued. The goal is to then show that a new set of algorithms (non-SAR application) could be easily mapped to the COTS-based architecture.
The UYS-2 program upgrades will demonstrate the benefits of the RASSP Methodology and design tools. The use of the virtual prototyping tools and automatic code generation tools coupled with new concepts, such as the ARPA Myrinet development, will demonstrate the ease of building COTS-based processors for multiple service applications with the RASSP concepts at significantly reduced cost and schedule.
In addition to demonstrating the use of RASSP concepts, the team will deploy a large number of the tools for use by the total international electronic design community. This is an exciting part of the program because it will help fund continued improvements to the tools and will allow the community to develop models and examples that can be used by the user community.
The RASSP concepts are being applied to other ARPA-Tri-Service programs. The first such program is the Afford-able Multi-Mission Manufacturing (AM3) program. The ATL RASSP team believes the RASSP enterprise concept and implementation will also have applications to many other design and manufacturing requirements.
[2] Caracciolo, G. and Pridmore, J., Reuse-Oriented Model Year Architectures for Rapid Prototyping, Second Annual RASSP Conference Proceedings, 1995.
[3] Bard, A. and Schaming, W.B., Hardware/Software Codesign in the Lockheed Martin Advanced Technology Laboratories' RASSP Program, Second Annual RASSP Conference Proceedings, 1995.
[4] Robbins, Christopher, Autocoding in the Lockheed Martin ATL RASSP Hardware/Software Codesign Process, Second Annual RASSP Conference Proceedings, 1995.
[5] Bard, A., Chadha, B., Finnie, E., Kalathil, B., Selvidge, W., Tuck, M.C., and Welsh, J., Integrated Process Control and Data Management in RASSP Enterprise Systems, Second Annual RASSP Conference Proceedings, 1995.
[6] Pridmore, J., Advanced Technology Laboratories' Path to 4X Improvements, Second Annual RASSP Conference Proceedings, 1995.
[7] Bard, A., Myers, C., and Schaming, W.B., Hardware/ Software Codesign, RASSP Working Document, 1994.
[8] Hein, C. and Nasoff, D., VHDL-Based Performance Modeling and Virtual Prototyping, Second Annual RASSP Conference Proceedings, 1995 .
[9] Kuttner, C., TRW RASSP Model Year 1 Spread Spectrum Pre-Processor, Second Annual RASSP Conference Proceedings, 1995.
[10] Jaffe, R., Kline, W., and Pridgen, J., RASSP Technology Insertion into the Synthetic Aperture Radar Image Processor Application, Second Annual RASSP Conference Proceedings, 1995.
