SEARCH · Search NASA

Results for “multi-core processor”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

31 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS2019

High Performance Spacecraft Computing (HPSC) Middleware Update

High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes, an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an HPSC project update, an overview of the latest HPSC System Software release, an overview of HPSC Middleware Release 2, and a preview of the third HPSC Middleware release. The presentation will begin with a project update that will provide a look at the high-level changes since the project was introduced at the Flight Software Workshop last year. Next, the presentation will provide an overview of the current suite of HPSC System Software which includes the vendor provided bootloaders, operating systems, emulator, and development tools. Next, the HPSC Middleware progress will be presented, which includes an overview of the features and capabilities of HPSC Middleware Release 2, followed by a look at the reference flight software applications which utilize the Middleware. Finally, the presentation will give a preview of the HPSC Middleware Release 3.

Cudmore, Alan↗

NASA NTRS2012

Fault Tolerance Middleware for a Multi-Core System

Fault Tolerance Middleware (FTM) provides a framework to run on a dedicated core of a multi-core system and handles detection of single-event upsets (SEUs), and the responses to those SEUs, occurring in an application running on multiple cores of the processor. This software was written expressly for a multi-core system and can support different kinds of fault strategies, such as introspection, algorithm-based fault tolerance (ABFT), and triple modular redundancy (TMR). It focuses on providing fault tolerance for the application code, and represents the first step in a plan to eventually include fault tolerance in message passing and the FTM itself. In the multi-core system, the FTM resides on a single, dedicated core, separate from the cores used by the application. This is done in order to isolate the FTM from application faults and to allow it to swap out any application core for a substitute. The structure of the FTM consists of an interface to a fault tolerant strategy module, a responder module, a fault manager module, an error factory, and an error mapper that determines the severity of the error. In the present reference implementation, the only fault tolerant strategy implemented is introspection. The introspection code waits for an application node to send an error notification to it. It then uses the error factory to create an error object, and at this time, a severity level is assigned to the error. The introspection code uses its built-in knowledge base to generate a recommended response to the error. Responses might include ignoring the error, logging it, rolling back the application to a previously saved checkpoint, swapping in a new node to replace a bad one, or restarting the application. The original error and recommended response are passed to the top-level fault manager module, which invokes the response. The responder module also notifies the introspection module of the generated response. This provides additional information to the introspection module that it can use in generating its next response. For example, if the responder triggers an application rollback and errors are still occurring, the introspection module may decide to recommend an application restart.

Some, Raphael R.↗

NASA NTRS1996

Aeroacoustic Codes For Rotor Harmonic and BVI Noise--CAMRAD.Mod1/HIRES

This paper presents a status of non-CFD aeroacoustic codes at NASA Langley Research Center for the prediction of helicopter harmonic and Blade-Vortex Interaction (BVI) noise. The prediction approach incorporates three primary components: CAMRAD.Mod1 - a substantially modified version of the performance/trim/wake code CAMRAD; HIRES - a high resolution blade loads post-processor; and WOPWOP - an acoustic code. The functional capabilities and physical modeling in CAMRAD.Mod1/HIRES will be summarized and illustrated. A new multi-core roll-up wake modeling approach is introduced and validated. Predictions of rotor wake and radiated noise are compared with to the results of the HART program, a model BO-105 windtunnel test at the DNW in Europe. Additional comparisons are made to results from a DNW test of a contemporary design four-bladed rotor, as well as from a Langley test of a single proprotor (tiltrotor) three-bladed model configuration. Because the method is shown to help eliminate the necessity of guesswork in setting code parameters between different rotor configurations, it should prove useful as a rotor noise design tool.

Brooks, Thomas F.↗

NASA NTRS2008

Spaceborne Processor Array

A Spaceborne Processor Array in Multifunctional Structure (SPAMS) can lower the total mass of the electronic and structural overhead of spacecraft, resulting in reduced launch costs, while increasing the science return through dynamic onboard computing. SPAMS integrates the multifunctional structure (MFS) and the Gilgamesh Memory, Intelligence, and Network Device (MIND) multi-core in-memory computer architecture into a single-system super-architecture. This transforms every inch of a spacecraft into a sharable, interconnected, smart computing element to increase computing performance while simultaneously reducing mass. The MIND in-memory architecture provides a foundation for high-performance, low-power, and fault-tolerant computing. The MIND chip has an internal structure that includes memory, processing, and communication functionality. The Gilgamesh is a scalable system comprising multiple MIND chips interconnected to operate as a single, tightly coupled, parallel computer. The array of MIND components shares a global, virtual name space for program variables and tasks that are allocated at run time to the distributed physical memory and processing resources. Individual processor- memory nodes can be activated or powered down at run time to provide active power management and to configure around faults. A SPAMS system is comprised of a distributed Gilgamesh array built into MFS, interfaces into instrument and communication subsystems, a mass storage interface, and a radiation-hardened flight computer.

