NASA Office of Logic Design

NASA Office of Logic Design

A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.


Software and IP

Read This!

 

 

Applications_Notes and Papers

HAL/S Documentation
  1. HAL/S Compiler System Specification
  2. HAL/S Language Specification
  3. HAL/S Programmer's Guide
  4. HAL/S-FC User's Manual
  5. Programming in HAL/S
 


Horizons: Open Source and Free Software

The January/February 2006 edition of the  Horizons newsletter has a number of interesting articles on open source and free software written by written by Jon Berndt.  This newsletter is published by the AIAA Houston Section


Why Engineers Should Consider Formal Methods

C. Michael Holloway
NASA LaRC
16th Digital Avionics Systems Conference, October 27-30, 1997

Abstract
This paper presents a logical analysis of a typical argument favoring the use of formal methods for software development, and suggests an alternative argument that is simpler and stronger than the typical one.


Software Development Standard for Space Systems

Aerospace Report No. TOR-2004(3909)-3537 Revision B

March 11, 2005

Foreword (excerpt)
This report provides a full life cycle software development process standard based on MIL-STD-498.  Additional information from EIA/IEEEE Interim Standard J-STD-016-1995, Standard for Information Technology, Software Life Cycle Processes, Software Development Acquirer-Supplier Agreement.  In addition, the tailoring from Recommended Software Standards for Space Systems, Aerospace Report No. TOR-2004(3909)-3406 has been applied.


Space Shuttle Technical Conference

Lyndon B. Johnson Space Center
June 28-30, 1983
NASA Conference Publication 2342
General Chairman: Aaron Cohen

Abstract
   This publication is a compilation of the papers prepared for the Space Shuttle Technical Conference held at the NASA Lyndon B. Johnson Space Center, Houston, Texas, June 28-30, 1983. The purpose of this conference was to provide an archival publication for the retrospective presentation and documentation of the key scientific and engineering achievements of the Space Shuttle Program following the attainment of full operational status by the National Space Transportation System.
   To provide technical disciplinary focus, the conference was organized around 10 technical topic areas: (i) Integrated Avionics, (2) Guidance, Navigation, and Control, (3) Aerodynamics, (4) Structures, (5) Life Support, Environmental Control, and Crew Station, (6) Ground Operations, (7) Propulsion and Power, (8) Communications and Tracking, (9) Mechanisms and Mechanical Systems, and (10) Thermal and Contamination Environments and Protection Systems.
   The papers in each technical topic which were presented over the 3-day conference period provide a historical overview of the key technical problems and challenges which were met and overcome during the development phase of the Space Shuttle Program. Taken as a whole, these papers provide a valuable archival reference to the magnitude and scope of this major national achievement.


The "Bug" Heard 'Round the World

Jack Garman
NASA, Johnson Space Center
ACM Software Engineering Notes
October, 1981, pp. 3-10.

Introduction (excerpts)
Discussion of the software problem which delayed the first Shuttle orbital flight.

On April 10, 1981, about 20 minutes prior to the scheduled launching of the first flight of America's Space Transportation System, astronauts and technicians attempted to initialize the software system which "backs-up" the quad-redundant primary software system ......and could not.  In fact, there was no possible way, it turns out, that the BFS (Backup Flight Control System) in the firth onboard computer could have been initialized properly with the PASS (Primary Avionics Software System) already executing in the other four computers.


Proceedings: 2005 National Software and Complex Electronic Hardware Standardization Conference

 


Co-hosted by FAA and NASA

Norfolk, Virginia
July 26-28, 2005


SOFTWARE ASPECTS OF STRATEGIC DEFENSE SYSTEMS

Communications of the ACM, December 1985, Volume 28, Number 12.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear. and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise or to republish. requires a fee and/or specific permission.

Note: While some of this paper is specific to the SDI system back in the 1980's, a good amount of the engineering analysis is applicable to those who wish to treat the digital logic design problem as a software task and use software methods.  This analysis is applicable to our work today.  -- rk

Summary:
This report comprises eight short papers that were completed while I was a member of the Panel on Computing in Support of Battle Management, convened by the Strategic Defense Initiative Organization (SDIO).

  1. Why software is unreliable
  2. Why the SDI software system will be untrustworthy
  3. Why conventional software development does not produce reliable programs
  4. The limits of software engineering methods
  5. Artificial intelligence and the Strategic Defense Initiative
  6. Can automatic programming solve the SDI software problem?
  7. Can program verification make the SDI software reliable?
  8. Is SDIO an efficient way to fund worthwhile research?


Stereo Vision and Rover Navigation Software for Planetary Exploration

