12004 mapldvhdl synthesis introduction vhdl synthesis for high-reliability systems (vol. 2 of 2)...

12004 MAPLD VHDL Synthesis Introduction

VHDL Synthesis forHigh-Reliability Systems

(Vol. 2 of 2)

2004 MAPLD International Conference

Washington, D.C.

September 7, 2004


Synthesis Issues

Demonstrated with a Simple Finite State Machine Using Gray Codes


Gray Codes

“This is rookie stuff, so I can duck out of this module, get some cookies,

and come back later, right?”


History of the Gray Code

• Invented by Emile Baudot (1845-1903)

• Originally called a “cyclic-permuted” code

• Telegraph - 5 bit codes– Bits stored on a code wheel in the receiver– Wheel connected to the printing disk– Matched pattern on wheel and received pattern and

then actuated head to print.

• Exhibited at Universal Exposition, Paris (1878)


0 0 0 0 0 1 0 0 0 1 2 0 0 1 1 3 0 0 1 0 4 0 1 1 0 5 0 1 1 1 6 0 1 0 1 7 0 1 0 0 8 1 1 0 0 9 1 1 0 110 1 1 1 111 1 1 1 012 1 0 1 013 1 0 1 114 1 0 0 115 1 0 0 0

Binary Reflected Gray Code

0 0 0 1 0 1 2 1 1 3 1 0

0 0 0 0 1 0 0 1 2 0 1 1 3 0 1 0 4 1 1 0 5 1 1 1 6 1 0 1 7 1 0 0


Why Gray Codes?

• Single output changes at a time– Asynchronous sampling– Permits asynchronous combinational circuits to

operate in fundamental mode– Potential for power savings

• Multiphase, multifrequency clock generator


Effects of Errors

• Lockup States– None if all states are used– Can’t use all states for one-hot

• Magnitude of Error– Reduced to one code word– Binary can jump 1/2 scale


Binary Counter + Gray Code Converter: Glitch Free?

BinaryCounter

Binaryto

GrayConverter

CLK


VHDL Code for a 4-Bit Gray Code Sequencer (1)

Package Gray_Types Is

Type States Is ( s0, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14, s15 );

End Package Gray_Types;


VHDL Code for a 4-Bit Gray Code Sequencer (2)

Library IEEE; Use IEEE.Std_Logic_1164.all;

Library Work; Use Work.Gray_Types.All;

Library synplify; Use synplify.attributes.all;

Entity Gray_Code Is

Port ( Clock : In Std_Logic; Reset_N : In Std_Logic;

Q : Out States ); End Entity Gray_Code;

Architecture RTL of Gray_Code Is Attribute syn_netlist_hierarchy of RTL : architecture is false;

Signal IQ : States; Attribute syn_encoding of IQ : signal is "gray";

Begin GC: Process ( Clock, Reset_N ) Begin If ( Reset_N = '0' ) Then IQ <= s0; Else If Rising_Edge ( Clock ) Then Case IQ Is When s0 => IQ <= s1; When s1 => IQ <= s2; When s2 => IQ <= s3; When s3 => IQ <= s4; When s4 => IQ <= s5; When s5 => IQ <= s6; When s6 => IQ <= s7; When s7 => IQ <= s8; When s8 => IQ <= s9; When s9 => IQ <= s10; When s10 => IQ <= s11; When s11 => IQ <= s12; When s12 => IQ <= s13; When s13 => IQ <= s14; When s14 => IQ <= s15; When s15 => IQ <= s0; When Others => IQ <= s0; End Case; End If; End If; End Process GC;

Q <= IQ;

End Architecture RTL;


Synthesizer Output for a Gray Code Sequencer - SX Target

Logic Equations:A: ~D2 ~S10+D2 ~S00B: D0 ~S00 ~S10+D1 S00 ~S10+D1 ~S00 S10+D0 S00 S10C: D0 ~S00 ~S10+D1 S00 ~S10+~D0 ~S00 S10+D0 S00 S10D: D0 ~S01+D1 ~S00 S01+D0 S00E: ~D0 ~S00 ~S10+D0 S00 ~S10+D0 ~S00 S10+~D0 S00 S10F: D0 ~S00 ~S10 +~D0 S00 ~S10+~D0 ~S00 S10+D0 S00 S10

AB

C

D

E

F


