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


Space Flight Digital Electronics


XII. Review of Digital Electronic Circuits


Reviewing an FPGA is quite similar to the design/analysis process, minus the synthesis process, as it employs identical skills and techniques.  In this usage, synthesis refers to the process of synthesizing a logic design to perform the required functions reliability and not to the process of simply pushing a button on a computer screen and having software replace the human.

As such, the review of a digital electronic circuit is simply no more or no less than proving that the design will reliably meet all requirements and specifications.  That of course is the job of the designer/analyst and the reviewer's function is redundant.

This section gives some insight into the process by explaining the steps to be taken in reviewing an FPGA-type digital design.  Although it is written with a currently popular target FPGA (RT54SX-S series) and synthesis tool (Synplicity), the overall methodology and most of the individual steps will apply to any FPGA.  It is assumed that the reader is tasked to review a design having no prior knowledge of its function.

 1. Be Sure You Have the Correct Specification for the FPGA You Are Reviewing

Device specifications can be updated at any time, and there may be subtle differences between a manufacturer's part types, so be sure you have the correct specification sheet for the part being reviewed.  Check the manufacturer's web site for the latest specification, as with web-based specification distribution, updates can come at any time and often without notice.  The governing military specifications are also now available on-line.  Of course, similar care must be utilized for all devices in the system being reviewed.

2. Collect the Necessary Review Files

Most FPGA designs are done in an HDL (hardware description language) such as VHDL or, less often, in Verilog, and so that is the assumption here.  The use of standard tools from a well-known manufacturer and, preferably, from the FPGA vendor,  is encouraged.  This enables the review process by not forcing the reviewer to have to obtain and learn new tools, which drives up the cost and time for a review as well as making it less effective.  For this discussion, we will assume that the Synplicity synthesis tool is being used; the principles are similar for other manufacturers.

The files required for review include those that describe the system, the FPGA, and the electronics surrounding the FPGA:

  1. A system description:  PDR/CDR package, system specification, etc.

  2. A set of board schematics.

  3. The FPGA HDL files along with other files that guide the synthesis process.

  4. Existing test benches

  5. Results of synthesis and timing analysis runs

  6. The .srr file: Synplicity synthesis log file

  7. The .adb file: the database file after place and route -- this is the design.

Before starting the review, familiarize yourself with the system operation and requirements and look over the board schematics to get a feel for the design.  Make note of the FPGA’s place in the overall system and its criticality. 

  1. Is the correct operation of the device safety critical?

  2. Does the device control pyrotechnic initiation circuits, thrusters, or high-voltage power supplies?

  3. Does the device issue spacecraft critical or mission critical commands, set latching relays, or otherwise perform configuration functions?

  4. How many different power sources feed the board, and how are they sequenced?  Consider both power-up and power-down sequences.

  5. How is the circuitry reset?

  6. Is it critical that the FPGA’s functions be performed correctly the first time tried, or is there opportunity for retries?

  7. Does the FPGA receive asynchronous data or commands or perform processing on asynchronous events?

  8. How many clock sources are there, and what are their frequencies, duty cycles and phase relationships?  A clock tree should be provided by the designer or it can be generated as part of the review process.

  9. The printed circuit board artwork should be readily available, as needed, to support signal and power integrity analysis.

Reading through the HDL at this point usually isn’t fruitful, as most HDL is poorly written and documented; not much can be gleaned from it at this time.

3. Performing the Review

There are several levels of detail to which a review can be performed, and ideally every design receives the most detailed review in which correct FPGA usage and the overall electronic and logic design are considered and proven correct.  This isn’t always possible because of time and budget limitations, but the steps in reviewing a design are the same regardless of the ultimate review level, the difference being how many steps in the review are accomplished.  Often, a "spot check" or "scan" of a design is all that may be performed, because of the aforementioned limitations.

One critical thing to remember is that the HDL is not the design, but simply the designer’s description of the desired logic.  Running HDL simulations and test benches is insufficient proof of a design's correctness.