S. Goldberg, M. Maimone, L. Matthies
IEEE Aerospace Conference
March 2002, pp. 2025-2036
Big Sky, Montana

Abstract
  
NASA's Mars Exploration Rover (MER) missions will land twin rovers on the surface of Mars in 2004. These rovers will have the ability to navigate safely through unknown and potentially hazardous terrain, using autonomous passive stereo vision to detect potential terrain hazards before driving into them. Unfortunately, the computational power of currently available radiation hardened processors limits the amount of distance (and therefore science) that can be safely achieved by any rover in a given time frame.
   We present overviews of our current rover vision and navigation systems, to provide context for the types of computation that are required to navigate safely. We also present baseline timing results that represent a lower bound in achievable performance (useful for systems engineering studies of future missions), and describe ways to improve that performance using commercial grade (as opposed to radiation hardened) processors. In particular, we document speedups to our stereo vision system that were achieved using the vectorized operations provided by Pentium MMX technology. Timing data were derived from implementations on several platforms: a prototype Mars rover with flight-like electronics (the Athena Software Development Model (SDM) rover), a RAD6000 computing platform (as will be used in the 2003 MER missions), and research platforms with commercial Pentium III and Sparc processors.
   Finally, we summarize the radiation effects analysis that suggests that commercial grade processors are likely to be adequate for Mars surface missions, and discuss the level of speedup that may accrue from using these instead of radiation hardened parts.


Software-Desaster, und wie man sie verhindern kann

 

Inhalt

Programmfehler sind oft nur irritierend, können aber auch verheerende Folgen haben.  Ein Fehler im Pentium-Prozessor kostete Intel im Jahr 1994 US$ 306 Millionen. Fehler in einem Steuerrechner des neuen Stellwerks im Bahnhof Hamburg Altona führten im Jahr 1995 dazu, daß der Bahnhof für mehrere Tage nicht angefahren werden konnte, und verursachte erheblichen Ärger bei den Bahnkunden.  Aus der Luft- und Raumfahrt sind etliche durch Softwarefehler verursachte Unfälle bekannt, die zum Teil auch zum Verlust von Menschenleben führten.

In dem Proseminar wollen wir einige der bekanntesten dieser Fehler und die durch sie ausgelösten Desaster untersuchen.  Dabei soll jeweils

  • dargestellt werden, was genau schief ging, und wie es dazu kommen konnte, und
  • eine Technik aus der Informatik vorgestellt werden, die solche Fehler verhindern hilft.
Themen werden jeweils in Zweiergruppen bearbeitet.  Jede Gruppe recherchiert Verlauf und Auswirkungen eines Desasters und stelle eine Technik aus der Informatik vor, mit der man Fehler dieser Art verhindern kann.  Die Themenübersicht finden Sie weiter unten auf dieser Seite.


"Software Acquisition And Software Engineering Best Practices."XL

Eslinger, S. The Aerospace Corporation
Report No. TR-2000(8550)-1, SMC Report No. SMC-TR-99-27 (15 November 1999).
 

Purpose and Scope
     The purpose of this white paper is to address the issues raised in the recently published Senate Armed Services Committee Report 106-50 concerning Software Management Improvements for the Department of Defense (DoD). The text, titled "Software Management Improvements," extracted from Title VIII (Acquisition Policy, Acquisition Management, and Related Issues) of Senate Report 106-50, is given for reference in Table 1-1 of the body of this report.
     This paper recommends a set of software acquisition and software engineering best practices that addresses the issues raised in the Senate Report. These recommendations are based upon the experience of The Aerospace Corporation in supporting the United States Air Force (USAF) and the National Reconnaissance Office (NRO) in the acquisition of DoD space systems. The domain of application of the recommended best practices, therefore, is the acquisition and development of large software-intensive, mission-critical systems, such as space systems, which are for the most part unprecedented.


MER Spirit Flash Memory Anomaly (2004)

NASA Public Lessons Learned System (PLLS) Database

Abstract:
Shortly after the commencement of science activities on Mars, an MER rover lost the ability to execute any task that requested memory from the flight computer. The cause was incorrect configuration parameters in two operating system software modules that control the storage of files in system memory and flash memory. Seven recommendations cover enforcing design guidelines for COTS software, verifying assumptions about software behavior, maintaining a list of lower priority action items, testing flight software internal functions, creating a comprehensive suite of tests and automated analysis tools, providing downlinked data on system resources, and avoiding the problematic file system and complex directory structure.


Flip-Flop Replication

replication.htm

Introduction