time = 9000.0ns Q=0000 time = 10000.0ns Q=1000 time = 11000.0ns Q=1100 time = 12000.0ns Q=0100 time = 13000.0ns Q=0110 time = 14000.0ns Q=1110 time = 15000.0ns Q=1010 time = 16000.0ns Q=0010 time = 17000.0ns Q=0011 time = 18000.0ns Q=1011 time = 19000.0ns Q=1111 time = 20000.0ns Q=0111 time = 21000.0ns Q=0101 time = 22000.0ns Q=1101 time = 23000.0ns Q=1001 time = 24000.0ns Q=0001 time = 25000.0ns Q=0000

Simulation Output for a Gray Code Sequencer

net -vsm "D:\designs\sequencers\gray_code4.vsm"

clock clock 1 0stepsize 500ns

vector q q_3 q_2 q_1 q_0radix bin qwatch q

l reset_ncycle 8

h reset_ncycle 32


Simulation Output for a Gray Code Sequencer


Synthesizer Output for a Gray Code Sequencer

Outputs are not always driven by a flip-flop


Synplicity1 Synthesis Issues

• Synthesizer ignored the command to make the state machine a Gray code and decided to make it a one-hot machine. Had to “fiddle” with the VHDL compiler settings for default FSM.

– Signal IQ : States;– Attribute syn_encoding of IQ : signal is "gray";

• Output glitches!!!!!!!!

1Synplify version 5.1.5


FSM Gray Codes and HDLThe Saga Continues ...

We had another engineer (HDL specialist) run the same Gray coded FSM through his version of Synplicity and what did he get …

… Yes, as the cynic would expect, a different answer!



Here's the key part of the output listing:

Encoding state machine work.Gray_Code(rtl)-q_h.q[0:15]

original code -> new code

0000000000000001 -> 0000 0000000000000010 -> 0001 ... 1000000000000000 -> 1000

… So far so good!



But then ...

Replicating q_h.q[3], fanout 13 segments 2Replicating q_h.q[2], fanout 13 segments 2Replicating q_h.q[1], fanout 12 segments 2Replicating q_h.q[0], fanout 12 segments 2

Added 0 BuffersAdded 4 Cells via replication

Resource Usage Report of Gray_Code

Sequential Cells: 8 of 1080 (1%) dfc1b: 8



Package Gray_Types Is

Type States Is ( s0, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14, s15);

End Package Gray_Types;

library IEEE;use IEEE.Std_Logic_1164.all;

library Work;use Work.Gray_Types.all;

library synplify;use synplify.attributes.all;

entity Gray_Code is

port ( Clock : in std_logic; Reset_N : in std_logic; Q : out States );end entity Gray_Code;

architecture RTL of Gray_Code is attribute syn_netlist_hierarchy of RTL : architecture is false;

signal IQ : States; attribute syn_encoding of IQ : signal is "gray";

begin GC : process ( Clock, Reset_N ) begin if ( Reset_N = '0' ) then IQ <= s0; else if Rising_Edge ( Clock ) then case IQ is when s0 => IQ <= s1; when s1 => IQ <= s2; when s2 => IQ <= s3; when s3 => IQ <= s4; when s4 => IQ <= s5; when s5 => IQ <= s6; when s6 => IQ <= s7; when s7 => IQ <= s8; when s8 => IQ <= s9; when s9 => IQ <= s10; when s10 => IQ <= s11; when s11 => IQ <= s12; when s12 => IQ <= s13; when s13 => IQ <= s14; when s14 => IQ <= s15; when s15 => IQ <= s0; when others => IQ <= s0; end case; end if; end if; end process GC;

Q <= IQ;

end architecture RTL;

Synplicity VHDL Compiler, version 6.2.0



Automatic Flip-flop Replication


4-Bit Gray CodeNo Enumerations or FSM Optimization (1)

library IEEE;use IEEE.Std_Logic_1164.all;entity graycntr_lookup is port ( Clk : in std_logic; Reset_N : in std_logic; Q : out std_logic_vector(3 downto 0));end entity graycntr_lookup;

architecture RTL of graycntr_lookup is signal IQ : std_logic_vector(3 downto 0);

begin GC : process (Clk, Reset_N) begin if ( Reset_N = '0' ) then IQ <= "0000"; else if Rising_Edge ( Clk ) then case IQ is when "0000" => IQ <= "0001"; when "0001" => IQ <= "0011"; when "0011" => IQ <= "0010"; when "0010" => IQ <= "0110"; when "0110" => IQ <= "0111"; when "0111" => IQ <= "0101"; when "0101" => IQ <= "0100"; when "0100" => IQ <= "1100"; when "1100" => IQ <= "1101"; when "1101" => IQ <= "1111"; when "1111" => IQ <= "1110"; when "1110" => IQ <= "1010"; when "1010" => IQ <= "1011"; when "1011" => IQ <= "1001"; when "1001" => IQ <= "1000"; when "1000" => IQ <= "0000"; when others => IQ <= "0000"; end case; end if; end if; end process GC; Q <= IQ;end architecture RTL;

