Reliable State Machines
description
Transcript of Reliable State Machines
10/14/2005 Caltech 1
Reliable State Machines
Dr. Gary R Burke
California Institute of TechnologyJet Propulsion Laboratory
10/14/2005 Caltech 2
outline
• Background – JPL MER example
• JPL FPGA/ASIC Process– Procedure– Guidelines
• State machines– Traditional– Highly Reliable– Comparison
10/14/2005 Caltech 3
10/14/2005 Caltech 4
10/14/2005 Caltech 5
10/14/2005 Caltech 6
MER Mission example
• Large number of FPGAs
• Mostly fuse programmable – but at least one RAM programmable FPGA
• Several ASICs
• Many standard parts eg Microprocessor, RAM chips.
10/14/2005 Caltech 7
10/14/2005 Caltech 8
10/14/2005 Caltech 9
10/14/2005 Caltech 10
10/14/2005 Caltech 11
10/14/2005 Caltech 12
10/14/2005 Caltech 13
10/14/2005 Caltech 14
FPGA/ASIC Process
• JPL needs to ensure design process is sound• A bug in an FPGA/ASIC can halt a billion dollar
mission• Tight schedules can result in inadequate testing• Inadequate version control can result in the wrong
code • First Pass success important for ASIC design
10/14/2005 Caltech 15
FPGA/ASIC Process
• To ensure a quality product:
• Requirements are correct and do not change
• Specification is complete
• Design will meet the specification and requirements
• Testing has covered all possible cases
10/14/2005 Caltech 16
FPGA/ASIC Process
• Peer reviews by experts to check the design and design approach
• Formal Reviews to ensure design process is adequate, and to sign off on the design
• Documentation for review and archiving
• Check-lists to ensure all problems are fixed
10/14/2005 Caltech 17
FPGA/ASIC Process
• Configuration Management to ensure correct versions are used
• Verification Matrix – which documents all testing
• Checking tools e.g. Lint, DRC; all errors, and warnings documented
10/14/2005 Caltech 18
ASIC PROCESS
Specification: HDL Design: Structural design: Physical Design:Complete Layout::
IDRReview
PDRReview
CDRReviewSTART
ASIC Design ProcessGRB - 2/1/04
InputsLevel 5
Requirements
outputs
CreateSpecification.Preliminary
design.Test Approach.
ASIC/FPGA/packageselection.
ConfigurationmanagementReview plan
Select FoundryPartition Design
Specify IPsFT approach
process
PreliminarySpecification
CM planTest approach
ConceptualDesign
&Requiremen
tsReviewIs ASICready toprocede
withdetaileddesign?
RTL code,Test PlanUpdated
Specification
RTL Design; RTL simulation
DFT;simulation coverageV test bench & modeling
Trial SynthesisTrial Timing analysisTrial testability anal.
Test PlanInitial Firmware design
SEU mitigation planFault tolerant plan
Lint verificationpinout defined
code walkthrough
PDRIs ASIC
Ready toprocede
withstructuraldesign?
SynthesisTiming analysis
testabilityPrototype; ATPGVendor software
Gate levelverification
Firmware designTest vectorsTV coverage
Trial P&RPrototype FPGA
Formal Verification
Structural codeTest Vectors
StructuralDesignPeer
Reviewand
Sign-off
Physical Design:Place and Route
Timing analysis BAUpdate PrototypeTest Vectors BAVendor software
BAGate level
verification BA
Test vectorsLayoutnetlist
V-matrix
PhysicalDesignPeer
reviewand
sign-off
Chip layout
Complete Layout::Chip integration
DRCLVSERC
CDRReview: Is
ASIC readyfor
fabrication?
CDRChecklist
Firmw are Design:
Analog CircuitDesign:
Analog LayoutDesign:
Firmw areCompilation
Proto BoardTest
Proto BoardDesign
StructuralDesignsign-off
PhysicalDesignsign-off
PreliminarySpecification
CM planTest approach
RTL code,Test Plan
Updated Specification
Structural codeTest Vectors
chipfabrica
tion
10/14/2005 Caltech 19
FPGA PROCESS
Specification: HDL Design:FPGA Prototype
design:FPGA Final Build
IDRReview
PDRReview
CDRSTART
FPGA Design ProcessGRB - 2/1/04
InputsLevel 5
Requirements
outputs
CreateSpecification.
ImplementationPartition and
Test Approach.FPGA deviceand package
selection.ConfigurationmanagementSchedule with
Plan for ReviewsSpecify IPs
FT approach
process
PreliminarySpecification
CM planTest approach
ConceptualDesign
&Requiremen
tsReviewIs FPGAready toprocede
withdetaileddesign?
RTL code,Test Plan
Updated Specification
HDL Design; HDL simulation
DFT;simulation coverageV test bench & modeling
Trial SynthesisTrial Timing analysis
Test PlanInitial Firmware design
SEU mitigation planFault tolerant plan
Lint verificationpinout defined
code walkthroughprot-board design
Is FPGAReady toprocede
withsynthesis?
SynthesisTiming analysis
testabilityPrototype
FPGA softwareGate levelverification
Firmware designTest vectorsTV coverage
Prototype FPGA
Configurationcode
Test Vectors
Physical Design:Place and RouteTiming analysis
Update PrototypeTest Vectors
Vendor softwareSystem Test
Verificationmatrix;
Test vectors
CDRReview: Is
flight FPGAready for
personalization?
CDRChecklist
Firmw are Design:
Proto-BoardTest
Firmw areVerif ication
Prot-boarddesign
FPGA fuseprogramming
PreliminarySpecification
CM planTest approach
RTL code,Test Plan
Updated Specification
Configurationcode
Test Vectors
10/14/2005 Caltech 20
Guidelines
• Define set of rules for HDL design
• Reduce ambiguity
• Clarify design to be easily checked and reviewed
• Implement most reliable design techniques
10/14/2005 Caltech 21
Fault Tolerant State Machines
• The state machine needs to be tolerant of single event upsets
• State machine should not hang
• State machine should always be in a defined state
• No asynchronous inputs to state machine
• Default state must be specified
10/14/2005 Caltech 22
State Machines• A state machine is a sequential machine that when
built into an FPGA or ASIC controls the sequencing of actions in the digital logic
• The current state of a machine is held in a state register which is updated on a clock
• The next value of the state register (next state) is derived from the current state and the inputs
• Outputs from the state machine are decoded from the state register and can also be combined with the inputs
10/14/2005 Caltech 23
State-Machine (SM) Encoding
• Each distinct state of the SM is represented by a unique code
• The allocation of these binary codes to states is the Encoding
• The simplest encoding is Binary
• In Binary encoding each state is given the next available binary number in sequence.
10/14/2005 Caltech 24
Other SM Encoding
• 1-hot encoding– The number of bits in the code is equal to the number of states. Each
encoded state has just 1 bit in the encoded word set to a 1 (the rest are 0)– The advantage is that when optimized for non-reliable use, the amount
of logic needed is less than Binary encoding, and it can be faster. One bit change with a SEU will result in a bad code which can be detected.
– The disadvantage is the increased number of bits results in more flip/flops and therefore more targets for SEUs. The SEU advantage is lost when the 1-hot encoding is optimized.
• The simplest encoding is Binary• In Binary encoding each state is given the next available binary
number in sequence.
10/14/2005 Caltech 25
Other SM Encoding- cont
• Grey-code– Similar to binary encoding, except the codes are
chosen so that in the main state-machine sequence only 1 bit changes at a time
– No major advantage over binary with this code. Decoded outputs from the state register can make use of the nature of the encoding to simplify producing a glitch free output.
10/14/2005 Caltech 26
Other SM Encoding- cont
• H2-code– This variation on Binary encoding uses one
extra bit to ensure all codes are separated by a Hamming distance of 2. That is, it will take 2 changes in the state register to reach another known state.
– The advantage is that it has less bits and so less SEU targets than 1-hot, but retains the fault tolerance of the un-optimized 1-hot encoding.
10/14/2005 Caltech 27
Other SM Encoding- cont
• H3-code– This extension on H2 encoding uses additional bits to
ensure all codes are separated by a Hamming distance of 3. That is, it will take 3 changes in the state register to reach another known state.
– The advantage is that the SM can be designed such that a single change in the state register has no effect on the state.
– The disadvantage is that it requires more logic to implement
10/14/2005 Caltech 28
Synthesis• To check the overhead of each of the state
machines, they were individually synthesized• Finite state machine optimization is turned off• A clock frequency of 50 MHz is used• Target device is a Xilinx Spartan 2, speed grade 6• Error injection circuitry is not included
10/14/2005 Caltech 29
Synthesis ResultsState
Machine Size
# Slice Flip
Flops
# of 4 input LUTs
Clock Period
(ns)
Max Synthesized Frequency
(MHz)
Minimum Period (ns)
4 3 8 20 226.6 4.48 4 22 20 133.5 7.5
12 5 41 20 124.5 8.016 5 49 20 117.8 8.524 6 84 20 91.5 10.932 6 107 20 87.3 11.5
4 5 15 20 162.8 6.18 6 42 20 117.4 8.5
12 7 55 20 105.0 9.516 7 71 20 102.6 9.824 9 91 20 88.7 11.332 9 137 20 83.5 12.0
Hamming 2
Hamming 3
State Machine
Size
# Slice Flip
Flops
# of 4 input LUTs
Clock Period
(ns)
Max Synthesized Frequency
(MHz)
Minimum Period
(ns)
4 2 7 20 272.1 3.78 3 15 20 178.8 5.6
12 4 25 20 129.6 7.716 4 38 20 122.1 8.224 5 50 20 109.6 9.132 5 96 20 94.5 10.6
4 4 10 20 238.2 4.28 8 20 20 194.8 5.1
32 12 31 20 173.0 5.816 16 41 20 148.9 6.724 24 63 20 148.9 6.732 32 237 20 68.6 14.6
Binary
One Hot
10/14/2005 Caltech 30
Four Bit State Encoding
4 Bit State Encoding
2
4
3
5
7
10
8
15
3.74.2 4.4
6.1
0
2
4
6
8
10
12
14
16
Binary One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 31
Eight Bit State Encoding
8 Bit State Encoding
3
8
4
6
15
20
22
15
5.6 5.1
7.58.5
0
5
10
15
20
25
Binary One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 32
Twelve Bit State Encoding
12 Bit State Encoding
4
12
57
25
31
41
55
7.75.8
8.0 9.5
0
10
20
30
40
50
60
Binary States One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 33
Sixteen Bit State Encoding
16 Bit State Encoding
4
16
57
3841
49
71
8.2 6.78.5 9.8
0
10
20
30
40
50
60
70
80
Binary One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 34
Twenty-Four Bit State Encoding
24 Bit State Encoding
5
24
69
50
91
9.1 6.710.9 11.3
63
84
0
10
20
30
40
50
60
70
80
90
100
Binary One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 35
Thirty-Two Bit State Encoding
32 Bit State Encoding
5 6 9
96107
137
14.6 11.5 12.032
237
10.6
0
50
100
150
200
250
Binary One Hot Hamming 2 Hamming 3
# of Slice Flip Flops
# of Four Input LUTs
Clock Period (ns)
10/14/2005 Caltech 36
Fault Injection Test
• A test circuit is generated with an example of each state machine executing the same task, plus a reference state machine
• The task chosen requires a16-state state machine, to detect a 16-bit pattern in a serial input stream
• An error generator injects faults into all state machines except the reference state machine
10/14/2005 Caltech 37
Error Injection Test Continued
• The outputs of each state machine are compared to the reference output
• A set of counters tallies the comparison outputs• 2 types of failure are logged for each state
machine:– Failure to detect pattern
– False detection of pattern (false-positive)
10/14/2005 Caltech 38
Error Injection Test Continued
• Non-key patterns are 1-bit different from the key pattern, to increase the likelihood of a false match
• Error rate can vary, set to 1:199 clocks in example• Errors are weighted by distributing them pseudo-randomly
over 16 bits. A state machine with a word size of n, receives n/16 of the total faults
• Synchronous fault injection is before the state register• Asynchronous fault injection is after the state register• All results are from actual implementation of the test
circuits in a Spartan 2 FPGA
10/14/2005 Caltech 39
Error Rate – Synchronous Faults Synchronous (rate=199)
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
0.1
Binary 1-Hot H2 H3
erro
rs p
er p
atte
rn single
false-pos single
double
false-pos double
10/14/2005 Caltech 40
Error Rate – Asynchronous Faults
Asynchronous (rate=199)
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
0.018
0.02
Binary 1-Hot H2 H3
erro
rs p
er p
atte
rn single
false-pos single
double
false-pos double
10/14/2005 Caltech 41
Error Rate – Asynchronous Pulse Faults
Pulse (rate=199)
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
0.018
Binary 1-Hot H2 H3
erro
rs p
er p
atte
rn single
false-pos single
double
false-pos double
10/14/2005 Caltech 42
Results: Binary Encoding
• Lowest resources used
• Second fastest speed after One Hot– Fastest for small number of states
• Second-most sensitive to errors
• Generates false-positive errors i.e. reports false pattern matches
10/14/2005 Caltech 43
Results: One Hot Encoding
• No false-positive errors (single faults)• Fastest speed except for small number of states
and large number of states• Uses more resources than Binary• Inefficient for large number of states• Worst fault tolerance of all encoding tested• Has 2x the error rate of binary encoding
10/14/2005 Caltech 44
Results: Hamming Distance of 2 (H2) Encoding
• No false-positive errors (single faults)
• Better Fault Tolerance than Binary
• More resources needed than One Hot, except for large number of states
10/14/2005 Caltech 45
Results: Hamming Distance of 3 (H3) Encoding
• Zero single-fault errors– Immune to synchronous and asynchronous
errors
• Lowest double-fault errors• Most resources used (*)
~2x binary encoding
• Slowest speed (*)(*) Except for large number of states