Chow, Edward T.↗

NASA NTRS2015

2nd Generation QUATARA Flight Computer Project

Single core flight computer boards have been designed, developed, and tested (DD&T) to be flown in small satellites for the last few years. In this project, a prototype flight computer will be designed as a distributed multi-core system containing four microprocessors running code in parallel. This flight computer will be capable of performing multiple computationally intensive tasks such as processing digital and/or analog data, controlling actuator systems, managing cameras, operating robotic manipulators and transmitting/receiving from/to a ground station. In addition, this flight computer will be designed to be fault tolerant by creating both a robust physical hardware connection and by using a software voting scheme to determine the processor's performance. This voting scheme will leverage on the work done for the Space Launch System (SLS) flight software. The prototype flight computer will be constructed with Commercial Off-The-Shelf (COTS) components which are estimated to survive for two years in a low-Earth orbit.

Falker, Jay↗

NASA NTRSDate not supplied

Recent Updates to the Object Reentry Survival Analysis Tool (ORSAT) Version 7.1

The Object Reentry Survival Analysis Tool (ORSAT) code is maintained and used by the NASA Orbital Debris Program Office (ODPO) and has been under continuous development and improvement since the mid-1990s. ORSAT is an object-oriented reentry simulation tool; it models a satellite as a collection of discrete components that follow independent trajectories upon the breakup of the parent object. Version 7.1 of the tool incorporates five years of new thermal and aerodynamic model development, multi-processor parametric study capability, codebase upgrades, and numerous bug-fixes. The thermal demise model was completely rewritten using a forward-time/central-space numerical stencil and incorporating a new pyrolysis model for fiber-reinforced plastic (FRP) materials. New aerodynamic and aeroheating models for hollow cylinders and hollow square prisms were developed using a combination of flow simulations in the direct simulation Monte Carlo (DSMC) Analysis Code (DAC) and Data Parallel Line Relaxation (DPLR) code and free-flight tests in the University of Texas at San Antonio’s Hypersonic Wind Tunnel. The latest version also incorporates a mechanical, strength-based demise model for FRP materials. Minor improvements include an update to the Fortran 2018 codebase; improved integration and speed with the Python-based, multi-core, parametric study tool, AutoORSAT; and fixes for many minor bugs. This new version of ORSAT will enable more accurate reentry risk assessments for modern satellites. This paper presents an overview of these changes and a summary of the verification and validation performed on the final code.

Benton R. Greene↗

NASA NTRSDate not supplied

Recent Updates to the Object Reentry Survival Analysis Tool (ORSAT) Version 7.1

Benton R. Greene↗

NASA NTRS2010

Toward GEOS-6, A Global Cloud System Resolving Atmospheric Model

NASA is committed to observing and understanding the weather and climate of our home planet through the use of multi-scale modeling systems and space-based observations. Global climate models have evolved to take advantage of the influx of multi- and many-core computing technologies and the availability of large clusters of multi-core microprocessors. GEOS-6 is a next-generation cloud system resolving atmospheric model that will place NASA at the forefront of scientific exploration of our atmosphere and climate. Model simulations with GEOS-6 will produce a realistic representation of our atmosphere on the scale of typical satellite observations, bringing a visual comprehension of model results to a new level among the climate enthusiasts. In preparation for GEOS-6, the agency's flagship Earth System Modeling Framework [JDl] has been enhanced to support cutting-edge high-resolution global climate and weather simulations. Improvements include a cubed-sphere grid that exposes parallelism; a non-hydrostatic finite volume dynamical core, and algorithm designed for co-processor technologies, among others. GEOS-6 represents a fundamental advancement in the capability of global Earth system models. The ability to directly compare global simulations at the resolution of spaceborne satellite images will lead to algorithm improvements and better utilization of space-based observations within the GOES data assimilation system

Putman, William M.↗

NASA NTRS2012

Fault-Tolerant, Real-Time, Multi-Core Computer System

A document discusses a fault-tolerant, self-aware, low-power, multi-core computer for space missions with thousands of simple cores, achieving speed through concurrency. The proposed machine decides how to achieve concurrency in real time, rather than depending on programmers. The driving features of the system are simple hardware that is modular in the extreme, with no shared memory, and software with significant runtime reorganizing capability. The document describes a mechanism for moving ongoing computations and data that is based on a functional model of execution. Because there is no shared memory, the processor connects to its neighbors through a high-speed data link. Messages are sent to a neighbor switch, which in turn forwards that message on to its neighbor until reaching the intended destination. Except for the neighbor connections, processors are isolated and independent of each other. The processors on the periphery also connect chip-to-chip, thus building up a large processor net. There is no particular topology to the larger net, as a function at each processor allows it to forward a message in the correct direction. Some chip-to-chip connections are not necessarily nearest neighbors, providing short cuts for some of the longer physical distances. The peripheral processors also provide the connections to sensors, actuators, radios, science instruments, and other devices with which the computer system interacts.