• No enumerations• Synplicity VHDL Compiler, version 6.2.0


time = 8000.0ns RESET_N=0 Q=0000 time = 9000.0ns RESET_N=1 Q=0000 0time = 10000.0ns RESET_N=1 Q=0001 1time = 11000.0ns RESET_N=1 Q=0011 2time = 12000.0ns RESET_N=1 Q=0010 3time = 13000.0ns RESET_N=1 Q=0110 4time = 14000.0ns RESET_N=1 Q=0111 5time = 15000.0ns RESET_N=1 Q=0101 6time = 16000.0ns RESET_N=1 Q=0100 7time = 17000.0ns RESET_N=1 Q=1100 8time = 18000.0ns RESET_N=1 Q=1101 9time = 19000.0ns RESET_N=1 Q=1111 10time = 20000.0ns RESET_N=1 Q=1110 11time = 21000.0ns RESET_N=1 Q=1010 12time = 22000.0ns RESET_N=1 Q=1011 13time = 23000.0ns RESET_N=1 Q=1001 14time = 24000.0ns RESET_N=1 Q=1000 15time = 25000.0ns RESET_N=1 Q=0000 0




Flip-flop outputs routed directly to outputs.


References

• “Origins of the Binary Code,” F. G. Hearth, Scientific American, August 1972, pp. 76-83


VHDL Design ReviewAnd

Presentation


Designer’s Responsibilities(Besides Doing the Design):

• Make the design reviewable and transferable– Documentation

• Theory of operation• Proof that spec and WCA are met

– Organization• Partitioning into logical components

– Presentation• Readability of schematics, VHDL, etc.

• Inadequate documentation biggest design review problem– How would you, the designer, explain your design to someone else?

• Reviewer’s question: If the designer can’t present the design, does the designer understand the design?


How to Review VHDL Designs

• How does one perform a design review, in general?– Most design review tasks are independent of how the

design is presented

• What does VHDL add to the task?


What VHDL Adds to the Review Process

• Probably, an awful lot more work!!• VHDL introduces serious problems:

– It hides design details

– It is not WYSIWYG: What you see (as your design concept in VHDL) may not be what you get (as an output of the synthesizer)

– Coupled with FPGAs, it encourages bad design practices

• Understanding design by reading code extremely difficult


VHDL Hides Design Details

• Connectivity hard to follow in VHDL files

• Behavior of sequential circuits can be hard to follow through processes

• Interactions between modules can be difficult to understand

• Spelling errors → undetected circuit errors


Following connectivity

• Signal name changes make task difficult• My method as a reviewer:

– Import modules into Libero– Create symbols for modules– Create a schematic with modules and print it out

on E-size paper– Connect modules with colored pencils

• Designer should do this as part of design presentation


Following ConnectivitySimple Input and Output Example

MA1: COUNT23 port map (RST_N => SIM_CLR_N, SYNC_CLR => EQUALS_internal, CLOCK => C5MHZ, Q => TIME_NOW_internal ); MA3: MUX_23_4 port map (A => R1HZ, B => R6HZ, C => R8HZ, D => R10HZ, T => THZ, T_SEL => TEST_SEQ, S1 => RATE_SEL(1), S0 => RATE_SEL(0), Y => Y ); MA2: COMP23 port map (DATAA => TIME_NOW_internal, DATAB=> Y, AEB => EQUALS_internal ); MA7: GATE_RANGE port map (RST_N => RST_N, CLOCK => C5MHZ, OPEN_VALUE => OPEN_VALUE,CLOSE_VALUE => CLOSE_VALUE, TIME_NOW => TIME_NOW_internal, GATE => GATE ); MA8: BIN2GRAY23 port map (A => TIME_NOW_internal, Y => GRAYTIME );

EQUALS <= EQUALS_internal; TIME_NOW <= TIME_NOW_internal;end RTL_ARCH;

Note: Had to print out the entity just to make this slide.

InputsOutputs


Following ConnectivitySignals In a Simple Module

