{"id":13003,"date":"2018-02-12T19:18:10","date_gmt":"2018-02-13T02:18:10","guid":{"rendered":"https:\/\/blogs.mentor.com\/verificationhorizons\/?p=13003"},"modified":"2026-03-27T08:38:33","modified_gmt":"2026-03-27T12:38:33","slug":"no-one-expects-gate-level-cdc-verification-and-glitch-detection-for-asic-signoff","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2018\/02\/12\/no-one-expects-gate-level-cdc-verification-and-glitch-detection-for-asic-signoff\/","title":{"rendered":"No One Expects Gate Level CDC Verification and Glitch Detection for ASIC Signoff!"},"content":{"rendered":"

[Preface: at the upcoming DVCon 2018 in San Jose, poster 4.12 addresses some of the issues raised below, as well as DVCon San Jose 2017 paper 12.3]<\/em><\/p>\n

There you are, satisfied that all of your tape out criteria were met: at the RTL level, every form of \u201ccoverage\u201d you could think of was applied, and 100% coverage scores were achieved across-the-board. Similarly, your RTL clock domain crossing (CDC) verification was clean. At the gate level, all the gate-level simulations (GLS) passed with flying colors, and weeks of static timing analysis (STA) came to a successful close.<\/p>\n

Yet here you are in the lab, hovering over samples that keep rebooting at seemingly random intervals since you first powered them up.<\/p>\n

“Why do bad things happen to good people?”<\/p>\n

“Why is this happening to ME?”<\/p>\n

“I wasn\u2019t expecting any errors or glitches \u2026”<\/p>\n

<<< CUE DRAMATIC ENTRANCE MUSIC >>><\/em><\/strong><\/p>\n

\"\"<\/a><\/p>\n

Sadly, this classic comedy reference is no joke for many of our customers: recently one D&V team found themselves in this exact situation, where samples of a chip destined for safety-critical applications was periodically hanging. Clearly the customer\u2019s customers would never accept such a device, and the window for their acceptance was rapidly closing. Bottom-line: if the re-spin didn\u2019t work, the sockets would be lost.<\/p>\n

So what can be done in this situation (and\/or what did the aforementioned customer do)?<\/p>\n

The solution lies in 3 steps, summarized by the following diagram:<\/p>\n

\"\"
\n<\/a><\/p>\n

Step 1: Make Sure RTL<\/strong> CDC is Clean<\/u><\/p>\n

First, CDC verification at the RTL level should be completely \u201cclean\u201d before doing any gate level analysis. In short, all waivers should be understood and reviewed by two separate engineers, and the synchronizer choices should be further validated for robustness with a dynamic CDC analysis that includes simulations with behavioral metastability models. The reason for this is relatively obvious: while RTL CDC verification of a large design can be a challenge, at least at the RTL level you can more easily see the relationships between the design and the verification results. But once the RTL is transformed into zillions of gates by a synthesis tool, it becomes much harder to sort through \u201cbit blasted\u201d logic, let alone the various signal name and topology changes.<\/p>\n

Step 2: Make Sure Gate Level<\/strong> CDC is Clean<\/u><\/p>\n

If RTL CDC verification was clean, wouldn\u2019t the chip be safe from any further CDC issues?\u00a0 Unfortunately, no. New, chip-killing CDC error paths and glitches can be introduced on signal paths that were perfectly safe at the RTL level. Rephrasing, if you think you are \u201csafe\u201d because the RTL CDC analysis was successful, you are actually still at risk. While this can happen at relatively \u201cbig\u201d nodes, in general our customers\u2019 experiences suggest these effects become a really big threat starting at 28nm and below. To greatly oversimply, the 28nm node seems to be the point where devices \u201crun out of bandwidth\u201d and expose more 2nd<\/sup> order effects like this.<\/p>\n

Fortunately, the DVCon 2017 paper 12.3 \u201cAccelerating CDC Verification Closure on Gate-Level Designs<\/em>\u201d, by my colleagues Anwesha Choudhury and Ashish Hari<\/a>\u00a0describes these issues in more detail, and shows how an exhaustive, formal-based gate-level CDC analysis provided by Questa Signoff CDC<\/a> can eliminate these problems.<\/p>\n

Step 3: Run an exhaustive, formal-based, gate-level glitch-detection analysis<\/u><\/p>\n

Unfortunately another round of CDC analysis at the gate level isn\u2019t enough: as noted above, glitch detection is also needed since synthesis can also introduce glitch-y signal paths. This typically occurs in-and-around the \u201cde-mux\u201d logic between clock domains and synchronization logic, or the synthesis tool itself inadvertently disrupts the synchronizer logic by being overly aggressive in applying optimizations.<\/p>\n

As you might imagine, finding these glitches among 100’s of millions of signal paths and gates is like finding a needle in a haystack. As Jackie Hsiung of Mediatek Inc., and my colleagues Sulabh Kumar Khare and Ashish Hari describe in the upcoming DVCon poster P4.12 \u201cPreventing Chip-Killing Glitches on CDC Paths with Automated Formal Analysis<\/em>\u201d<\/a>, they show how an automated formal approach, combined with advanced heuristics, has been delivering \u201clow noise\u201d results on seven real world-SoCs projects.<\/p>\n

 <\/p>\n

The happy ending to this whole sketch is that the above 3 steps work in the real world. In the case study mentioned at the beginning, the customer used Questa Signoff CDC<\/a> to find 3 glitches among millions of signals. One of the glitch sources found was one that they had suspected; but the other two were a complete surprise. The requisite ECOs were implemented, the design was re-verified from end-to-end, and the re-spun samples worked perfectly! (And these engineers no longer fear menacing, red-robed characters bursting into their lab unannounced.)<\/p>\n

 <\/p>\n

Until we meet at the upcoming DVCon, may your CDC paths be properly synchronized, and your signaling be free of glitches.<\/p>\n

 <\/p>\n

Joe Hupcey III,
\nfor the Questa CDC team<\/p>\n

 <\/p>\n

Reference links:<\/strong><\/p>\n

DVCon 2017, paper 12.3 \u201cAccelerating CDC Verification Closure on Gate-Level Designs<\/em>\u201d, Anwesha Choudhury and Ashish Hari, Mentor – A Siemens Business\u00a0<\/a><\/p>\n

 <\/p>\n

DVCon 2018, poster P4.12, \u201cPreventing Chip-Killing Glitches on CDC Paths with Automated Formal Analysis<\/em>\u201d, by Jackie Hsiung, Mediatek Inc., Sulabh Kumar Khare, Mentor- A Siemens Business, and Ashish Hari, Mentor- A Siemens Business<\/a><\/p>\n

 <\/p>\n

Questa Signoff CDC product overview<\/a><\/p>\n

 <\/p>\n

Related: On-demand webinar addressing dynamic CDC analysis: What Is CDC Protocol Verification, and Why You Absolutely Need It To Prevent Bugs in Your Silicon<\/em>\u00a0<\/a><\/p>\n

 <\/p>\n

Video of the classic Monty Python \u201cSpanish Inquisition\u201d sketch\u00a0<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

[Preface: at the upcoming DVCon 2018 in San Jose, poster 4.12 addresses some of the issues raised below, as well…<\/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":[333,375,401,448,450,511,513,650,660,669,690,716,731],"industry":[],"product":[],"coauthors":[],"class_list":["post-13003","post","type-post","status-publish","format-standard","hentry","category-news","tag-advanced-nodes","tag-cdc","tag-coverage","tag-dvcon-u-s","tag-dynamic-cdc-analysis","tag-glitch-detection","tag-gls","tag-protocol-verification","tag-questa-cdc-fx","tag-questa-signoff-cdc","tag-rtl","tag-signoff","tag-sta"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13003","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=13003"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13003\/revisions"}],"predecessor-version":[{"id":19852,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/13003\/revisions\/19852"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=13003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=13003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=13003"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=13003"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=13003"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=13003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}