The design is the output of the back end place and route function and the hardware is the physical chip, after configuration.

The fidelity of the actual design to the intended design depends on the quality of the synthesizer, which is unknowable, and the ability of the designer to

One of the limitations of FPGA design is that the static timing analysis tool is primarily designed to analyze fully synchronous logic that uses only one clock edge.  Dynamic logic simulators are insufficient for proving design correctness.  Asynchronous design techniques are extremely difficult to analyze with the available tools, are error-prone, and are thus discouraged where these techniques are not required.  Therefore, an important part of the review process is ferreting out design techniques that are error-prone and should not be used in an FPGA.

3.1 Reviewing the Board Schematics 

The FPGA application can not be properly reviewed without knowing it's electrical environment.  The following list, which is not exhaustive, shows several classes of issues that must be examined.

  1. Of primary importance are that the special pins, e.g., TRST*, are treated properly.  Review the FPGA specification for the requirements of unused clock pins and other special pins such as device configuration or programming pins and verify they have been properly terminated on the board.

  2. Look for unusual loads (e.g., high capacitance or non-logic loads).

  3. Look for unusual sources (e.g., questionable logic levels, excessive transition times, mixing of logic families, devices powered by different supplies, etc.). 

  4. Note circuitry that may be powered up or down independently of the FPGA and the cold-sparing capability of each device.

  5. Determine the number of simultaneously switching outputs and their distribution around the FPGA's I/O ring.

  6. Determine the length of PCB traces and how the signals are terminated, ensuring that overshoot and undershoot specifications are met.  In particular, carefully examine all signals that leave the PCB.

  7. Ensure that the manufacturer's recommendation for bypass capacitors and power/ground planes are being followed.  Past reviews have found boards with inadequate capacitance and routing, including one case where zero bypass capacitors were used and another where placement of the capacitors led to poor performance.

3.2 Reading the Synthesizer Output Log File

The .srr file, the output log file written by Synplicity as it reads though and processes the HDL files, can tell the reviewer quite a bit about the design.  Experience shows that designers rarely read .srr files after synthesis.

  1. The first part of the .srr file shows two passes made through the VHDL.  In the first, Synplicity finds the VHDL modules and state machines, and in the second the state machines are revisited and reset logic is created for any which the designer gave the “safe” attribute to deal with illegal states.

    Note the state machine names found in the first pass, then note in the second pass any for which reset logic is not created.  All state machines should have their illegal states handled, because otherwise illegal states may cause inappropriate behavior.  The requirements for each state machine must be determined and either handled in the logic, by periodic local resets, or by a POR or other reset command.  It is often found that designers concentrate on the correct functioning of the circuits and not on either the effects of "glitches" or recovering from them.  Glitches may result from, for example, power transients, radiation, or ESD.

    Having the reset logic created, however, does not mean the FPGA will perform the correct functions if illegal states are entered.  One subtlety of Synplicity's synthesizer-generated reset logic is that under some conditions a half-edge flip-flop (e.g., a falling edge flip-flop in a rising edge design) is used to generate the reset.  The designer generally doesn’t recognize this because Synplicity doesn’t point it out, and its timing isn’t analyzed.  This timing analysis relies on the duty cycle of the state machine's clock, which may vary considerably, and not the period, which is generally quite accurate, as crystal controlled clock oscillators are the norm.

  2. The next section shows the part replications.  Most important among these are flip-flop replications, and the most important of these are replications of flip-flops which are part of synchronizers of asynchronous signals; replicated flip-flops in synchronizers are of course not permitted.  In general, replicated flip-flops could cause inappropriate operation if transient events cause logically equivalent flip-flops to take on different values, and should be discouraged.  If replicated flip-flops are employed in the design, then the acceptability of each instance must be thoroughly analyzed and documented.  This task is both labor intensive and error-prone and must be performed after each synthesizer run. 

  3. The next section gives a list of the logic types used.  Compare the flip-flops used with the FPGA manufacturer's macro library to see if any of the following types are used: 

  1. Flip-flops without sets or clears, indicating circuitry that will not be reset on POR or reset command;

  2. Flip-flops with both sets and clears, indicating possible asynchronous design techniques (the absence of set/clear flip-flops does not indicate the absence of asynchronous design techniques);

  3. Latches, for which the timing must be checked by hand;

  4. Opposite edge flip-flops (e.g., falling edge flip-flops in a predominantly rising edge design) that could place constraints on clock symmetry and be more difficult to analyze with the timing verifier.  Some opposite edge flip-flops could result from the use of the “safe” attribute, noted above, and the designer is often unaware of their presence.