MA1: COUNT23 port map (RST_N => SIM_CLR_N, SYNC_CLR => EQUALS_internal, CLOCK => C5MHZ, Q => TIME_NOW_internal ); MA3: MUX_23_4 port map (A => R1HZ, B => R6HZ, C => R8HZ, D => R10HZ, T => THZ, T_SEL => TEST_SEQ, S1 => RATE_SEL(1), S0 => RATE_SEL(0), Y => Y ); MA2: COMP23 port map (DATAA => TIME_NOW_internal, DATAB=> Y, AEB => EQUALS_internal ); MA7: GATE_RANGE port map (RST_N => RST_N, CLOCK => C5MHZ, OPEN_VALUE => OPEN_VALUE,CLOSE_VALUE => CLOSE_VALUE, TIME_NOW => TIME_NOW_internal, GATE => GATE ); MA8: BIN2GRAY23 port map (A => TIME_NOW_internal, Y => GRAYTIME );

EQUALS <= EQUALS_internal; TIME_NOW <= TIME_NOW_internal;end RTL_ARCH;

Making this chart was a lot of work and was error prone.


E.g., A Spelling Error?

• A VHDL module contained two signals:– CSEN appeared only on the left side of a

replacement statement:CSEN <= …

– CS_EN sourced several signals, i.e., appeared on the right side

X <= CS_EN…

• Were they intended to be the same signal?


E.g., Meaning of Names-- ADDRESS DECODE LOGIC VALUES IF (ADDRCOUNT >= "000001000") THEN ADCGE8_I <= '1'; [note name ends in “8” and comparison value

is 8] ELSE ADCGE8_I <= '0'; END IF; IF (ADDRCOUNT >= "000000110") THEN ADCGE6_I <= '1'; [note name ends in “6” and comparison value

is 6] ELSE ADCGE6_I <= '0'; END IF; IF (ADDRCOUNT = "000110101" OR LOADAC = '1') THEN ADCGE36_D <= '1'; [note name ends in “36” but comparison

value is 35]

• Lesson: Be careful with your names!


VHDL is Not WYSIWYG

• Signals intended to be combinational can end up being sequential, and vice versa

• Sequential circuits can have unexpected, undesirable SEU behavior– Paper: “Logic Design Pathology and Space Flight

Electronics”, R. Katz, R. Barto, K. Erickson, 2000 MAPLD International Conference

• The designer gives up some control over the design to unvalidated software


VHDL and Bad Design Practices

• VHDL and FPGAs combine to allow designers to treat design as software– Especially for FPGAs for which there is no

reprogramming penalty, e.g., Xilinx

• Rather than designing by analysis, designers simply “try” design concepts


E.g., part of a 16 page process -- V1.02 & V2.2 -- DATA WILL STOP TANSFERING IFF BOTH HOLD AND OUTPUT ENABEL

ARE -- ACTIVE FOR THE SAME PORT

-- HOLD2 <= ((((HLD2TX_N_Q AND O_EN_Q(2)) OR -- (HLDTX_N_Q AND O_EN_Q(1)) OR -- (ROFRDY_N_Q AND O_EN_Q(0))) AND-- NOT(BYPASS_EN_Q AND (HLDTX_N_Q AND O_EN_Q(1)))));

HOLD1_I <= ((HLDTX_N_Q AND O_EN_Q(1)) OR (ROFRDY_N_Q AND O_EN_Q(0)));-- V2.2

HOLD2 <= (((((HLD2TX_N_Q AND O_EN_Q(2)) OR (HLDTX_N_Q AND O_EN_Q(1)) OR (ROFRDY_N_Q AND O_EN_Q(0))) AND NOT(BYPASS_EN_Q AND (HLDTX_N_Q AND O_EN_Q(1))))) OR (((HLD2TX_N_Q AND O_EN_Q(2)) OR (HLDTX_N_Q AND

O_EN_Q(1))) AND (BYPASS_EN_Q AND HLDTX_N_Q AND O_EN_Q(1))));


SimplifyingLet:

a=HDL2TX_N_Q and O_EN_Q(2)b=HLDTX_N_Q and O_EN_Q(1)c=ROFRDY_N_Q and O_EN_Q(0)d=BYPASS_EN_Q

ThenHOLD2=(a+b+c)·(d·b)’ + (a+b)·(d·b) = a+b+c.

What happened to d=BYPASS_EN_Q??


Lessons

• Don’t just try things, think about what you’re doing– Either BYPASS_EN_Q is needed or it’s not –

what’s the requirement of the system?

• Make modules small enough to test via VHDL simulation, and test them fully.– If this logic was tested by itself, the error would

have been found.

• It’s on orbit, now


Combined Effects of VHDL

Hidden design details

+ Non-WYSIWYG nature

+ Bad design practicesDesigner can lose control of design

i.e., the designer loses understanding of what is in the design, then adds erroneous circuitry until simulation looks right


