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

A Case Study in HW/SW Codesign and
RC Project Risk Management: The
Honeywell Reconfigurable Space
Computer (HRSC)
Jeremy Ramos
Ian Troxel
Advanced Processing
Systems
Honeywell Inc.
Clearwater, FL
HCS Research
Laboratory
University of Florida
Gainesville, FL
Outline
• Introduction
• Motivation
• Project Overview
• HRSC System Design
• Project Description
• Lessons Learned
• Conclusions
Ramos
#196 MAPLD 2004
2
On-board High-Performance Computing Need
Sample-Level
Signal Processing
Frame-Level
Signal Processing
High-Level Logic
Operations
Time
Dependent
Processing
TDP
Object
Dependent
Processing
ODP
Mission
Dependent
Processing
MDP
Sensor Array
Telemetry
• 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
TDP ODP
• 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
MDP
Reconfigurable Computing (RC) ideal for payload processing
Ramos
#196 MAPLD 2004
3
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 2004
4
On-board Reconfigurable Computing Challenge
•Numerous problems to be overcome
–Rad-Hard Design Considerations
–Programming Model
–Power Issues
–Non-Recurring Engineering (NRE)
–New Technology
Less Mature
Learning Curve
Integrating With Legacy Code and Systems
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
#196 MAPLD 2004
5
Honeywell RC Project
• The goal of Honeywell’s RC effort is to produce highperformance 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 2004
6
Project Overview
• 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
Ramos
#196 MAPLD 2004
7
Honeywell Reconfigurable Space Computer
PMC
Slot A
• 2 Adaptive Processing Cells
Front Panel
Front Panel
cPCI J1,J2
cPCI_IF
– Overall architecture has numerous non-contentious data
IO
Prototyping
Interface
cPCI Local Bus
IO
Prototyping
Interface
paths and is optimized for throughput
• Configuration Manager
–
–
–
–
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
MemBus
Supports 2 PEs concurrently
Configuration memory SEU mitigation is built in
Configuration cache included
Interrupt handler
User IO
Programmable PE and interface clocks
MemBus
MemBus
MemBus
–
–
–
–
–
–
MemBus
Config.
Cache
Configuration
Manager
PE2
PE1
Virtex 1000
Virtex 1000
Configuration, User I/O, and
interrupts
MemBus
DPM
MemBus
256Kx32
• Network Interface
• Software
– Development tools and System Software pre-integrated
Developing the HRSC prototype was real challenge
Ramos
PMC
Slot B
#196 MAPLD 2004
8
MemBus
Project Timeline
2/26
Initial Specification
1/28 - 2/25
1/14 High-level System Design
Project Kickoff
2/1
3/1
5/1
Detailed Design Specification
9/14
Full Board Simulation Complete
12/13
Board Returns
12/20
11/15
Board and Apps Verified
Board Sent to Fab.
8/12
API, FPGA Cores and Demo Application Verified
4/1
5/1
6/1
7/1
8/1
9/1
10/1
11/1
1/14/2002
12/1
12/20/2002
1/14 - 1/28
Algorithm Design Trades
3/1 - 4/30
Board design, API and VHDL teams fanout
5/2 - 8/12
8/12 - 9/13
Continued Development Board-Level Simulation
9/15 - 11/14
System-Level Tests
• Accelerated project schedule
•
– From concept to working board in one year
Relatively small project team
– 3 full time engineers until February 28th
– 5 FTE (with 7 engineers) after March 1st
Many lessons learned along the way…
Ramos
#196 MAPLD 2004
9
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 2004
10
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 2004
11
Recipe for Success: Spiral Development
Unit Test
Integrate
Done
Develop
Iteration
Complete
Design
Integration
Test
Start
Start
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
#196 MAPLD 2004
12
Recipe for Success: Minimize NRE
PMC interface
User’s
Design
User’s
Design
cPCI 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
#196 MAPLD 2004
13
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 2004
14
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 2004
15
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
#196 MAPLD 2004
16