While the above are not necessarily design errors, they indicate items that must be checked.  Some HDL coding errors can result in unexpected latches or set/clear flip-flops.

  1. The next section discusses the clocks found by the synthesizer.  The logic type list discussed above will also note which of the clock resources were used, and give statements such as “clock found” or “clock inferred”. 

    1. If local clocks were used (i.e., clocks that do not use the global clock resources), they will show up here, e.g., when there are 4 clocks in an FPGA with 3 clock drivers.  Local clocks potentially have much higher skew than is acceptable and their use should not be allowed for clocking sequentially adjacent flip-flops that are triggered on the same edge.

  2. If the routed clocks (CLKA/B) are used in RT54SX-S, RTSX-SU, or A54SX-A devices, the circuitry must be shown to incorporate appropriate skew tolerant design techniques.

  3. A table will show which clock edges have logic between them, e.g., from the rising edge to falling edge of HCLK, or between edges of different clocks.  Carefully scrutinize logic crossing clock domains, and the symmetry requirements of clocks of which both edges are used.

The remainder of the .srr file contains timing analysis information that is calculated before place and route, and is thus of dubious value.  The correct timing analysis will be shown by Timer when the .adb file is accessed; note that Timer will not guarantee minimum values.  However, Timer will not analyze half-edge clock flip-flops or any asynchronous techniques on its own.  Such instances will have to be analyzed by hand, in conjunction with Timer.

When reading the .srr file, carefully note any warnings given.  Designs can synthesize even when warnings are given, but each warning must be dispositioned, after each synthesis run.

3.3 Back-End Tools: Using the .adb file

 The .adb file contains the details of the design, including the actual netlist, timing analysis, pin information, etc.  Designer incorporates a netlist viewer so that the reviewer may see the design in a schematic representation, although it is an awkward view (as most schematic generators produce).  As noted above, the schematic given here, rather than the HDL description, is the real design

  1. Check the temperature, voltage, and radiation settings for which the timing analysis was done.  These should be the full military ranges for temperature and voltage, and whatever the program radiation requirement is.  If the analysis is done with a reduced temperature or voltage range, analyses must be presented justifying the reductions.  Note that the tools assume that temperature is the device junction temperature and not the case temperature of the temperature of the board's thermal control surfaces.

  2. Run Timer to see how much timing margin there is.  Even when the full military ranges are used, as above, there should be some margin for aging, inaccuracy in calculation, etc.  A ± 10% margin for propagation delay is appropriate.

  3. Run Pinedit to determine what I/O options were chosen.  Verify that the choices were appropriate by comparing them with the inputs and outputs seen on the schematics.

  4. Open the Netlist Viewer and view the schematic to resolve the issues found in section 3.2, above, especially to understand the unusual flip-flop usages found in section 3.2(c).

  5. In the Netlist viewer, scan through the schematic looking for flip-flops with gated sets or clears, and to assure that all the settable and resettable flip-flops connect to a valid reset and are not involved in asynchronous design techniques.  Starting at the reset or POR input, the reset lines can be highlighted and followed through all the pages.

  6. In the Netlist viewer, ensure that all mission-critical and safety-critical circuits are implemented correctly.  HDL synthesizers have been seen to implement poor circuits such as static hazards in clock generation circuitry. 

3.4 Review the POR and Reset Circuitry and Power-Up Conditions