Logic designers often replicate logic for reliability or performance reasons. For example, if the load on an output is too high, then the load will often be split between multiple drivers (in some cases outputs may be joined together but this is not preferred and is usually avoidable). In other cases, cutting the load and duplicating the driver can help make timing by distributing the capacitive load. The replication of combinational logic is quite straightforward.

However, if this concept is extended to sequential logic then the situation is trickier since state information is involved. Indeed, the logic may present different information to different parts of the circuit and, for example, may be inconsistent in the presence of a trasient fault such as a single event upset, ESD event, etc. That is, the logical flip-flop can present different values to different parts of the circuit depending on which physical flip-flop they connected to. This is a call for caution in high-reliability applications. Software CAE tools are more than happy to generate circuits of this class and do not generate logic to ensure self-consistency.


"25 Years Ago"

Fred Martin, MIT/IL
1994

Introduction
25 years ago it happened, the first Lunar Landing, Apollo 11 - July 20,1969. It was an exciting, exhilarating time of total focus and dedication. Current and alumni Intermetrics employees were intimately involved with the project since its inception in 1960 (John Miller, Jim Miller, Ed Copps, Jim Flanders, Dan Lickly, Joe Saponaro, Bill Widnall, John Green, Alex Kosmala, Ray Morth, Steve Copps and me, Fred Martin). The most memorable part of the flight for me, aside from the landing and the moonwalk itself, was the descent from lunar orbit to the surface. I'd like to present a personal remembrance and perspective.

ESA Software Initiative

May 7, 2003
Kjeld Hjortnaes
esa_software_initiative_final_may_7.pdf

Why the ESA Software Initiative
  • Late 2000 an analysis of the results from Technical Reviews of more than 18 ESA projects was conducted and reported to the ESA Management Board.
  • Top technical problem areas was on- board software:
    • Most ESA programmes experience significant development problems of on- board software. Software development schedules are often on the critical path even at the PDR stage.
    • Worldwide major failures in space programmes have been attributed to bad engineering and verification of software.
    • The software complexity, size and verification are severely under estimated.
  • ESA Management Board instructed D/ TOS, in cooperation with ESA project teams, to analyse the problem, its causes and issue appropriate recommendations.


An Investigation of the Therac-25 Accidents

Nancy G. Leveson1 and Clark S. Turner2
1 University of Washington
2 University of California, Irvine

therac_updated.pdf

therac_failure

Introduction
Computers are increasingly being introduced into safety-critical systems and, as a consequence, have been involved in accidents.  Some of the most widely cited software-related accidents in safety-critical systems involved a computerized therapy machine called the Therac-25.  Between June 1985 and January 1987, six known accidents involved massive overdoses by the Therac-25 -- with resultant deaths and serious injuries.  They have been described as the worst series of radiation accidents in the 35-year history of medical accelerators.


Minimizing HDL Design Errors

Ben Cohen
VhdlCohen Publishing

Minimizing_Design_Errors_HDL.pdf
Minimizing_Design_Errors_HDL.doc

Abstract

This paper discusses processes, methodologies, and classes of tools necessary to minimize ASIC and FPGA design errors.

(added July 5, 2001)

 

VHDL Modelling Guidelines

european space research and technology centre

ASIC/001, Issue 1
September 1994

Prepared by P. Sinander

ESA_ModelGuide.pdf
ESA_ModelGuide.ps

Abstract
   This document defines requirements on VHDL models and testbenches, and is intended to be used as an applicable document for ESA developments involving VHDL modelling. It is mainly focused on digital models; specific requirements for analog modelling have not been covered.
   The requirements concern simulation and documentation aspects of VHDL models delivered to ESA; specific rules and guidelines for logic synthesis from VHDL have not been included. Nevertheless, the requirements of this document are compatible with the use of logic synthesis. The requirements are not applicable for the case when a design database is transferred in VHDL format.
   The purpose of these requirements is to ensure a high quality of the developed VHDL models, so they can be efficiently used and maintained with a low effort throughout the full life-cycle of the modelled hardware.
   The requirements are based on the VHDL-93 standard, to minimise future maintenance efforts for updating models. However, in an initial stage the models shall be backward compatible with VHDL-87 as far as possible, since some tools will not be updated immediately.
   The requirements have been structured in a general part applicable to all VHDL models, and additional requirements applicable to different kinds of models. In addition, VHDL code examples and a list of common problems encountered have been included in order to provide some guidance to the VHDL developer. If not stated which kind of model is to be developed, the default kind is a model for Component simulation.  (Added March 20, 2001)
