outline Reliable State Machines MER Mission example

Transcription

1 outline Reliable State Machines Dr. Gary R Burke California Institute of Technology Jet Propulsion Laboratory Background JPL MER example JPL FPGA/ASIC Process Procedure Guidelines State machines Traditional Highly Reliable Comparison 1/1/2 Caltech 1 1/1/2 Caltech 2 1/1/2 Caltech 3 1/1/2 Caltech 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. 1/1/2 Caltech 1/1/2 Caltech 6 1

2 1/1/2 Caltech 7 1/1/2 Caltech 8 1/1/2 Caltech 9 1/1/2 Caltech 1 1/1/2 Caltech 11 1/1/2 Caltech 12 2

3 ASIC Design Process GRB - 2/1/ STA RT Inputs outputs process Spec ific ation: Level Requirements CM plan Test approach Create. design. Test Approach. ASIC/FPGA/ package selection. Configuration management Review plan Select Foundry Partition Design Specify IPs FT approach IDR Review Proto Board Design Firmw are Design: HDL Des ign: Analog Circuit Des ign: PDR Rev iew Proto Board Test Firmw are Compilation Structural design: Analog Layout Des ign: Structural Des ign sign-off Physical Design: RTL code, Structural code CM plan Updated Test approach Structural code Test vectors RTL code, Layout netlist Updated V-matrix Physical Conceptual Synthesis Design RTL Design; PDR Design Timing analysis Structural & RTL simulation Is ASIC Peer testability Design Physical Design: Requiremen DFT;simulation coverage Ready to review Prototype; ATPG Peer Place and Route ts V test bench & modeling procede and Vendor software Review Timing analysis BA Review Trial Synthesis with sign-off Gate level and Update Prototype Is ASIC Trial Timing analysis structural verification Sign-off BA ready to Trial testability anal. design? Firmware design Vendor software procede Test vectors BA with Initial Firmware design TV coverage Gate level detailed SEU mitigation plan Trial P&R verification BA design? Fault tolerant plan Prototype FPGA Lint verification Formal Verification pinout defined code walkthrough Ph ys ica l Des ign sign-off Complete Layout:: Chip layout Review Checklist Complete Layout:: Chip integration DRC Review: Is LVS ASIC ready ERC for fabrication? chip fabrica tion 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 1/1/2 Caltech 13 1/1/2 Caltech 1 FPGA/ASIC Process To ensure a quality product: Requirements are correct and do not change is complete Design will meet the specification and requirements Testing has covered all possible cases 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 1/1/2 Caltech 1 1/1/2 Caltech 16 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 ASIC PROCESS 1/1/2 Caltech 17 1/1/2 Caltech 18 3

4 FPGA Design Process GRB - 2/1/ START Inputs outputs process : IDR Review Firmw are Design: HDL Design: Prot-board design PDR Re v ie w Firmw are Verification FPGA Prototype design: Proto-Board Test RTL code, Level Requirements CM plan Updated Test approach RTL code, Configuration code CM plan Updated Test approach Conceptual Create Synthesis Design HDL Design;. Timing analysis & HDL simulation Is FPGA Implementation Requiremen DFT;simulation coverage testability Ready to Partition and Prototype ts V test bench & modeling procede Test Approach. FPGA software Review Trial Synthesis with FPGA device Gate level Is FPGA Trial Timing analysis synthesis? and package verification ready to selection. procede Initial Firmware design Firmware design Configuration Test vectors with SEU mitigation plan management TV coverage detailed Fault tolerant plan Schedule with Prototype FPGA design? Lint verification Plan for Reviews pinout defined Specify IPs code walkthrough FT approach prot-board design FPGA Final Build Configuration code Verification matrix; Test vectors Checklist Review: Is Physical Design: flight FPGA Place and Route ready for Timing analysis personalizat Update Prototype ion? Vendor software System Test FPGA fuse programming FPGA PROCESS Guidelines Define set of rules for HDL design Reduce ambiguity Clarify design to be easily checked and reviewed Implement most reliable design techniques 1/1/2 Caltech 19 1/1/2 Caltech 2 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 1/1/2 Caltech 21 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 1/1/2 Caltech 22 State-Machine (SM) Encoding Other 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. 1/1/2 Caltech 23 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 ) 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. 1/1/2 Caltech 2

5 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. 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. 1/1/2 Caltech 2 1/1/2 Caltech 26 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 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 MHz is used Target device is a Xilinx Spartan 2, speed grade 6 Error injection circuitry is not included 1/1/2 Caltech 27 1/1/2 Caltech 28 Synthesis Results Four Bit State Encoding State # Slice # of Clock Max Minimum State # Slice # of Clock Max Minimum Machine Flip input Period Synthesized Period Machine Flip input Period Synthesized Period (ns) Size Flops LUTs (ns) Frequency (MHz) (ns) Size Flops LUTs (ns) Frequency (MHz) Bit State Encoding Binary Hamming One Hot Hamming /1/2 Caltech 29 1/1/2 Caltech 3

6 Eight Bit State Encoding Twelve Bit State Encoding 8 Bit State Encoding 12 Bit State Encoding Binary States One Hot Hamming 2 Hamming 3 1/1/2 Caltech 31 1/1/2 Caltech 32 Sixteen Bit State Encoding Twenty-Four Bit State Encoding 16 Bit State Encoding 2 Bit State Encoding /1/2 Caltech 33 1/1/2 Caltech 3 Thirty-Two Bit State Encoding Fault Injection Test Bit State Encoding 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 1/1/2 Caltech 3 1/1/2 Caltech 36 6

7 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) 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 1/1/2 Caltech 37 1/1/2 Caltech 38 Error Rate Synchronous Faults Error Rate Asynchronous Faults Synchronous (rate=199).1 Asynchronous (rate=199) errors per pattern single false-pos single double false-pos double errors per pattern single false-pos single double false-pos double Binary 1-Hot H2 H3 Binary 1-Hot H2 H3 1/1/2 Caltech 39 1/1/2 Caltech Error Rate Asynchronous Pulse Faults Results: Binary Encoding errors per pattern Pulse (rate=199) single false-pos single double false-pos double 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 Binary 1-Hot H2 H3 1/1/2 Caltech 1 1/1/2 Caltech 2 7

8 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 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 1/1/2 Caltech 3 1/1/2 Caltech 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 1/1/2 Caltech 8