Search NASASearch

SEARCH · Search NASA

Results for “IP cores”

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.

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

At least 19 records

Challenges Regarding IP Core Functional Reliability

For many years, intellectual property (IP) cores have been incorporated into field programmable gate array (FPGA) and application specific integrated circuit (ASIC) design flows. However, the usage of large complex IP cores were limited within products that required a high level of reliability. This is no longer the case. IP core insertion has become mainstream including their use in highly reliable products. Due to limited visibility and control, challenges exist when using IP cores and subsequently compromise product reliability. We discuss challenges and suggest potential solutions to critical application IP insertion.

IP cores

NASA Electronic Parts and Packaging (NEPP) Field Programmable Gate Array (FPGA) Single Event Effects (SEE) Test Guideline Update

The following are updated or new subjects added to the FPGA SEE Test Guidelines manual: academic versus mission specific device evaluation, single event latch-up (SEL) test and analysis, SEE response visibility enhancement during radiation testing, mitigation evaluation (embedded and user-implemented), unreliable design and its affects to SEE Data, testing flushable architectures versus non-flushable architectures, intellectual property core (IP Core) test and evaluation (addresses embedded and user-inserted), heavy-ion energy and linear energy transfer (LET) selection, proton versus heavy-ion testing, fault injection, mean fluence to failure analysis, and mission specific system-level single event upset (SEU) response prediction. Most sections within the guidelines manual provide information regarding best practices for test structure and test system development. The scope of this manual addresses academic versus mission specific device evaluation and visibility enhancement in IP Core testing.

Test guidelines

NASA Electronic Parts and Packaging Field Programmable Gate Array Single Event Effects Test Guideline Update

The following are updated or new subjects added to the FPGA SEE Test Guidelines manual: academic versus mission specific device evaluation, single event latch-up (SEL) test and analysis, SEE response visibility enhancement during radiation testing, mitigation evaluation (embedded and user-implemented), unreliable design and its affects to SEE Data, testing flushable architectures versus non-flushable architectures, intellectual property core (IP Core) test and evaluation (addresses embedded and user-inserted), heavy-ion energy and linear energy transfer (LET) selection, proton versus heavy-ion testing, fault injection, mean fluence to failure analysis, and mission specific system-level single event upset (SEU) response prediction. Most sections within the guidelines manual provide information regarding best practices for test structure and test system development. The scope of this manual addresses academic versus mission specific device evaluation and visibility enhancement in IP Core testing.

Field Programmable Gate Array (FPGA)

Remote Memory Access Protocol Target Node Intellectual Property

