Ensuring the functional safety of a design has always been important in industries such as medical, automotive, communications, industrial and aerospace. As the pace of innovation in these industries has increased, and their use of electronics has grown, so has their use of FPGAs. This has made it increasingly important to carry over functional safety techniques used in ASICs to FPGA designs for these industries.<\/p>\n
Sharath Duraiswami, a corporate applications engineer at Synopsys, outlined some of the issues that designers need to address to improve the functional safety of PFGA based designs in a recent webinar. His presentation focused on mitigating the impact of single event transients, that is glitches on signal lines or in a memory fabric caused by an alpha particle or high-energy neutron strike. If such glitches are clocked into a synchronous element they can cause single-event upsets (SEUs) that corrupt the operation of finite state machines (FSMs), change logic values, register or SRAM contents, and even alter I\/O signals.<\/p>\n
The SEU problem is particularly critical in FPGAs, whose function is defined by programming. Different types of FPGA need different forms of mitigation, depending on whether they are programmed by Flash memory, antifuses or an SRAM array (see Figure 1).<\/p>\nNo URL for image<\/em>\n Various approaches are available to address these vulnerabilities, including techniques such as triple modular redundancy (TMR), I\/O replication, \u2018duplicate with compare\u2019 strategies for configuration memories, and the automated generation of \u2018safe\u2019 FSMs during synthesis in Synopsys\u2019 Synplify Premier tool.<\/p>\n TMR, unsurprisingly, involves implementing three instances of a critical circuit in a design, and then using voting logic to ensure that all three instances come to the same conclusion. To do this well, designers should ensure three things: that the outputs of the triplicated circuits are directly connected to the voting logic; that any clocks and any inputs to clocks driving such circuits are synchronised; and that you tell the synthesis tool not to optimise away any nets you add in to monitor errors, and any custom logic that is designed to mitigate errors.<\/p>\n Duraiswami also outlined three different forms of TMR. (See Figure 2)<\/p>\nNo URL for image<\/em>\n Deciding which to use means thinking through what sort of errors could be caused by errors in the block you are trying to protect, and how best to mitigate that impact.<\/p>\n Feedback correction is necessary because otherwise an erroneous output, caused an SEU in the output of one block of a TMR triplicate, could be held by its synchronous feedback loop and still present when an SEU in a second of the blocks also occurred, leading to an incorrect majority voter output. Synplify Premier can automatically add the voter output into the CE feedback loop, dealing with the issue.<\/p>\n There are various strategies available to protect the onchip block RAMs on an FPGA. These include using TMR; inferring the use of special ECC RAMs in some Altera, Xilinx and Microsemi parts; and designing monitors that can trigger the wiping and reloading of memory, especially configuration memory, when an error is detected.<\/p>\nNo URL for image<\/em>\n The registers in an FSM define how it is supposed to react to any given set of inputs. If one of the registers suffers an SEU, a couple of issues can arise: the first is that the FSM keep running but moves to the wrong next state; the second is that it enters a state that is completely unanticipated and locks up.<\/p>\n One way to address this problem is to use synthesis to create \u2018safe FSMs\u2019, which are structured to protect themselves against SEUs in a number of different ways. For example, it is possible to build FSMs that include Hamming coding to detect and correct errors. Error recovery is possible with \u2018safe FSMs\u2019, which are structured during the synthesis process to return to a reset state when an error is detected. The most sophisticated approach, though, is to use synthesis to build \u201csafe case FSMs\u2019, in which the designer specifies a \u2018default\u2019 state in the case statement of their RTL that contains a user-specified error-recovery scheme.<\/p>\n No URL for image<\/em> <\/em><\/p>\n SEUs at I\/Os can be detected and corrected by replicating the I\/Os or by applying distributed TMR strategies. In \u2018duplicate and compare\u2019 approaches, an error on an output pad can be mitigated by duplicating the module that drives the output, an the output pad itself. Error logic can be incorporated to flag the error for resolution.<\/p>\n A more advanced approach applied distributed TMR, triplicating the module that drives the output and triplicating the output itself. Any errors are corrected by majority voting.<\/p>\nNo URL for image<\/em>\n Duraiswami\u2019s webinar<\/a> has greater detail of the concepts behind each of these techniques, as well as details of how to use a combination of coding, synthesis commands and attributes in Synplify Premier, to control their implementation.<\/p>\n More on\u00a0designing for functional safety with FPGAs<\/a><\/p>\n More on\u00a0Synopsys’\u00a0Synplify Premier<\/a><\/p>\n Using triple modular redundancy, error detection and correction, and ‘safe’ FSMs to ensure greater functional safety in FPGA-based designs<\/p>\n","protected":false},"author":329,"featured_media":8519,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1242,1386,38],"tags":[1835,1797,1499,1605,1836,1837],"coauthors":[996],"class_list":["post-8508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecture-design","category-assembly-integration","category-ic-implementation","tag-ecc","tag-fpga-synthesis","tag-fsm","tag-functional-safety","tag-redundancy","tag-seu","workflow-featured","workflow-focus","workflow-technique","workflow-up-to-date"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/8508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/329"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=8508"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/8508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/8519"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=8508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=8508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=8508"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=8508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Triple modular redundancy<\/strong><\/h2>\n
\n
Protecting memories<\/strong><\/h2>\n
Protecting FSMs<\/strong><\/h2>\n
Mitigating I\/O pad errors<\/strong><\/h2>\n
Further information<\/b><\/h2>\n
<\/b>Company info<\/b><\/h2>\nSynopsys Corporate Headquarters<\/i><\/address>\n 690 East Middlefield Road<\/i><\/address>\nMountain View, CA 94043<\/i><\/address>\n(650) 584-5000<\/i><\/address>\n(800) 541-7737<\/i><\/address>\n\u00a0<\/i>www.synopsys.com<\/a><\/i><\/address>\n","protected":false},"excerpt":{"rendered":"