Force_Errors.pdf Forcing Signal Errors with VHDL
Abstract
This paper presents a technique, which uses the user-defined resolution function feature of VHDL, to selectively control from VHDL the assertion of errors imposed on testbench signals of type Std_Logic. This technique allows the testbench environment to selectively inject errors at specific times and with specific values onto signals to verify the design-under-test responses to interface errors. (January 4, 2001)
EDAC8Cyclic.pdf
edac.vhd
edac_rtl.vhd
edac_tb.vhd
A (16,8) Error Correcting Code (T=2) For Critical Memory Applications
Abstract
     High density SRAMs generate errors in their stored data because of natural radiation. This is a particular problem for computing on-board a satellite , where the single-error correction of the usual Hamming code can be inadequate. The two-bit error correcting code described here is a more powerful and efficient alternative. (12/21/2000)
Component_Verification.pdf Component Verification by Example
Abstract
This paper presents, by example, some of the key features of the front-end processes for specifying the planning of both the implementation and verification (i.e., testbench) of a design to ensure that the implemented design meets its intended requirements and costs.  (12/19/2000)
R1-2000_Installation.htm

Designer R1-2000 - Installation Notes.  A DCOM update is required for some Microsoft OS installations.  (Dec. 11, 2000).

DesignerVariables.htm

Variables for Designer Software - Placement and Routing (December 8, 2000).

Combiner.htm How to Read Combiner Information Files
LEON-1 VHDL model The LEON core is a SPARC* compatible integer unit developed for future space missions. It has been implemented as a highly configurable, synthesisable VHDL model. To promote the SPARC standard and enable development of system-on-a-chip (SOC) devices using SPARC cores, the European Space Agency is making the full source code freely available under the GNU LGPL license.

The LEON-1 processor should be seen as a demonstrator of the LEON core. As such, it implements a minimum of interfaces and functions. Once the LEON core has been fully verified, a more complete processor (LEON-2) will be developed with functions such as PCI interface, floating-point unit and DRAM controller. 

The LEON core has been extensively tested against the IEEE-P1754 (SPARC) standard, but have not been formaly tested and cerified by SPARC international as being SPARC V8 compliant.

ESA_DesignReq.pdf ASIC Design and Manufacturing Requirements - ESA
VHDL87_Syntax.htm VHDL '87 Syntax Diagrams.
VHDL93_Syntax.htm VHDL '93 Syntax Diagrams
synopsis_actel.pdf "Using Synopsis to Design Actel's Radiation-Hardened FPGAs,"
Abstract
This application note shows how to use Synopsis automation scripts to control synthesis such that SEU soft flip-flops (S-Module flip-flops) are excluded from the synthesized output.  The synthesis can be controlled to either use radiation-tolerant flip-flops (C-Module or C-C flip-flops) or triple-modular redundant (TMR) structures. (.pdf 39 kbytes)
SynplicitySEUControl.htm "Using Synplicity to Control Flip-Flip Implementation for SEU-Hardness"
Abstract
A procedure is given and discussed on now to use Synplicity to control the flip-flop implementation.  Either C-Mod flip-flops or TMR implementations are generated from VHDL or Verilog HDL code.
ACTmap_ForLoop.PDF "VHDL Coding Style in ACTmap"
Abstract
As we move to a higher percentage of design using VHDL, it is important to understand the effects of VHDL on design efficiency and device performance. A number of tests using different coding styles have been run.
VL_74_R@1998_Upgrade.htm "Updating from WVOffice 7.31 and Designer 3.1.1u1 to WVOffice 7.4 and Designer R2-98 on a PC"
AsynchronousLoops.htm Procedure for having Designer software detect asynchronous feedback loops in timing analysis.
HoldTimeCalculation.PDF Note on clock skew not in calculations for Designer software, 3.0 and later. (.pdf 28 kbytes).
Converting Objectstore Databases

Converting Designer 3.0 and 3.1 Objectstore databases to the new format.

Programming with Old Actel Databases

Which versions of Actel software can program the .def and .fus file formats and how do I convert files to the .afm file format for new versions of the software?

Actel Database Compatibility App note on Actel database compatibility across platforms
VHDL and Other References List of VHDL Books, Documents, and Reports and some other references.
Actgen R3-1998 Patch Actgen Patch for R3-1998 Designer Software - Certain taps in LFSR are incorrect.
Actgen R3-1998 Bug Inverted Output

Actgen Bug for R3-1998 Designer Software - in modulo-class counters, the output may be inverted.  Additionally, counts should be verified.

Safe State Machines with Synplify "Designing Safe VHDL State Machines with Synplify".  Discussion of Synplicity mechanism for handling the VHDL problem of trap states.  Posted 8/15/99 (Version 5.1.5a current).

 

