{"id":13102,"date":"2018-04-24T14:15:40","date_gmt":"2018-04-24T21:15:40","guid":{"rendered":"https:\/\/blogs.mentor.com\/verificationhorizons\/?p=13102"},"modified":"2026-03-27T08:38:46","modified_gmt":"2026-03-27T12:38:46","slug":"significantly-improve-your-fpga-design-reliability-by-using-custom-cdc-synchronizers","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2018\/04\/24\/significantly-improve-your-fpga-design-reliability-by-using-custom-cdc-synchronizers\/","title":{"rendered":"Significantly Improve Your FPGA Design Reliability by Using Custom CDC Synchronizers"},"content":{"rendered":"

[Preface: we are presenting a paper on this topic at the upcoming SEE\/MAPLD conference, May 21-24, 2018 in La Jolla, CA<\/a> \u2013 Join us!]<\/em><\/p>\n

Today\u2019s FPGA designs include multiple cores, interfaces, test logic, and even different internal power and voltage domains. In particular, the multiple asynchronous clocks, and the signals crossing between asynchronous clock domains, may result in functional errors. Specifically, when a signal from one asynchronous clock domain is sampled by a register on a different asynchronous clock domain, the setup\/hold timing requirement will be violated for the destination register. This setup\/hold timing violation means that the destination register will probably become metastable, so the destination register will settle to an unpredictable value and cause a functional error. To address this, FPGA designers add synchronization logic to prevent the propagation of metastable events.<\/p>\n

However, the standard \u201c2 D flip-flop\u201d synchronizer might not always do the job, especially if common pitfalls in positioning the synchronizer in the circuit aren\u2019t avoided. The negative effects are only compounded when the FPGA is going into a challenging operating environment (e.g. continuous exposure to high radiation in space). Consequently, any resulting CDC errors that slip through can lead to intermittent failures that may only manifest themselves in specific operating conditions that may not come up in the lab, and would only be found in certain field conditions. Fortunately, there are easy and effective solutions \u2026<\/p>\n

The Common 2 DFF Synchronizer vs. a \u201cCustom Sync\u201d<\/strong><\/p>\n

The simplest synchronization structure is a \u201c2DFF\u201d synchronizer (Figure 1 below) \u2013 literally two D flip-flops in a row. Unfortunately, designers often mistakenly drive this synchronizer with combinational logic (Figure 2). The result is that the combinational logic will transmit any glitches into the synchronizer, thus reducing the mean time between failure (MTBF) of the synchronizer; and hence the reliability of whole circuit. These CDC mistakes also apply to more complex synchronization structures such as DMUX and handshake synchronizers.<\/p>\n

\"Figure<\/a>
Figure 1: 2DFF Synchronizer<\/figcaption><\/figure>\n
\"Figure<\/a>
Figure 2: Combinational Logic Violation<\/figcaption><\/figure>\n

The good news is that this is relatively easy to avoid with a custom synchronizer methodology for the design and verification of clock domain crossing (CDC) logic in FPGA designs. The idea is to leverage the CDC tool to identify all the points where synchronizers need to be inserted, then put-in a more robust CDC synchronizer structure of your own creation, or from IP vendor library. Either way, the industry jargon here is that you are employing \u201ccustom sync\u201d logic.<\/p>\n

In Questa CDC<\/a>, the custom synchronizer specification command (Figure 3 below) is how users can declare pre-verified synchronization structures, and also tell Questa CDC<\/a> to check that this custom synchronizer is being properly used. In parallel, Questa CDC<\/a> will flag manually inserted RTL-based CDC synchronizers as an error. This effectively forces the designers to use the chosen, \u201csafer\u201d custom sync circuitry.<\/p>\n

\"Figure<\/a>
Figure 3: Custom Synchronizer Declaration<\/figcaption><\/figure>\n


\n<\/a>The Gory Details<\/strong><\/p>\n

By utilizing the custom synchronizer methodology, there are 3 safeguards that can be incorporated to protect against CDC errors:<\/p>\n

    \n
  1. Add protective logic into the CDC library structure<\/li>\n
  2. Specify assumption checks in the custom synchronizer specification<\/li>\n
  3. Declare CDC library structures as synchronizer modules<\/li>\n<\/ol>\n

    In developing a CDC synchronizer library, project teams can add these safeguards to the CDC library structures to prevent incorrect synchronizer block usage. Specifically, one technique is to include a transmit register in the library block (Figure 4 below) to avoid combinational logic violations (again, as in Figure 2 above). By adding the transmit register into the synchronizer block, this will prevent designers from adding combinational logic between the clk_A register and the 2DFF synchronizer. (Caveat: the downside of adding the protection register is that redundant registers may be included in CDC paths when designers register the data into the library synchronizer block.)<\/p>\n

    \"Figure<\/a>
    Figure 4: Synchronizer Structure with Transmit Register<\/figcaption><\/figure>\n

    Another strategy for ensuring correct synchronizer usage is to specify safeguards when defining the custom synchronizer specification. Although designers can allow CDC tools to infer the constraints for a custom synchronizer, it is safest for designers to explicitly declare the constraints for custom synchronizers. Indeed, a complete custom synchronizer specification includes both constraints defining the internal logic as well as the external assumptions for the synchronizer block usage (Figure 5).<\/p>\n

    \"Figure<\/a>
    Figure 5: Custom Synchronizer Constraint and Assumption<\/figcaption><\/figure>\n

    The constraints for synchronizer block include the clock domain information for the input and output ports based on the input port destination or the output port source. An important external assumption for the synchronizer block is a \u201cno combinational logic\u201d rule for the driving logic of an input port \u2013 it is an automatic check to see if a synchronizer is driven by combinational logic, flagging an error if this rule is violated. One advantage to this approach is that no time is wasted re-checking the pre-verified synchronizer block — only the external connections to the custom synchronizer are checked.<\/p>\n

    A third option is to add a specification constraint for the synchronizer library block. Instead of specifying the synchronizer library block as a custom synchronizer, a designer can declare the synchronizer as a designated synchronizer module (Figure 6). This designation will both check that the internal synchronizer block logic is correct as well as flag a violation when any RTL-based synchronizer structure is used. The disadvantage of this approach in comparison to the custom synchronizer approach is that the same pre-verified structure will be verified multiple times and this may impact CDC analysis performance.<\/p>\n

    \"Figure<\/a>
    Figure 6: Synchronizer Module Specification<\/figcaption><\/figure>\n

    With the increase in asynchronous clocks in today\u2019s hardware designs, CDC errors are the second-leading cause of both FPGA and ASIC design re-spins [1]. Advanced CDC methodologies, such as this custom synchronizer flow, allow design teams to eliminate CDC errors.<\/p>\n

    Kurt Takara, Chris Kwok, Dominic Lucido, and Joe Hupcey III
    \nfor the Questa CDC Team<\/p>\n

    References<\/h2>\n

    [1] Wilson Research Group and Mentor Graphics, \u201c2016 Functional Verification Study\u201d, July 2016.<\/p>\n

    https:\/\/blogs.mentor.com\/verificationhorizons\/blog\/2016\/12\/02\/part-12-the-2016-wilson-research-group-functional-verification-study\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    [Preface: we are presenting a paper on this topic at the upcoming SEE\/MAPLD conference, May 21-24, 2018 in La Jolla,…<\/p>\n","protected":false},"author":71594,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[375,377,407,425,496,659],"industry":[],"product":[],"coauthors":[],"class_list":["post-13102","post","type-post","status-publish","format-standard","hentry","category-news","tag-cdc","tag-cdc-verification","tag-custom-synch","tag-deep-space-circuit-design","tag-fpga","tag-questa-cdc"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/71594"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=13102"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13102\/revisions"}],"predecessor-version":[{"id":19858,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13102\/revisions\/19858"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=13102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=13102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=13102"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=13102"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=13102"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=13102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}