Vendor Independent SEE Mitigation Solution For FPGAs Kamesh Ramani Pravin Bhandakkar Darren Zacher Melanie Berg (MEI

1
Vendor Independent SEE Mitigation Solution For
FPGAs Kamesh RamaniPravin BhandakkarDarren
ZacherMelanie Berg (MEI NASA Goddard)
2
Agenda

• Vendor Independent solution
• Flow
• Advantages
• TMR Techniques
• Handling of special cases
• DRC and max fanout violation
• Constraint handling
• Formal Verification interface
• User controls

3
Vendor Independent Flow
Control inference of ROM/RAM, Shift Registers,
DSPs
RTL
Regular Synthesis
TMR
TMR related synthesis controls
Constraints
PNR
EDIF
Regular options
Switches
Switch off Netlist Optimizations
TMR Options
Based on Scheme perform TMR on design and check
for DRC rules
Select Technology
4
Synthesis From RTL to EDIF
Post TMR Processing
TMR PNR Interaction
SEU related controls during synthesis
TMR
TMR
TMR DRC Processing TMR Max Fanout Processing
TMR Related PNR options
Block RAM inference and resource control
Recognizing Combinational loops
Recognize TMR related attributes In the RTL
Control not to infer Distributed RAM
Formal Verification infrastructure
Inference of Safe FSMs
DSP Inference, resource control No MAC
inference No Counter inference Control on Flop
absorption
Constraints handling infrastructure
SRL inference can be controlled
5
Vendor Independent Flow

• Regular flow from RTL to synthesized Netlist and
  then to PNR
• TMR can be applied on any chosen technology and
  device
• Various optimizations for RadHard protection can
  be incorporated during synthesis itself
• Output can be formally verified
• against RTL
• against non-TMR netlist
• Special mitigation solution during synthesis for
• DSPs, Black Boxes, RAMs, SRLs

6
Vendor Independent FlowAdvantages

• Formally verifiable against RTL and non TMR
  netlist
• Can be applied on any FPGA vendor chip
• Can be applied on newer technology FPGAs
  seamlessly
• Control throughout the synthesis flow to perform
  radiation related optimizations and choices
• Controls at module level is available
• Special handling for different technology cells
• Ability to plug in dedicated RadHard modules for
  different inferred components
• Can fix DRC and maxfanout violations effectively
  after TMR
• Can seamlessly generate appropriate constraints,
  attributes, area and frequency reports for TMR
  netlist

7
Voters

• Voters
• We define voters to be circuits that take in the
  output from triplicated flops and resolve it
  based on either majority or minority
• We choose to use majority voters
• Equation AB BC CA
• Voters utilize combinatorial cells specific to
  target technology
• LUTs in SRAM-based devices
• MAJ3 in antifuse-based devices

8
Various TMR Strategies - LTMR

• Local TMR (LTMR) 1
• Triplicate sequential elements only, and majority
  vote the outputs
• Flip-flops, shift registers, block RAMs, and
  sequential DSPs
• The input data, control signals and clock will be
  shared by the triplicated flops
• Reduces SEE occurrence to frequency dependent SET
  capture clock trees, global routes and IOs are
  still susceptible
• 1 M. Berg, Design for Radiation Effects,
  Invited Talk Presented 2008 at Military and
  Aerospace Programmable Logic Design, MAPLD,
  Annapolis, MD, September. 2008

9
Various TMR Strategies - LTMR
LTMR
10
Various TMR Strategies - DTMR

• Distributed TMR (DTMR) 1
• Apply TMR on sequential and combinational logic
• Triplicate sequential and combinatorial logic
  global routes and I/O are not triplicated
• Vote out the triplicated logic just after the
  sequential elements
• Triplicate the majority voting circuit as well to
  protect SET effects on the voting circuit
• Reduces SEE occurrence clock trees, global
  routes and IOs are still susceptible
• Preferrable scheme for SEU and SET protection of
  technologies with hardened clock trees

11
Various TMR Strategies - DTMR
DTMR
12
Various TMR Strategies - GTMR

• Global TMR (GTMR) 1
• Apply TMR on the entire design including global
  buffers
• Triplicate the sequential elements, combinational
  logic, voters and the global buffers
• Voters converge the triplicated flop outputs at
  clock and control domain crossovers
• This gives very high level of radiation
  protection
• This scheme requires that the triplicated global
  lines have minimum skew between them
• Preferred scheme for commercial SRAM based FPGAs

13
Various TMR Strategies - GTMR
GTMR
14
Special Case Handling Overview

• In vendor independent flow we can handle embedded
  resources effectively
• Tech cells such as RAMs, DSPs, Shift registers
  etc
• Need to triplicate and vote datapath can limit
  usage
• Ability to control automated embedded resource
  inference
• To Selectively infer
• To infer with restricted features
• Synthesis tool decides embedded resource
  allocation earlier in the implementation flow
• Enables more effective TMR application.
• Gives better control over synthesis for radiation
  hardening

15
Embedded Resource Handling

• Embedded RAM
• Triplicated and voters are inserted at each
  output
• Treated as sequential elements and will be TMRed
  in all the schemes
• The user can instantiate an error correcting
  (EDAC) RAM
• Supply black box or netlist IP, or set an
  attribute on the instance
• Instance will be treated like a black box or IP
  and not triplicated

16
Embedded Resource Handling

• Embedded Shift Registers (e.g. SRL)
• By default, embedded shift registers will not be
  inferred during synthesis
• User has option to enable shift register
  inference if desired
• If present in the design, embedded shift
  registers are triplicated and a voter is inserted
  at the output

17
Embedded Resource Handling

• DSP
• DSPs can be classified for TMR broadly into
• Sequential DSPs
• Combinational DSPs
• Sequential DSPs
• Contain Flops in them
• Flops can be at the input, output or as pipeline
  registers
• Infer DSPs with only flops at the output by
  default
• These DSPs will be triplicated and voters
  inserted at every output
• Scan chain facilities in these DSPs will not be
  used as we cannot insert voters at their outputs

18
Embedded Resource Handling

• DSPs
• Combinational DSPs
• These contain only combinational logic
• Will be triplicated and voted out in DTMR and
  GTMR schemes only
• Multiply-Accumulate (MAC)
• MACs will not be inferred
• They contain loops and can potentially get stuck
  after a fault
• Hence the loop will be outside the DSP so that
  voters can be inserted in the loop to correct SEUs

19
Special Case Handling

• I/O Boundary Flops
• Flops at input and output may need special
  handling based on the TMR scheme
• LTMR
• The inputs to the TMRed design will fanout to
  triplicated flop instances
• The output flops will also have a voter at its
  output similar to other flops in the design.
• If user wishes, by using regular synthesis
  attributes can absorb the flops into the pads
• Flop not triplicated when absorbed into the pad

20
Special Case Handling I/O Boundary Flops

• DTMR and GTMR
• The inputs to the TMRed design will fanout to
  triplicated design
• The outputs from the TMRed design will converge
  at output flops
• Voters need to be applied at the output flops to
  converge the output
• If user wishes, by using regular synthesis
  attributes can absorb the flops into the pads
• Flop not triplicated when absorbed into the pad
• Can choose to triplicate pins on top level
• Each of the triplicated outputs can be voted
• Or user can choose to absorb flops, without
  voting, into pads using normal synthesis
  attributes

21
Special Case Handling

• Boxes
• By boxes we mean black, white, grey, clear etc
• Need to be mitigated by the user, as there is
  either no or limited visibility inside them
• All inputs to the box will converge at the box
  input boundary
• A voter will be inserted before each box input
• All outputs from box will fanout to triplicated
  instances
• Tool will fix and report any max fanout violation
  at box outputs

22
Special Case Handling

• Latches
• Latches are treated similar to sequential
  elements
• If a latch is present we will always triplicate
  it and insert voters at the output
• This is because latches contain loops which have
  the ability to retain faults

23
Special Case Handling

• Combinational Loops
• Combinational loops should be avoided in a design
  targeted for mitigation
• However if combinational loop is present, we will
  insert a voter at the point of feed back
• We will also warn the user about the
  combinational loop as well

24
Special Case Handling

• Clock generation circuits
• Clock generation circuits such as PLLs, DCM etc
  are susceptible to SEEs and should be avoided
• We warn the user about these circuits
• We do not triplicate these, nor vote them out

25
Design Rule Check (DRC) violations

• TMR on some cells can cause DRC violations
• Inserting voters between cascade pins of embedded
  resources is generally not allowed
• Block RAM cascading
• DSP cascading
• Scan chain feature of DSPs
• The violations are handled by
• not cascading the embedded resources or
• using the appropriate non-cascade input and
  output pins of those resources
• Global buffers such as those with pads cannot be
  triplicated
• To triplicate them we split them into pad cell
  and buffer cell
• Buffer cells are then triplicated
• Flow advantage preventive steps can be taken
  during synthesis

26
Max fanout violations

• Potential TMR violations occur at
• Input nets that feed triplicated logic
• Black box outputs
• Flop inputs in LTMR
• Flow advantage Since TMR is part of the
  synthesis flow such violations are detected and
  fixed

27
Constraints Handling

• Constraints on original instance copied to
  triplicated instances
• Constraints on flop output is transferred to
  voter output(s)
• Appropriate constraints are written out at the
  end of synthesis for the TMRed design as a whole
• Flow advantages
• Constraints are applied seamlessly throughout the
  TMRed design
• No need of post processing constraints after
  synthesis

28
Formal Verification RTL vs. TMR Netlist

• Novel approach regarding TMR insertion
• Formal Verification of Advanced Synthesis
  Optimizations, Anant Kumar Jain et al, MAPLD-09
• Formal Verification Interface (FVI) constraints
  for triplicated instances generated
• This assists FormalPro in verifying the generated
  netlist against RTL
• Flow advantages
• FVI constraints are automatically generated
  during synthesis
• Post-TMR netlist can be easily verified

29
Formal Verification TMR Netlist vs. Non TMR
Netlist

• FVI matching rules are generated during synthesis
• Matching rules helps to identify instance in
  normal netlist with its triplicated counterparts
  in the TMRed netlist
• Flow advantages
• FVI matching rules are automatically generated
  during synthesis
• Post-TMR netlist can be easily verified

30
Module Level User Controls

• Ability to apply different TMR techniques on
  different modules
• Allows TMR application on an as-needed basis for
  a given module
• Voters converge the triplicated flop outputs on
  the module boundaries with lesser TMR protection
• Using attributes can specify TMR scheme on a
• given instance in RTL
• On all instances of a given module in RTL
• TMR scheme is inherited through the hierarchy
• Flow advantages
• Control at the RTL level
• Beneficial for design review
• Greater flexibility to the user

31
Additional User Controls

• Voter insertion
• Force Voter Insertion on net or nets drivers
  output if specified
• Can be specified using an attribute
• Triplication control
• Specify a given instance not be triplicated
• Can be specified using an attribute

32
Summary

• Flow implemented as part of Precision synthesis
  tool
• TMR output netlist formally verifiable against
  RTL and non TMR netlist
• TMR can be applied on any FPGA vendor chip
• TMR can be applied on newer technology FPGAs
  seamlessly
• Controls available throughout the synthesis flow
  to perform mitigation related optimizations and
  choices
• TMR netlist is free of any DRC and maxfanout
  violations
• Constraints, attributes, area and frequency
  reports for TMR netlist are automatically
  generated.