A Case Study in HW/SW Codesign and RC Project Risk Management: The Honeywell Reconfigurable Space Computer (HRSC) Jeremy Ramos Advanced Processing Systems Honeywell Inc. Clearwater, FL Ian Troxel HCS Research Laboratory University of Florida Gainesville, FL

Ramos #196 MAPLD Outline Introduction Motivation Project Overview HRSC System Design Project Description Lessons Learned Conclusions

Ramos #196 MAPLD Increased data requirements for space stress downlink bandwidth limits – Hyperspectral imaging and Space Based Radar – Large sensors producing data at rates on the order of 50 to 100 Gbits/s On-board high-performance computing system one proposed solution – >1000 MOPS per processor node – Small form factor ~6Ux220mm modules – Highly efficient >300MOPS/Watt Satellite processing challenges and benefits – Develop a scalable and adaptable architecture for multiple missions and processing needs – Develop tools and software to support the deployment of applications on such a system – Leverage high-performance COTS technology, including RC, to reduce NRE and time to market Reconfigurable Computing (RC) ideal for payload processing TDPODP MDP DATA RATES Algorithm Complexity/Abstraction Telemetry Time Dependent Processing TDP Object Dependent Processing ODP Mission Dependent Processing MDP Sample-Level Signal Processing Frame-Level Signal Processing High-Level Logic Operations Sensor Array On-board High-Performance Computing Need

Ramos #196 MAPLD On-board Reconfigurable Computing RC a key enabler for Honeywell’s Next Generation Payloads – For select algorithms, RC provides orders of magnitude higher efficiency (MOPS/Watt), computing capacity (MOPS), and IO bandwidth over microprocessors Key RC benefits – Potential to reduce NRE  Replacing small ASICs with radiation tolerant Virtex devices  Reusing adaptive systems for future projects – Reduce Cycle Time  Provides reusable module with pre-integrated programmable SEU mitigation  FPGA modules can be reused – Reduce Risk  Flexibility enables onboard-repairability and degraded mode capability  Hardware fixes and application upgrades can be made in flight via uploads – Increase Capabilities  Timesharing of hardware by varying mission applications and modes  Reduced size, weight, & power (fewer processors and ASICs) Key RC challenges – No common or standard architectures, runtime software, interfaces, etc. – No hardware available for space – Design methodologies not as mature as microprocessors Many challenges must be overcome to take RC to space

Ramos #196 MAPLD On-board Reconfigurable Computing Challenge Honeywell accepted the RC challenge Numerous problems to be overcome –Rad-Hard Design Considerations –Programming Model –Power Issues –Non-Recurring Engineering (NRE) –New Technology u Less Mature u Learning Curve u Integrating With Legacy Code and Systems u Fear of Change –Cost Effectiveness of Technology Only Demonstrated on Selected High-End Projects –Potential for High Degree of Project Risk –Need a Proof of Concept System and Algorithm

Ramos #196 MAPLD Honeywell RC Project The goal of Honeywell’s RC effort is to produce high- performance reconfigurable computers for onboard processing – Develop a proof-of-concept RC board for space imaging applications with a path to flight – Provide a path to integration with other common satellite boards, backplanes and services – Keep costs minimal – Incorporate maximum flexibility and performance – Build a framework and strategy for minimizing problems RC flexibility creates for future applications – Reduce total project risk and cost by designing hardware and software components with a mind for reuse and in a priority order The RC system is targeted to support front-end and back-end digital signal processing needs for advanced space-borne processing programs like SBR, TCS, NPOESS, and several NASA missions. – Architectures optimized for space applications – Use COTS Xilinx FPGAs to reduce cost with built in SEU mitigation – Development tools and System Software pre-integrated The development of a prototype was identified as the first objective

Ramos #196 MAPLD Your mission, should you choose to accept… – Project parameters (thou shalt…)  Produce prototype board with path to flight in one year  Board must interoperate with current product line  Contain no less than two FPGAs  Provide processing flexibility within and between boards  Support several example applications (e.g. imaging, compression) at full data size and rate specification  Fit within a cPCI 6U form factor  Provide for future radiation tolerance and mitigation  Consume less than 40 Watts per board Project Overview

