The Second Workshop on...
Fault-Tolerant Spaceborne Computing Employing New Technologies, 2009

This is a working group on IP for space applications. ("IP" is used here as a special term of art referring specifically to chip layout macros for ASICs and logic for FPGAs written in a hardware description languages.) The thesis of the working group is that the industry produces specialized IP either in because of its space-relevant function (e. g. SAR beamforming) or because of accommodation to the space environment (radiation hard, fault tolerant). The industry would benefit by the ability to use and reuse this IP for multiple applications. This requires such activities as organizing the industry's inventory of IP so potential users can know what is available and also constructing the IP with common interfaces so that IP designed for different purposes can be combined without a large amount of custom interface circuitry and redesign.

This group will recognize that IP for FPGAs and ASICs follow the same general principles but is usually incompatible in specific instances.

This group is seeking to have discussion leading to some initial steps. The group is not expecting to produce a comprehensive architecture, but may instead produce recommendations of incremental, voluntary steps that would tend to improve efficiency or enable more sophisticated missions.

1. ISHM (Integrated Systems Health and Management) - hardware and lower level software focus (definition of lower level software focus: identification and reporting of errors up to the component level, component being processor, I/O channel, memory, ...)
   • Modes of system failure
     • Hard (radiation total dose, thermal, total component failure)
     • Soft (e.g., SEU, noise)
   • System level fault tolerance system mitigation methods:
     • Diagnostics (design & execution)
     • Prognostics (design & execution)
     • State based designs (design)
     • Operational methods (design & executional)
2. Hardware fault-tolerance advances:
   • Discussion of experiments in sending COTS directly to space
   • RHBD update
   • RHBP update
   • Alternatives to TMR - options and status
   • Prospects for fault tolerant (rad hard) storage - update
   • Fault tolerance for faster interconnects - could include advances plus any updates from commercial lessons learned (such as separation of traffic types, protocols, etc)
3. Calculating reliability with new methods, new technology:
   • Traditional calculations force traditional methods of fault tolerance
   • What can the group do (collectively) to ensure alternate calculations are vetted and accepted so that new technology and approaches can be used on upcoming acquisitions?
4. Possible Standards for Fault Tolerance/Fault Management (?):
   • Software service layers
   • Common frameworks and libraries for reuse
   • Operating system enhancements
   • Redundant memory systems / architechures (e.g., PIM)

1. ISHM (Integrated Systems Health and Management) - architecture and higher level software focus (definition of higher level software focus - component reports errors, what to do about them, detecting and doing something about performance anomalies though no errors have been reported, software architecture for ISHM, planning for dynamic "plug and play" of both H/W and S/W components).
   • Diagnostics
   • Prognostics
   • State based designs
   • Operational methods
2. Software architecture and fault tolerance: the role of the operating system in the multcore age
   • Traditionally a real time OS has been required to guarantee predictable behavior
   • Does multicore change that paradigm?
   • In general, from a systems perspective, what resources need to be assured and how if the goal is predictable system behavior
   • What about separation of control and data plane (also called mission control vs mission science)?
3. Software architecture and multi-mission surge:
   • Methods to separate and bound different missions using multi-core
   • Methods to accommodate surges and restore to "normal" state taking advantage of multicore options, these could include (but are not limited to):
     • Partial reconfiguration of FPGAs
     • Changes in programs on multicore
     • Changes in partitions on multicore
     • Activating idles cores and then re-snoozing them
     • Operating system support
4. Security as a fault tolerance component
5. Techniques for managing software complexity and simplifying V&V
   • multi-core ARINC for isolating and simplifying resource management
   • combining system engineering and software engineering principles
6. Inter Government software standards for enhancing reuse for spacebone multicore software, e.g., common:
   • Fault protection avionics functions (including ISHM)
   • Basic power management
   • Telecom
   • Resource management

There is a memory technology working group organizing as this schedule is being put together. The organizers are Rich Murphy, Sandia, Jeff Draper, ISI, Rafi Some, JPL, Andrew Keys, NASA, Larry Bergman, JPL.

The topics being discussed (via extraction of emails) are:

• Ground vs. Space requirements for DRAM
• Non-volatile memory (the usual suspects)
• Potential integration possibilities -- 3D integration, Quilt
• Packaging, other advanced packaging
• Improving radiation tolerance for commodity components
• Perhaps a topic of technology scaling effects on radiation responses of memories would be good. For instance, in our 90nm testing we found that a single strike could upset as many as 13 physically adjacent SRAM bits. That number will grow as SRAM cells shrink in size, which has significant implications for spacing, interleaving, and ECC strength needed to achieve a target BER.
• AFRL has three different contractors developing three different approaches for "Rad Hard DRAM"; Boise State is doing some work on a new form of spintronics for memories that would also be rad hard, and NASA has done some testing of the Sasmsung commercial PCRAM. If you'd like we can include some of these folks, and/or others of similar ilk, to get a flavor for what is possible and where we are wrt developing high density, low power, low mass/volume, memories (volatile and non). Clearly, we can also include a summary of recent testing of specific memory parts (culled from recent reports/papers).

Friday Working Groups

1. Does it make sense and is it reasonable to develop a Common Space borne Supercomputer Architecture for the U.S space community (NASA, DoD, DoE, IC)?
2. What computer architecture makes sense and what is the right set of hardware and software building blocks?
3. What technologies can we leverage from other communities such as the HPC community and the airborne embedded computing community?

1. Government agency representatives are requested to consider a plenary presentation (i. e. Wednesday or Thursday) on requirements in their agency that would benefit by a common architecture. The organizers will solicit Government agency representatives, but others not contacted may volunteer and will be scheduled for a speaking spot subject to available space.
2. Commercial, university, FFRDC, and Government participants are requested to consider a presentation on hardware and software building blocks that have been created in their organization that they feel could contribute to a common architecture. They may similarly offer methods of organizing building blocks into an architecture. The organizers will solicit speakers, but those not contacted may volunteer and will be scheduled to a plenary slot or the architecture working group subject to avialable space.
3. The closed Government session may address the archtecture theme. Government, FFRDC, and SETA participants with ideas may contact the organizers.