The MagnetoSpheric Multiscale (MMS) mission had a requirement to use the Remote Memory Access Protocol (RMAP) over its SpaceWire network. At the time, no known intellectual property (IP) cores were available for purchase. Additionally, MMS preferred to implement the RMAP functionality with control over the low-level details of the design. For example, not all the RMAP standard functionality was needed, and it was desired to implement only the portions of the RMAP protocol that were needed. RMAP functionality had been previously implemented in commercial off-the-shelf (COTS) products, but the IP core was not available for purchase. The RMAP Target IP core is a VHDL (VHSIC Hardware Description Language description of a digital logic design suitable for implementation in an FPGA (field-programmable gate array) or ASIC (application-specific integrated circuit) that parses SpaceWire packets that conform to the RMAP standard. The RMAP packet protocol allows a network host to access and control a target device using address mapping. This capability allows SpaceWire devices to be managed in a standardized way that simplifies the hardware design of the device, as well as the development of the software that controls the device. The RMAP Target IP core has some features that are unique and not specified in the RMAP standard. One such feature is the ability to automatically abort transactions if the back-end logic does not respond to read/write requests within a predefined time. When a request times out, the RMAP Target IP core automatically retracts the request and returns a command response with an appropriate status in the response packet s header. Another such feature is the ability to control the SpaceWire node or router using RMAP transactions in the extended address range. This allows the SpaceWire network host to manage the SpaceWire network elements using RMAP packets, which reduces the number of protocols that the network host needs to support.

Haddad, Omar

An Offload NIC for NASA, NLR, and Grid Computing

This work addresses distributed data management and access dynamically configurable high-speed access to data distributed and shared over wide-area high-speed network environments. An offload engine NIC (network interface card) is proposed that scales at nX10-Gbps increments through 100-Gbps full duplex. The Globus de facto standard was used in projects requiring secure, robust, high-speed bulk data transport. Novel extension mechanisms were derived that will combine these technologies for use by GridFTP, bandwidth management resources, and host CPU (central processing unit) acceleration. The result will be wire-rate encrypted Globus grid data transactions through offload for splintering, encryption, and compression. As the need for greater network bandwidth increases, there is an inherent need for faster CPUs. The best way to accelerate CPUs is through a network acceleration engine. Grid computing data transfers for the Globus tool set did not have wire-rate encryption or compression. Existing technology cannot keep pace with the greater bandwidths of backplane and network connections. Present offload engines with ports to Ethernet are 32 to 40 Gbps f-d at best. The best of ultra-high-speed offload engines use expensive ASICs (application specific integrated circuits) or NPUs (network processing units). The present state of the art also includes bonding and the use of multiple NICs that are also in the planning stages for future portability to ASICs and software to accommodate data rates at 100 Gbps. The remaining industry solutions are for carrier-grade equipment manufacturers, with costly line cards having multiples of 10-Gbps ports, or 100-Gbps ports such as CFP modules that interface to costly ASICs and related circuitry. All of the existing solutions vary in configuration based on requirements of the host, motherboard, or carriergrade equipment. The purpose of the innovation is to eliminate data bottlenecks within cluster, grid, and cloud computing systems, and to add several more capabilities while reducing space consumption and cost. Provisions were designed for interoperability with systems used in the NASA HEC (High-End Computing) program. The new acceleration engine consists of state-ofthe- art FPGA (field-programmable gate array) core IP, C, and Verilog code; novel communication protocol; and extensions to the Globus structure. The engine provides the functions of network acceleration, encryption, compression, packet-ordering, and security added to Globus grid or for cloud data transfer. This system is scalable in nX10-Gbps increments through 100-Gbps f-d. It can be interfaced to industry-standard system-side or network-side devices or core IP in increments of 10 GigE, scaling to provide IEEE 40/100 GigE compliance.

Awrach, James

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

Ethernet for Space Flight Applications

NASA's Goddard Space Flight Center (GSFC) is adapting current data networking technologies to fly on future spaceflight missions. The benefits of using commercially based networking standards and protocols have been widely discussed and are expected to include reduction in overall mission cost, shortened integration and test (I&T) schedules, increased operations flexibility, and hardware and software upgradeability/scalability with developments ongoing in the commercial world. The networking effort is a comprehensive one encompassing missions ranging from small University Explorer (UNEX) class spacecraft to large observatories such as the Next Generation Space Telescope (NGST). Mission aspects such as flight hardware and software, ground station hardware and software, operations, RF communications, and security (physical and electronic) are all being addressed to ensure a complete end-to-end system solution. One of the current networking development efforts at GSFC is the SpaceLAN (Spacecraft Local Area Network) project, development of a space-qualifiable Ethernet network. To this end we have purchased an IEEE 802.3-compatible 10/100/1000 Media Access Control (MAC) layer Intellectual Property (IP) core and are designing a network node interface (NNI) and associated network components such as a switch. These systems will ultimately allow the replacement of the typical MIL-STD-1553/1773 and custom interfaces that inhabit most spacecraft. In this paper we will describe our current Ethernet NNI development along with a novel new space qualified physical layer that will be used in place of the standard interfaces. We will outline our plans for development of space qualified network components that will allow future spacecraft to operate in significant radiation environments while using a single onboard network for reliable commanding and data transfer. There will be a brief discussion of some issues surrounding system implications of a flight Ethernet. Finally, we will show an onboard network architecture for a proposed new mission using Ethernet for science data transport.

Webb, Evan

Path to a Research Plan

This viewgraph presentation discusses the status and goals for the NASA OBPR Physical Science Research Program. The following text was used to summarize the presentation. The OBPR Physical Sciences Research program has been comprehensively reviewed and endorsed by National Research Council. The value and need for the research have been re-affirmed. The research program has been prioritized and resource re-allocations have been carried out through an OBPR-wide process. An increasing emphasis on strategic, mission-oriented research is planned. The program will strive to maintain a balance between strategic and fundamental research. A feasible ISS flight research program fitting within the budgetary and ISS resource envelopes has been formulated for the near term (2003-2007). The current ISS research program will be significantly strengthened starting 2005 by using discipline dedicated research facility racks. A research re-planning effort has been initiated and will include active participation from the research community in the next few months. The research re-planning effort will poise PSR to increase ISS research utilization for a potential enhancement beyond ISS IP Core Complete. The Physical Sciences research program readily integrates the cross-disciplinary requirements of the NASA and OBPR strategic objectives. Each fundamental research thrust will develop a roadmap through technical workshops and Discipline Working Groups (DWGs). Most fundamental research thrusts will involve cross-disciplinary efforts. A Technology Roadmap will guide the Strategic Research for Exploration thrust. The Research Plan will integrate and coordinate fundamental Research Thrusts Roadmaps with the Technology Roadmap. The Technology Roadmap will be developed in coordination with other OBPR programs as well as other Enterprise (R,S,M,N). International Partners will contribute to the roadmaps and through research coordination. The research plan will be vetted with the discipline working groups, the BPRAC subcommittees, and with the BPRAC. Recommendations from NRC past and current committees will be implemented whenever appropriate.Proposed theme element content will be "missionized" around planned content and potential new projects (facilities, modules, initiatives) on approximately a five-year horizon, with the approval of PSRD management. Center/science working group teams will develop descriptions of "mission" objectives, value, and requirements. Purpose is to create a competitive environment for concept development and to stimulate community ownership/advocacy. Proposed theme elements reviewed and approved by PSRD management. Strawman roadmaps for themes developed. Program budget and technology requirements verified. Theme elements are prioritized with the input of advisory groups. Integration into program themes (questions) and required technology investments are defined by science and technology roadmaps. Review and assessment by OBPR management.

Chiaramonte, Fran

Use of Field Programmable Gate Array Technology in Future Space Avionics

Fulfilling NASA's new vision for space exploration requires the development of sustainable, flexible and fault tolerant spacecraft control systems. The traditional development paradigm consists of the purchase or fabrication of hardware boards with fixed processor and/or Digital Signal Processing (DSP) components interconnected via a standardized bus system. This is followed by the purchase and/or development of software. This paradigm has several disadvantages for the development of systems to support NASA's new vision. Building a system to be fault tolerant increases the complexity and decreases the performance of included software. Standard bus design and conventional implementation produces natural bottlenecks. Configuring hardware components in systems containing common processors and DSPs is difficult initially and expensive or impossible to change later. The existence of Hardware Description Languages (HDLs), the recent increase in performance, density and radiation tolerance of Field Programmable Gate Arrays (FPGAs), and Intellectual Property (IP) Cores provides the technology for reprogrammable Systems on a Chip (SOC). This technology supports a paradigm better suited for NASA's vision. Hardware and software production are melded for more effective development; they can both evolve together over time. Designers incorporating this technology into future avionics can benefit from its flexibility. Systems can be designed with improved fault isolation and tolerance using hardware instead of software. Also, these designs can be protected from obsolescence problems where maintenance is compromised via component and vendor availability.To investigate the flexibility of this technology, the core of the Central Processing Unit and Input/Output Processor of the Space Shuttle AP101S Computer were prototyped in Verilog HDL and synthesized into an Altera Stratix FPGA.

Ferguson, Roscoe C.

Digital circuits using universal logic gates

According to the invention, a digital circuit design embodied in at least one of a structural netlist, a behavioral netlist, a hardware description language netlist, a full-custom ASIC, a semi-custom ASIC, an IP core, an integrated circuit, a hybrid of chips, one or more masks, a FPGA, and a circuit card assembly is disclosed. The digital circuit design includes first and second sub-circuits. The first sub-circuits comprise a first percentage of the digital circuit design and the second sub-circuits comprise a second percentage of the digital circuit design. Each of the second sub-circuits is substantially comprised of one or more kernel circuits. The kernel circuits are comprised of selection circuits. The second percentage is at least 5%. In various embodiments, the second percentage could be at least 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90%, or 95%.

Whitaker, Sterling R.

MMIC Amplifiers and Wafer Probes for 350 to 500 GHz

A wireless avionics interface exploits the constrained nature of data networks in flight systems to use a lightweight routing method. This simplified routing means that a processor is not required, and the logic can be implemented as an intellectual property (IP) core in a field-programmable gate array (FPGA). The FPGA can be shared with the flight subsystem application. In addition, the router is aware of redundant subsystems, and can be configured to provide hot standby support as part of the interface. This simplifies implementation of flight applications requiring hot stand - by support. When a valid inbound packet is received from the network, the destination node address is inspected to determine whether the packet is to be processed by this node. Each node has routing tables for the next neighbor node to guide the packet to the destination node. If it is to be processed, the final packet destination is inspected to determine whether the packet is to be forwarded to another node, or routed locally. If the packet is local, it is sent to an Applications Data Interface (ADI), which is attached to a local flight application. Under this scheme, an interface can support many applications in a subsystem supporting a high level of subsystem integration. If the packet is to be forwarded to another node, it is sent to the outbound packet router. The outbound packet router receives packets from an ADI or a packet to be forwarded. It then uses a lookup table to determine the next destination for the packet. Upon detecting a remote subsystem failure, the routing table can be updated to autonomously bypass the failed subsystem.

Samoska, Lorene A.

Interface Supports Lightweight Subsystem Routing for Flight Applications

A wireless avionics interface exploits the constrained nature of data networks in flight systems to use a lightweight routing method. This simplified routing means that a processor is not required, and the logic can be implemented as an intellectual property (IP) core in a field-programmable gate array (FPGA). The FPGA can be shared with the flight subsystem application. In addition, the router is aware of redundant subsystems, and can be configured to provide hot standby support as part of the interface. This simplifies implementation of flight applications requiring hot stand - by support. When a valid inbound packet is received from the network, the destination node address is inspected to determine whether the packet is to be processed by this node. Each node has routing tables for the next neighbor node to guide the packet to the destination node. If it is to be processed, the final packet destination is inspected to determine whether the packet is to be forwarded to another node, or routed locally. If the packet is local, it is sent to an Applications Data Interface (ADI), which is attached to a local flight application. Under this scheme, an interface can support many applications in a subsystem supporting a high level of subsystem integration. If the packet is to be forwarded to another node, it is sent to the outbound packet router. The outbound packet router receives packets from an ADI or a packet to be forwarded. It then uses a lookup table to determine the next destination for the packet. Upon detecting a remote subsystem failure, the routing table can be updated to autonomously bypass the failed subsystem.

Lux, James P.

Interface Supports Multiple Broadcast Transceivers for Flight Applications

A wireless avionics interface provides a mechanism for managing multiple broadcast transceivers. This interface isolates the control logic required to support multiple transceivers so that the flight application does not have to manage wireless transceivers. All of the logic to select transceivers, detect transmitter and receiver faults, and take autonomous recovery action is contained in the interface, which is not restricted to using wireless transceivers. Wired, wireless, and mixed transceiver technologies are supported. This design s use of broadcast data technology provides inherent cross strapping of data links. This greatly simplifies the design of redundant flight subsystems. The interface fully exploits the broadcast data link to determine the health of other transceivers used to detect and isolate faults for fault recovery. The interface uses simplified control logic, which can be implemented as an intellectual-property (IP) core in a field-programmable gate array (FPGA). The interface arbitrates the reception of inbound data traffic appearing on multiple receivers. It arbitrates the transmission of outbound traffic. This system also monitors broadcast data traffic to determine the health of transmitters in the network, and then uses this health information to make autonomous decisions for routing traffic through transceivers. Multiple selection strategies are supported, like having an active transceiver with the secondary transceiver powered off except to send periodic health status reports. Transceivers can operate in round-robin for load-sharing and graceful degradation.

Block, Gary L.

Backplane Design Considerations for High Speed SpaceWire Networks

SpaceWire is becoming a preferred protocol for board to board communication over a backplane in addition to its existing use over cabled interfaces, replacing other protocols due to its simplicity and readily available flight quality physical layer devices, IP cores and test equipment. However, without specific guidelines for implementing SpaceWire over a backplane, designers are left to make trade decisions regarding connector selection, layout design rules and test accessibility issues. This paper will discuss NASA's Goddard Space Flight Center s implementation of high speed SpaceWire over backplane on James Webb Space Telescope and other missions.

Pagen, Shahana Aziz

High-Speed On-Board Data Processing for Science Instruments: HOPS

The project called High-Speed On-Board Data Processing for Science Instruments (HOPS) has been funded by NASA Earth Science Technology Office (ESTO) Advanced Information Systems Technology (AIST) program during April, 2012 â€" April, 2015. HOPS is an enabler for science missions with extremely high data processing rates. In this three-year effort of HOPS, Active Sensing of CO2 Emissions over Nights, Days, and Seasons (ASCENDS) and 3-D Winds were of interest in particular. As for ASCENDS, HOPS replaces time domain data processing with frequency domain processing while making the real-time on-board data processing possible. As for 3-D Winds, HOPS offers real-time high-resolution wind profiling with 4,096-point fast Fourier transform (FFT). HOPS is adaptable with quick turn-around time. Since HOPS offers reusable user-friendly computational elements, its FPGA IP Core can be modified for a shorter development period if the algorithm changes. The FPGA and memory bandwidth of HOPS is 20 GB/sec while the typical maximum processor-to-SDRAM bandwidth of the commercial radiation tolerant high-end processors is about 130-150 MB/sec. The inter-board communication bandwidth of HOPS is 4 GB/sec while the effective processor-to-cPCI bandwidth of commercial radiation tolerant high-end boards is about 50-75 MB/sec. Also, HOPS offers VHDL cores for the easy and efficient implementation of ASCENDS and 3-D Winds, and other similar algorithms. A general overview of the 3-year development of HOPS is the goal of this presentation.

Beyon, Jeffrey

Reconfigurable Hardware Adapts to Changing Mission Demands

A new class of computing architectures and processing systems, which use reconfigurable hardware, is creating a revolutionary approach to implementing future spacecraft systems. With the increasing complexity of electronic components, engineers must design next-generation spacecraft systems with new technologies in both hardware and software. Derivation Systems, Inc., of Carlsbad, California, has been working through NASA s Small Business Innovation Research (SBIR) program to develop key technologies in reconfigurable computing and Intellectual Property (IP) soft cores. Founded in 1993, Derivation Systems has received several SBIR contracts from NASA s Langley Research Center and the U.S. Department of Defense Air Force Research Laboratories in support of its mission to develop hardware and software for high-assurance systems. Through these contracts, Derivation Systems began developing leading-edge technology in formal verification, embedded Java, and reconfigurable computing for its PF3100, Derivational Reasoning System (DRS ), FormalCORE IP, FormalCORE PCI/32, FormalCORE DES, and LavaCORE Configurable Java Processor, which are designed for greater flexibility and security on all space missions.

Source record

Electron Energy Partition Across Interplanetary Shocks. III. Analysis

An analysis of model fit results of 15,210 electron velocity distribution functions (VDFs), observed within ±2 hr of 52 interplanetary (IP) shocks by the Wind spacecraft near 1 au, is presented as the third and final part on electron VDFs near IP shocks. The core electrons and protons dominate in the magnitude and change in the partialto-total thermal pressure ratio, with the core electrons often gaining as much or more than the protons. Only a moderate positive correlation is observed between the electron temperature and the kinetic energy change across the shock, while weaker, if any, correlations were found with any other macroscopic shock parameter. No VDF parameter correlated with the shock normal angle. The electron VDF evolves from a narrowly peaked core with flaring suprathermal tails in the upstream to either a slightly hotter core with steeper tails or much hotter flattop core with even steeper tails downstream of the weaker and strongest shocks, respectively. Both quasi-static and fluctuating fields are examined as possible mechanisms modifying the VDF, but neither is sufficient alone. For instance, flattop VDFs can be generated by nonlinear ion acoustic wave stochastic acceleration (i.e., inelastic collisions), while other work suggested they result from the combination of quasi-static and fluctuating fields. This three-part study shows that not only are these systems not thermodynamic in nature; even kinetic models may require modification to include things like inelastic collision operators to properly model electron VDF evolution across shocks or in the solar wind.

Solar wind