E.g., found in a VHDL file:

CASE BVALREG3A_Q IS

WHEN "0000" =>

IF (DAVAIL_LCHA_Q = '1' ) THEN

-- ISN'T THIS CONDITION ALWAYS TRUE

-- AT THIS POINT??? PC

• Just how well did the designers understand the design??


Worst Case Result

• A design that works in simulation for expected conditions, but with flaws that show up in unusual conditions

• Passed on with little documentation by engineers who become unavailable

A total programmatic disaster!!

An common occurrence!


Solution to VHDL Problem

• Make sure designs are reviewable and transferable– No such thing as too good an explanation of

how a circuit works

• Don’t use VHDL (much less Verilog!!)


VHDL Review

Tools and Techniques


Netlist Viewer

• Crucial because– Synthesizer output, not VHDL, is the final design– Easy to see asynchronous design items– Connectivity often more apparent in viewer than

in VHDL

• Helps solve the non-WYSIWYG nature of VHDL


.srr files

• Flip-flop replication– See examples in “Synthesis Issues” module.

• State machine encoding and illegal state protection

• Inferred clocks => possible asynchronous design techniques

• Resource usage


.adb files

• Needed for netlist viewer

• Check internal timing

• Get timing parameters to perform board level timing analysis

• Check I/O pin options


VHDL Simulator

• Simulate modules or extract parts of modules

• Try to break them:– Most simulations are success oriented, in that

they try to show the module works when it gets the expected inputs

– Try to simulate with the unexpected inputs– Easier to do with smaller modules


E.g., breaking a FIFO

Here’s the full flag, but we’ll keep writing

Here we get the full flag while reading out

Turned out to be a problem for the project


Suggestions for FPGA Design Presentation


Goals

• 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– Improve design quality


Steps to Preparing for Design Review

1. Modularize your design2. Make a datasheet for each module3. Show FPGA design in terms of modules4. Describe internal circuitry5. Describe state machines6. Describe FPGA connections7. Describe synthesis results8. Provide timing spec for external timing analysis9. Show requirements of external circuitry


1. Modularize your design

• Easier to do during design phase• Goal is to describe design in terms of components

that can be individually verified• Each component, or module, is a separate VHDL

entity• Modules should be of moderate, e.g., MSI, size

– E.g., FIFO, ALU

– Counter, decoder probably too small

– VME interface too big


2. Make a Datasheet for Each Module

• Describe the module’s behavior

• Show truth table

• Show timing diagrams of operation

• Provide test bench used to verify module– Try to break it

• Model: MSI part data sheet


3. Show FPGA Design in Terms of Modules

• Provide requirements spec for FPGA

• Draw block diagram

• Top-level VHDL entity shows FPGA inputs and outputs and ties component modules together

• Show necessary timing diagrams– Interaction between modules

– Interaction with external circuitry

• Text for theory of operation

• Provide test bench for top level simulation


4. Describe internal circuitry

• Use of clock resources• Discuss skew issues• Describe deviations from fully synchronous design

– Be prepared to show necessary analysis

• Show how asynchronism is handled– External signals– Between clock domains

• Glitch analysis of output signals used as clocks by other parts


5. Describe state machines

• Encoding chosen

• Protection against lock-up states

• Homing sequences

• Reset conditions


6. Describe FPGA Connections• Use of special pins: TRST*, MODE, etc.• Power supply requirements

– Levels, sequencing, etc.

• Termination of unused clock pins• Input and output options chosen for pins• Discuss transition times of inputs• POR operation and circuitry• Critical signals and power-up conditions

– Remember WIRE! (being presented next door in a parallel seminar).


7. Describe synthesis results

• Percentage of utilization

• Flip-flop replication and its effects on reliable operation

• Margin results from Timer

• Timing of circuits using both clock edges


8. Provide Timing Specification for External Timing Analysis

• tSU, tH with respect to clock

• Clock to output tPD

• tPW for signals connected to flip-flop clocks

• Clock symmetry requirements if both edges of clock used


9. Show Requirements of External Circuitry

• Provide data sheets for parts interfacing to FPGA

• Show timing diagrams of interactions of FPGA to other parts

• Show timing analysis of external circuitry


References

• Design guidelines:http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/

• Design tutorialshttp://klabs.org/richcontent/Tutorial/tutorial.htm

• Design, analysis, and test guidelines:http://klabs.org/DEI/References/design_guidelines/design_analysis_test_guides.htm


When Should You and When Should You Not Use VHDL?

Richard B. Katz

NASA Office of Logic Design

2004 MAPLD International Conference

September 8-10, 2004