The ideal power-on-reset (POR) is asserted as soon as the power supplies are turned on and remains asserted until the voltages reach valid operating levels.  Some factors may require that the POR be asserted beyond that point in the power-up cycle:

  1. If there is an oscillator on the board, it should remain asserted until the oscillator has begun proper operation, which could be as long as tens of milliseconds after its power supply has reached a valid level.

  2. If there are flip-flops that require the oscillator to be running in order to be reset, the reset must be asserted until these flip-flops are reset.   

Beyond this, the criticality of the FPGA and its potential to cause damage to the spacecraft or an instrument, as discussed in section 2 above, may require careful scrutiny of its reset and power up/down conditions.  During some portion of the power up time, the FPGA is not a circuit but simply a collection of unconnected gates, and transients may appear on its outputs.

External circuitry capable of causing damage or undesirable operation during power up and down, or during brown-outs, should be carefully reviewed to verify safe operation during these periods.  For example, circuits constituting an arm and fire mechanism should not have both the arm signal and the fire signal originate in FPGAs that are powering up or down simultaneously.  FPGAs should also not be used to pass POR signals to other circuits without sufficient care; this is a frequently seen cause of problems.  External components should also be reviewed to determine whether special reset requirements exist.  Notable in this class are EEPROMs, which must be protected during power-on, power-off, and other transient conditions such as brown-outs.

3.5 Review the Overall Design to Verify Correct Operation

The more difficult part of a design review is the verification that the circuit does what the specification says it is supposed to do.  This includes, but it not limited to as seen above, going into the HDL and determining what it says the circuitry is supposed to do.  One of the problems with HDL is that even if the design is broken into reasonably sized modules, the connectivity between the modules is difficult to determine.  One method for dealing with this is the following:

  1. Import the HDL modules into Actel Libero

  2. Create a symbol for each of the modules

  3. Using ViewDraw (in the Libero toolset) place the symbols on a large sheet and print it out.

  4. Use colored pencils or highlighters to draw the connections between the modules.

This will give a high-level view of the FPGA design.  Each module should be documented as it serves as a component in the hierarchical design.  Ideally, components will be based on constructs that are essential building blocks of digital systems such as counters, decoders, logical units, sequencers, etc.  Components of arbitrary functionality make the design of reliable systems, as well as their verification, difficult and error-prone.  This is one of the results of a design approach that treats hardware as software.

The remainder of the review consists of examining the modules and reading the specification to determine how the various functions are implemented and whether their requirements are met.  It may be useful to write test benches and simulate some of the modules or even parts of modules if their behavior is not obvious.

Pay careful attention to the timing of interfaces between the FPGA and external components, as these are not usually analyzed by designers. 


References, Notes, and Related Documents

  1. Suggestions for VHDL Design Presentation

  2. "VHDL Design Review and Presentation," 2004 MAPLD International Conference

  3. "A Designer's Checklist,"  2004 MAPLD International Conference

  4. OLD News #13: Minimum Delays and Clock Skew in SX-A and SX-S FPGAs

  5. Index of DSCC Mil Specs & Drawings

  6. "PCB Layout Issues," Design Seminar on Actel SX-A and RTSX-S Programmed Antifuses, Tuesday, April 13, 2004

  7. "Case Study: Simultaneous Switching Outputs," Design Seminar on Actel SX-A and RTSX-S Programmed Antifuses, Tuesday, April 13, 2004

  8. "Drive Strength." Design Seminar on Actel SX-A and RTSX-S Programmed Antifuses, Tuesday, April 13, 2004

  9. "Sequential Circuit Design for Spaceborne and Critical Electronics," Rod Barto, 2000 MAPLD International Conference.

  10. "Is It Safe?" from "Programmable Logic Applications Notes, EEE Links," August 1999.

  11. "When Should You and When Should You Not Use VHDL?"  2004 MAPLD International Conference

  12. "Some Characteristics of Crystal Clock Oscillators During the Turn-On Transient"

  13. Appendix F of the WIRE Mishap Investigation Board Report, June 8, 1999.

  14. "SX-S Output Transients"

  15. "Act 3 Output Transients"


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