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.


Please e-mail comments and suggestions for these guidelines and criteria.

Design Guidelines and Criteria

for

Space Flight Digital Electronics

XI. Design and Analysis Documentation

A: Labeling Schematics

B: Off-Page Signals

C: Auxiliary Synthesis Files

 

Label Schematics: It is good practice to label every instance, symbol, and net in all schematics.  This is useful for two reasons:

  1. The backend engineering and analysis tools will provide output that will reference the labels, either the ones that you supply or the default ones provided by the tools.  Having to find I$25/I$2/N$32 where the label is a hidden attribute is difficult and makes engineering analysis of the tool's analysis difficult.

  2. When you are troubleshooting or performing internal probing, having the labels ready to go lets the engineer concentrate on what he or she is doing.

The following labeling scheme works well.

Schematic labeled using the above guidelines.Design generated by HDL tool without labels.  Performing analysis and troubleshooting on this design is more difficult.


Signals that go off-page should be marked with references to the sheets that they either come from or go to.  It is difficult and error-prone to go through a 20 or more page schematic and search each page for where off-page signals have gone.


Auxiliary Synthesis Files are considered primary design documentation.  In particular any files that control or guide the synthesis process, or that document the output from the synthesizer, should be controlled and included with any documentation package.  For instance, an auxiliary file may determine the style of a finite state machine or perhaps whether "safe" encoding is used.  The HDL description does not specify the design in this case.  Many designers like to keep directives out of the HDL source file to keep it free of synthesizer-specific directives to make the design more portable.  It is preferred to put the directives in the HDL code to minimize the chances of errors in the design, synthesis, analysis, or modification processes.  Similarly, synthesis output files which document what the synthesizer has actually done is also primary design documentation.  For even something as trivial as the flip-flop, the HDL source is insufficient as the circuit design is not knowable from the ASCII text input.  The synthesizer output file is needed to determine whether or not the flip-flop has been replicated, which is critical in many high-reliability applications.  Similarly, for a second example, the state encodings will be listed in the output documentation; it is noted that in some cases the synthesizer decides that it knows better then the designer and does not always follows the guidance provided it.

 

References, Notes, and Related Documents

  1. "Suggestions for VHDL Design Presentation": Detailed design review and worst case analysis are the best tools for ensuring mission success. The goal here is not to make more work for the designer, but to: Enhance efficiency of reviews; Make proof of design more clear; Make design more transferable; and Improve design quality.

TOP LEVEL: "Design Guidelines and Criteria for Space Flight Digital Electronics"


Home - NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz
NACA Seal