Washington, D.C.


Abstract

Many designers will design all of their ASIC and FPGA logic circuits in VHDL or some other HDL.

Is that the correct approach for “critical” applications of digital logic?

When should you and when should you not design with VHDL in critical military and aerospace applications?


Sample Applications to Discuss(Some Real, Some Hypothetical)

• Critical Timing Circuit in a Scientific Instrument– Timing unit with < 400 ps resolution

• Controller for a Crane in an Industrial Environment.– Moving a Space Shuttle Orbiter

• Initiation Circuit for Explosives and Rockets– Warhead Fuzes

– Self-Destruct Charges on a Solid Rocket Booster (manned)

– Rocket Motor On Fighter Aircraft Missile


Critical Timing Circuit in a Scientific InstrumentTiming unit with < 400 ps resolution

• Don’t have to like it, you just have to do it.

• Requires hand placement of many critical modules– Minimize Delays

– Match Delays• Aid in calibration

• Try to cancel temperature coefficients for tPD

– Assume on order of 100 modules must be hand placed.

• Schematic:– Straightforward to identify modules and place them. Names in the

design match the names in the back end tool.

• VHDL:– Munges names, names constant from run to run? Effects on timing

constraint/analysis tools?


Skew and Clocks


Quick Review of Clock Skew

Early FF1:CLK

Late FF2:CLK

D

E

Note: used min, best case for prop delays and max, worst-case for clock path to FF2.


An Excerpt from OLD News #13

The findings below are accurate at the time of this posting and is the manufacturer's current guidance.

• Minimum delay numbers calculated by the timing analysis tools are not guaranteed. They are not bound and actuals may be less then the reported values. This is true for Designer's TIMER as well as files containing extracted delays such as .sdf files.

• For an arbitrary flip-flop pair, with a common edge (either rising or falling), when clocked by a global routed array clock:

– There is no guarantee that it will be correct by construction under all conditions and placements.

– There is no certified technique to prove adequate margin by analysis with the current tool set.

– Skew-tolerant design techniques are recommended.

Reference: http://www.klabs.org/richcontent/old_news/old_news_13/


A Schematic Approach to Skew-Tolerant Circuits


A VHDL Approach to Skew Tolerant Circuits

DTCountIntNEProc:Process ( Clock, Reset )Begin if Reset = ActiveReset then DTCountIntNE <= "00000000"; elsif Falling_Edge ( Clock ) then if ReadPulse = '1' then DTCountIntNE <= DTCountInt + 1; end if; end if; End Process DTCountIntNEProc;

DTCountIntProc:Process ( Clock )Begin if Rising_Edge ( Clock ) then DTCountInt <= DTCountIntNE; end if; End Process DTCountIntProc;


Verification

• Is functional level simulation adequate?

• Examine circuit level result of the VHDL synthesis process. Is this practical?– Labor Intensive– Redo for each synthesizer revision?– Redo for each synthesis run?


Functional level simulation adequate?

Original

“Optimized”

The two circuits are logically equivalent when analyzed with Boolean logic equations with the lower, CAE-optimized circuit, permitting higher device speeds. An SEU analysis shows the addition of a second state variable with an upset resulting in the "optimized" circuit containing a state where Q = QN, violating the system equations and causing a failure.


Critical DelaysOK, not a VHDL slide, but shows the need for examination of circuits

An old slide but the principle resurfaces many times. In a recent examination of a military safety-critical system, it was found that the designer was making delays with gates, the back end software was removing them, and he was unaware since he did not understand either the software he was using or the actual design as implemented.


VHDL Code and Synthesizer AnalysisCase Study - Hardened Clock Generator

• The VHDL synthesizer, unknown to the designer, generated a poor circuit for a TMR voter– Used 3 C-Cells for a voter

– Slowed the circuit down

• The implementation of the voter is hidden from the user– Synthesizer generated a static hazard

– An SEU can result in a glitch on the "hardened" clock signal.

• Designer did not examine the synthesizer’s output.



-- Divide 25 MHz (40 ns) clock by 4-- to produce 6.25 MHz clock (160 ns)-- This clock should be placed on-- an internal global buffer

clkint1: clkintPort Map ( A => clk_div_cnt(1), Y => clk_div4 );

clkdiv: Process (reset_n, clk)Begin If reset_n = '0' Then clk_div_cnt <= "00"; Elsif clk = '1' And clk'EVENT Then clk_div_cnt <= clk_div_cnt + 1; End If;End Process clkdiv;



Most significant bit of the counter. 3 C-Cells are used for the voter.

25MHz