Gostelow, Kim P.↗

NASA NTRS2012

Fault Mitigation Schemes for Future Spaceflight Multicore Processors

The goal of this work is to achieve fail-operational and graceful-degradation behavior in realistic flight mission scenarios, of multicore processors such as Mars Entry-Descent-Landing (EDL) and Primitive Body proximity operations.

single-core architecture↗

NASA NTRS2010

Symbolic Analysis of Concurrent Programs with Polymorphism

The current trend of multi-core and multi-processor computing is causing a paradigm shift from inherently sequential to highly concurrent and parallel applications. Certain thread interleavings, data input values, or combinations of both often cause errors in the system. Systematic verification techniques such as explicit state model checking and symbolic execution are extensively used to detect errors in such systems [7, 9]. Explicit state model checking enumerates possible thread schedules and input data values of a program in order to check for errors [3, 9]. To partially mitigate the state space explosion from data input values, symbolic execution techniques substitute data input values with symbolic values [5, 7, 6]. Explicit state model checking and symbolic execution techniques used in conjunction with exhaustive search techniques such as depth-first search are unable to detect errors in medium to large-sized concurrent programs because the number of behaviors caused by data and thread non-determinism is extremely large. We present an overview of abstraction-guided symbolic execution for concurrent programs that detects errors manifested by a combination of thread schedules and data values [8]. The technique generates a set of key program locations relevant in testing the reachability of the target locations. The symbolic execution is then guided along these locations in an attempt to generate a feasible execution path to the error state. This allows the execution to focus in parts of the behavior space more likely to contain an error.

Rungta, Neha Shyam↗

NASA NTRS2017

SpaceCubeX: A Framework for Evaluating Hybrid Multi-Core CPU FPGA DSP Architectures

The SpaceCubeX project is motivated by the need for high performance, modular, and scalable on-board processing to help scientists answer critical 21st century questions about global climate change, air quality, ocean health, and ecosystem dynamics, while adding new capabilities such as low-latency data products for extreme event warnings. These goals translate into on-board processing throughput requirements that are on the order of 100-1,000 more than those of previous Earth Science missions for standard processing, compression, storage, and downlink operations. To study possible future architectures to achieve these performance requirements, the SpaceCubeX project provides an evolvable testbed and framework that enables a focused design space exploration of candidate hybrid CPU/FPGA/DSP processing architectures. The framework includes ArchGen, an architecture generator tool populated with candidate architecture components, performance models, and IP cores, that allows an end user to specify the type, number, and connectivity of a hybrid architecture. The framework requires minimal extensions to integrate new processors, such as the anticipated High Performance Spaceflight Computer (HPSC), reducing time to initiate benchmarking by months. To evaluate the framework, we leverage a wide suite of high performance embedded computing benchmarks and Earth science scenarios to ensure robust architecture characterization. We report on our projects Year 1 efforts and demonstrate the capabilities across four simulation testbed models, a baseline SpaceCube 2.0 system, a dual ARM A9 processor system, a hybrid quad ARM A53 and FPGA system, and a hybrid quad ARM A53 and DSP system.

Hybrid Flight Architectures↗

NASA NTRS2019

Real-Time Background Oriented Schlieren: Catching Up With Knife Edge Schlieren

Background Oriented Schlieren (BOS) is a widely used technique that provides density gradient information in flow fields of interest, without imposing stringent optical quality requirements on the facility/experiment windows and/or optics used in the BOS setup. Typically, the BOS reference image is acquired before the test begins (flow off) and then the "live" image data are acquired during the actual testing/experiment (flow on). The raw BOS image data, while displayed in real-time as they are acquired from the camera, unfortunately provide little if any visual indication of the density gradients in the flow. Generally, the "live" images must be processed off-line after the testing is completed, providing no indication of the success of the BOS setup and no feedback on the operational success of the test. Advances in computer processing hardware enables the implementation of real-time processing and display of the BOS image data. Two different approaches to implementing the real-time BOS (RT-BOS) processing capability are described herein. First, a traditional multi-core Central Processing Unit (CPU) based approach using scheduled parallel threads is used to build a RT-BOS processing engine. In the second approach, a Graphical Processing Unit (GPU) approach is used to costruct a RT-BOS processing engine. Generally, high core count CPU processors can provide a useful processing rate for RT-BOS. However, the GPU based approach exceeds the processing capability of the CPU approach, at a fraction of the cost. The GPU approach places no restrictions on the Host PC processing capability, except that it be capable of acquiring the BOS image data from the camera in real-time.

Wernet, Mark P.↗