A Case Study in HWSW Codesign and RC

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

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

On-board High-Performance Computing Need Sensor Array Sample-Level Signal Processing Frame-Level Signal Processing High-Level Logic Operations Time Dependent Processing TDP Object Dependent Processing ODP Mission Dependent Processing MDP • 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 Telemetry DA T A RA S • On-board high-performance computing system one proposed solution – >1000 MOPS per processor node – Small form factor ~6 Ux 220 mm modules – Highly efficient >300 MOPS/Watt Alg • Satellite processing challenges and benefits m rith b A ty/ xi ple ac str m Co o TDP ODP MDP – 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 Ramos 3 n tio TE #196 MAPLD 2004

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 w Replacing small ASICs with radiation tolerant Virtex devices w Reusing adaptive systems for future projects – Reduce Cycle Time w Provides reusable module with pre-integrated programmable SEU mitigation w FPGA modules can be reused – Reduce Risk w Flexibility enables onboard-repairability and degraded mode capability w Hardware fixes and application upgrades can be made in flight via uploads – Increase Capabilities w Timesharing of hardware by varying mission applications and modes w 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 4 #196 MAPLD 2004

On-board Reconfigurable Computing 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 Honeywell accepted the RC challenge Ramos 5 #196 MAPLD 2004

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 6 #196 MAPLD 2004

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

Honeywell Reconfigurable Space Computer • 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 – – Configurable interface for prototyping via Virtex II 2000 Common and generic interface to PEs and memory PMCs provided COTS card interfaces for fast integration c. PCI standard selected as control plane interface to Configuration Manager • Network Interface • Software – Development tools and System Software pre-integrated Developing the HRSC prototype was real challenge Ramos 8 #196 MAPLD 2004

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 9 #196 MAPLD 2004

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 10 #196 MAPLD 2004

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 • c. PCI 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 11 #196 MAPLD 2004

Recipe for Success: Spiral Development Single Process Iteration Complete 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 12 #196 MAPLD 2004

Recipe for Success: Minimize NRE PMC interface User’s Design c. PCI interface Memory Inter PE 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 13 #196 MAPLD 2004

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 14 #196 MAPLD 2004

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 15 #196 MAPLD 2004

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 Ramos 16 #196 MAPLD 2004