CLK_DIV4


How Do You Verify Circuit Correctness for Safety Critical

Applications?


Reset Circuit Topologies

Reference: Analysis of POR Circuit Topologies http://klabs.org/richcontent/fpga_content/DesignNotes/por/por.htm


Introduction

The seemingly simple issue of FPGA and ASIC power-on reset circuits is nevertheless often a frequent cause of problems. The discussion in this module will cover both the key issues and a variety of circuits, analyzing their strong and weak points. The discussion will in most cases be general logic design but will deal with some particular issues with Field Programmable Gate Arrays (FPGAs).


System Issues

None of the circuits discussed in this module are intended to deal with issues of logic devices not starting (e.g., following their truth table) instantly after the application of power. These system-level issues, based on system-level requirements, must be analyzed and, if necessary, dealt with at the system level and not at the logic level internal to the FPGA or ASIC.


Analysis Assumptions1. The external POR circuitry is properly designed.

2. The clock is generated by a crystal clock oscillator, which takes a certain amount of time to start and then become stable. Additionally, the oscillator may not start clean.

3. The clock is not gated off. If that is not true, such as when areas of the circuit where the clock is gated off for power savings, then additional issues arise.

4. The POR signal is asynchronous to CLK.

5. The period of CLK is large compared with the metastable state resolution time of the flip-flop being used for synchronization.

6. The POR assertion time exceeds the clock oscillator and FPGA start times.

7. The output of the internal POR circuit drives the asynchronous set/reset of flip-flops. Since modern FPGAs all have asynchronous flip-flop inputs, this is often used to save logic resources, delay, and power. This is an important consideration since these inputs, unlike D's and ENABLE's, are sensitive to glitches. It is further assumed that timing specifications are met for set/reset distribution including the "removal" time.

8. Noise pulses on the input POR signal is a credible situation.


Fully Asynchronous Application

Unintended operation or lockup of finite state machines or systems may result if the flip-flops come out of reset during different clock periods.

There is a potential for one or more uncontrolled metastable states.

Therefore, only reset circuits that [attempt to] remove power-on reset synchronously (PORS) should be considered in hi-rel applications.


Fully Asynchronous ApplicationTYPE STATE_TYPE IS (s0 , s1 , s2, s3, s4, s5, s6, s7, s8, s9, ………………………………………….. s60, s61, s62, s63, s64, s65, s66, s67);…………………………………………..IF resetn = '0' THEN state <= s0;…………………………………………..CASE state IS

WHEN s0=>IF StartC = '1' THEN state <= s1;END IF;WHEN s1=> state <= s2;WHEN s2=> state <= s3;WHEN s3=> state <= s4;WHEN s4=> state <= s5

…………………………………………….

• A real life example of lack of consideration for POR issues:– Numerous state machine used in

design, some rather complex

– External POR signal applied to all flip-flops with no synchronization

– Local routing resources used for delivering POR throughout the circuit


POR Circuit Selection

Significant issues related to the analysis and selection of a power-on reset circuit for a particular application include:

– Dependence on clock signal being operational

– Noise immunity

– Critical timing path impact


Synchronously Applied, Synchronously Removed Circuits

All circuits of this type need Clock to be operational


Example 1A

Example1AProc:process (Clk)begin if RisingEdge(Clk) then PORA <= POR; PORS <= PORA; end if;end process Example1AProc;


Example 1A

• Fully synchronous

• Needs Clock to be operational (+ two cycles)– Compare with start/load time for FPGA

• Minimized impact on critical timing path

• Rejects noise that is not coincident with clock edge– External analog filters can help; device input transition times must be met,

simple RC circuits may violate timing constraints

– Internal digital FSM can act as a filter, care must be taken for startup conditions, latency, timing, metastable states, etc.

– No general solution since noise can be arbitrarily large in time


Example 1BExample1BProc:process (Clk)begin if RisingEdge(Clk) then PORA <= POR; PORB <= PORA; end if;end process Example1BProc;PORS <= PORA or PORB;

• A flawed attempt to improve Circuit in Example 1 for noise immunity– A static hazard on the output of

OR gate: a POR pulse shorter than one Clock cycle may result in a glitch on PORS


Example 1CExample1CProc:process (Clk)begin if RisingEdge(Clk) then PORA <= POR; PORB <= PORA; PORC <= PORB; end if;end process Example1CProc;PORS <= PORA or PORC;

• Fixes static hazard problem of Example 1B for narrow noise spikes.

• Only one input to the OR gate changes at any time– This technique can be extended

to reject POR pulses of arbitrary width