Ramos #196 MAPLD Honeywell Reconfigurable Space Computer Developing the HRSC prototype was real challenge 2 Adaptive Processing Cells – Overall architecture has numerous non-contentious data paths and is optimized for throughput Configuration Manager – Supports 2 PEs concurrently – Configuration memory SEU mitigation is built in – Configuration cache included – Interrupt handler – User IO – Programmable PE and interface clocks Network Interface – Configurable interface for prototyping via Virtex II 2000 – Common and generic interface to PEs and memory – PMCs provided COTS card interfaces for fast integration – cPCI standard selected as control plane interface to Configuration Manager Software – Development tools and System Software pre-integrated

Ramos #196 MAPLD Project Timeline Accelerated project schedule – From concept to working board in one year Relatively small project team – 3 full time engineers until February 28 th – 5 FTE (with 7 engineers) after March 1 st Many lessons learned along the way…

Ramos #196 MAPLD Recipe for Success Project savings Cost in raw $ and time saved in development and testing by hw/sw codesign to catch integration bugs early in the process Reduction in overall project risk by following a priority-based spiral development process Large reduction in Non-Recurring Engineering for the RC design by creating standard interfaces and APIs upon which all applications are built (creates a measure of stability in a highly flexible design space to reduce custom work) Kept design process streamlined with a small design team and light documentation by fixing interface specifications so future projects can focus on application development

Ramos #196 MAPLD Recipe for Success: HW/SW Codesign Didn’t wait for board to develop, test and verify hardware interfaces, VHDL, API software and applications FPGA and board design in simulation provided a testbench for API, application and control VHDL/C –Modelsim development environment –PCI flex models from Synopsis increased productivity –Integration testing made simple cPCI chassis and an Alpha-Data ADM-XRC FPGA board created an emulation environment to further test the API Low-level testing fully selectable between simulation, emulation and real board when prototyping applications

Ramos #196 MAPLD Recipe for Success: Spiral Development Single Process IterationComplete Process Diagram Spiral development process reduces risk – Coding requirements organized in order of priority – Iterations move design closer to the final system as functionality is added in order of priority – Iterations (after the first one) move system from a working design to another working design – Each step within subsequent process iterations tend to take less time as experience gained – When process complete, system is fully integrated and tested – Gives project manager simple way to assess reduction in project risk and increase in project functionality over time – Valuable tool to for performing risk-return and cost-benefit analysis

Ramos #196 MAPLD Recipe for Success: Minimize NRE Memory Inter PE PMC interface cPCI interface User’s Design User’s Design Standard interfaces Minimizing NRE reduces RC project risk (especially future projects) – Standard interfaces between all components reduces future development effort (tradeoff flexibility for ease of development) – Future users can concentrate on their design – Test and demo application development paralleled code development to identify features future users will need – Incorporated future user’s needs early in process by acting as our own customer

Ramos #196 MAPLD Recipe for Success: Project Team Cooperative team environment – Small, flexible design team – High degree of interaction – Clear vision and motivation Streamlined documentation process – Documentation kept to a minimum – Application developers needs drove the process – Focused on application notes rather than traditional specifications

Ramos #196 MAPLD Successful Project Outcome Board produced within budget and on time Board running and passed test within 2 days API and board support code all worked on first boot Demo app. running in 3 weeks (delay due to board production problems from outside manufacturer) FPGA interfaces developed for future projects Simulation / Emulation / Prototype environments developed and synchronized for future applications

Ramos #196 MAPLD Conclusions Developed prototype, proof-of-concept RC board for space imaging applications with a path to flight Project completed within budget, time and performance constraints Expanded RC development knowledge base through lessons learned Created framework and strategy for minimizing RC flexibility and project risk for future applications Several future projects are including the board in their designs