Utilities

LFSR Testbench

lfrs_testbench.exe

lfrs_testbench.zip

The LFSR testbench can help you understand the LFSR basics:
  1. Change interactively the LFSR settings (length, taps, style, lockup or no lock-up states, ...).
  2. Visualize the matching schematic.
  3. Get the binary sequence list and length.
  4. Get the corresponding HDL designs in AHDL, VHDL, or Verilog.

Courtesy of Jean Nicolle (http://www.logiccell.com/~jean/LFSR/)

Unix2DosZip.EXE Unix to DOS file conversion package that runs under Windows.
KPP.htm KPP - a pre-processor, similar to CPP, for VHDL applications.   It provides many standard functions such as #def, #undef, #ifdef, #include, etc.   It also provides for loops and some other features.  The program will run on Win '95, Win '98, and Win NT.  For this version, use the default directory for installation.
Arithmetic Module Generator for High Performance VLSI Designs Enter parameters and it outputs VHDL for adders, subtractors, multipliers, and squarer.

Link to: Norwegian University of Science and Technology

 

 

Software_SoC_and_IP_Vendors_and_Groups

WWW Site

Technology Description

Technical Contact

Intellitech Intellitech Corporation develops Intellectual Property (IP) for efficient configuration, debug and test of electronic products including SoC (System-on-a-Chip), ICs, PCBs and Systems. The IP provides a scalable configuration, debug, and test infrastructure that enables self-testable and in-the-field re-configurable products. Bret O. Moses
Intellitech Corporation
229 Polaris Ave., Suite 7
Mountain View, CA 94043
Tel: 650-968-4784
Cell: 408-394-5003
bmoses@intellitech.com
Microelectronics: VHDL

ESA Synthesizable VHDL Models

The VHSIC Hardware Description Language (VHDL) is a formal notation intended for use in all phases of the creation of electronic systems. The European Space
Agency has decided that VHDL shall be used in contracts that include design of electronics for spacecraft.

Very high integration levels of microelectronics will be required to fulfil the ever-increasing demands for high processing performance, low mass and power. With an increasing number of available gates on silicon, the functionality being implemented will move away from the use of traditional components to more advanced and complex systems within a single device. To develop such complex circuits the design methodology will have to change from being gate-level oriented to the integration of complex building blocks. The designers will have to rely on pre-existing building blocks with already verified functionality, with documentation and production test vectors being available, and which have ultimately been validated on silicon.

The contents of this page is related to VHDL building blocks for microelectronic developed in the scope of European Space Agency (ESA) activities, ranging from in-house developments to contractor work and from simple Field Programmable Gate Arrays (FPGA) to complex System-On-a-Chip (SOC) devices.

Martin.Hollreiser@esa.int
Welcome The purpose of this web site is to explain and promote the design and implementation of FPGA-based CPUs and integrated systems-on-a-chip. Gray Research LLC
P.O. Box 6156
Bellevue, WA 98008-1156
USA
Tel: (425) 861-8781
xsoc@fpgacpu.org
Mentor Graphics Corporation

Actel FPGA Netlist Catalog

CAE Vendor

Inventra IP for Actel

Model Technology ModelSim VHDL, Verilog, and Mixed-HDL Simulator Tel:  (503) 641-1340
Fax: (503) 526-5410
support@model.com
Model Technology, Inc.
8905 SW Nimbus Ave., Suite 150
Beaverton, Oregon 97008-7159
StateCAD Translates Graphical State Machines to HDL support@statecad.com
Tel:  (954) 423-8448
Fax: (954) 423-8434
Synopsys Home Page
Synplicity: Home Page support@synplicity.com
Tel: (408) 617-6000
Viewlogic Systems Group http://www.viewlogic.com/support/index.html
pc-support@viewlogic.com
The Free IP Project The Free-IP project is an effort to make quality IP available to anyone.

What is IP? IP is short for Intellectual Property. More specifically, it is a block of logic that can be used in making ASIC's and FPGA's. Examples of "IP Cores" are, UART's, CPU's, Ethernet Controllers, PCI Interfaces, etc. In the past, quality cores of this nature could cost anywhere from US$5,000 to more than US$350,000. This is way too high for the average company or individual to even contemplate using-- Hence, the Free-IP project.

Initially the Free-IP project will focus on the more complex cores, like CPU's and Ethernet controllers. Less complex cores might follow.

David Kessner

davidk@free-ip.com


Home - NASA Office of Logic Design
Last Revised: August 08, 2007
Digital Engineering Institute
Web Grunt: Richard Katz
NACA Seal