Asynchronously Applied, Synchronously Removed Circuits

Remember, many programmable logic devices will not allow inputs in or outputs out until the device starts.


Example 2Example2Proc:process (Clk)begin if RisingEdge(Clk) then PORA <= POR; PORB <= PORA; end if;end process Example2Proc;PORS <= POR and PORB;


Example 2

• POR wrapped around the synchronizing flip-flops to asynchronously assert PORS– Assertion of PORS is not affected by oscillator start time or even failure

• Removal is clean; properly synchronized to FFA and FFB

• FPGA start time may make the asynchronous application of POR appear to take action “instantly”.– Schematic or HDL description of a circuit may not be valid during the turn-

on transient.

• Noise immunity is low– Noise or runt pulses will get onto the reset network, resulting in incomplete

resets and metastable states.

• The logic gate slows the signal down relative to Example 1


Example 3Example3ProcA:process (Clk, POR)begin if POR = '0' then PORA <= '0'; elsif RisingEdge(Clk) then PORA <= POR; end if;end process Example3ProcA;

Example3ProcB:process (Clk)begin if RisingEdge(Clk) then PORS <= PORA; end if;end process Example3ProcB;


Example 3

• Fixes some of the problems of Figure 2.– Noise immunity improved

– No gate in the path of PORS helps with timing

• No combinational path for reset; needs an operational clock to propagate.

• Most transients are “caught” by FFA and then cleaned up.– Worst case: a noise glitch on POR just before an active edge of Clk


Example 4A

Example4AProc:process (Clk, POR)begin if POR = '0' then PORA <= '0'; PORS <= '0'; elsif RisingEdge(Clk) then PORA <= POR; PORS <= PORA; end if;end process Example4AProc;


Example 4A

• POR can be distributed prior to the clock starting. Note that the FPGA must be fully operational too, as discussed above.

• FFB will take care of metastability on the PORA signal.

• Noise glitches are reasonably well handled.– FFA and FFB should be hand placed to minimize POR skew.

– Not “bulletproof” against Runt pulses on POR.

• Is FFB reliable with POR removed asynchronously? Note that some hi-rel flip-flops are built with TMR structures. Other flip-flops may internally “glitch” or have a hazard and not be stable.


Example 4BExample4BProc:process (Clk, POR)begin if POR = '0' then PORA <= '0'; PORB <= '0'; PORS <= '0'; elsif RisingEdge(Clk) then PORA <= POR; PORB <= PORA; PORS <= PORB; end if;end process Example4BProc;

• Extension of the circuit shown in 4A.

• Longer reset after detection of a transient.


Notes and References1. "Some Characteristics of Crystal Clock Oscillators During the Turn-On Transient." This application

note discusses and shows what the output of an oscillator may be during the turn-on transient. Examples shows include runt pulses of various sizes and polarities. http://klabs.org/richcontent/General_Application_Notes/oscillator/osc_start_up_note/index.htm

2. "Asynchronous & Synchronous Reset Design Techniques - Part Deux“ http://klabs.org/richcontent/General_Application_Notes/reset_sync_async_v2.pdf

3. "Small Explorer WIRE Failure Investigation Report." This is Appendix F of the WIRE Mishap Investigation Board Report, June 8, 1999. http://klabs.org/richcontent/Reports/WIRE_Report.PDF

4. "Startup Transient," from Advanced Design: Designing for Reliability, 2001 MAPLD International Conference, Laurel, MD, September 10, 2001. http://klabs.org/richcontent/Tutorial/MiniCourses/reliable_design_mapld2001/D_StartupTransient.ppt

5. "Current Radiation Issues for Programmable Elements and Devices," IEEE Transactions on Nuclear Science, December 1998. http://klabs.org/richcontent/Papers/NSREC98_Paper.pdf

6. "RH1020 Single Event Clock Upset Summary Report," Richard B. Katz and J. J. Wang, March 5, 1998 http://klabs.org/richcontent/fpga_content/Act_1/rh1020_clk_upset_White_paper.PDF

7. Thanks to Melanie Berg of Ball for the helpful comments and suggesting to add notes about the extra delay in the reset path when using topologies such as those shown in Figure 2.

8. "Hazard Analysis," from Design Guidelines and Criteria for Space Flight Digital Electronics. http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/hazards/hazards.htm and http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/index.htm

9. Timing Analysis of Asynchronous Signals http://klabs.org/richcontent/General_Application_Notes/parts/removal_time.htm

12004 mapldvhdl synthesis introduction vhdl synthesis for high-reliability systems (vol. 2 of 2)...

Documents