Open side-bar Menu
 Real Talk
Vaishnav Gorur, Sr. Applications Engineer
Vaishnav Gorur, Sr. Applications Engineer
Prior to joining Real Intent, Vaishnav was a logic design engineer at MIPS Technologies where he was responsible for the microarchitecture and RTL Design of the Load-Store Unit and Graduation Unit of the 15-stage out-of-order asymmetric dual-issue superscalar pipeline in the MIPS32® 74K® fully … More »

Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures — Part 3

July 4th, 2013 by Vaishnav Gorur, Sr. Applications Engineer

In Austin, at the 50th DAC in June,  I delivered a poster presentation on “Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures”.   In this final blog in a series, I discuss the causes for a failure when the counter value of the control logic equals 16 and then look at pulse width results when using both aligned or offset reset signals.

Following a FAIL with counter = 14 and a PASS with counter = 15, here we take a look at a FAIL with counter = 16.

The Control signal is held high by the counter during the second half of the total count of 16 (from 0x8 to 0xf).

Note that when Mux-on is high, the mux is open and the Data signal gets captured in the Rx Data flop.

Take a look at the signals in the vicinity of the two vertical dotted lines on the right. The first dotted line aligns with a change in the Data signal which happens when the counter wraps. Since the mux is open (Mux-on is high) the Data is captured by the Rx Data flop on the first receive clock edge following the change in Data. This is marked by the second dotted line and is a Data Stability failure.

Note that, in order to produce a failing trace in this case, the counter needs to wrap around twice. In order to understand why there is no Data Stability failure in the first full count of the counter, take a look at the Grey oval in the waveforms. When the mux is open (when Mux=on is high), note that the Data remains stable and is not changing. Hence there is no Data Stability issue here.

Following a FAIL with counter = 14 and a PASS with counter = 15, one could expect that there will be passes from counter = 15 onwards. However, as shown below, there is a non-intuitive non-monotonic pattern in play here with a FAIL when counter = 16.

Until now, the examples we have discussed involved aligned resets. Let us revisit Pulse Width checks now with offset resets.

When the reset releases of the transmit and receive domains are aligned, the Pulse Width check results follow an intuitive, monotonic pattern as shown earlier. However, when the resets releases are offset, a non-monotonic pattern emerges for the Pulse Width checks as well.

This has to do with the alignment of the pulse with respect to the receive clock edges. This non-intuitive failure signature is valuable information to understand the behavior of the design when the reset timing is altered and to not make an assumption that the CDC structures in the design are immune to the reset release timing.

Design exploration enables designers to future-proof their designs by making them parameterizable. They can then be easily reconfigured to work across a wide range of frequency ratios.

This exploration also helps the understanding of legacy designs and identifying the range of frequencies in which that design can be safely reused for future projects.

CDC-related design trends require use of dedicated CDC tools and a re-evaluation of current  CDC verification methodology, flows and practices.

The use of automatic formal CDC verification in a case-study involving a common synchronization scheme revealed a non-intuitive failure signature.

Moving CDC verification partly to the design teams has numerous benefits including enhanced productivity, reduced verification complexity and shorter time-to-product.

In this blog series, we have identified parts of the CDC verification problem that are amenable to verification by digital design engineers and highlighted the cases where a non-intuitive failure signature was exposed by the use of formal analysis. We showed how these failure signatures can be used to improve design quality and to bolster the verification suite. Additionally, we also discussed how the knowledge gained from this exercise can help design engineers make their designs future-proof, a much desired trait in this age of heavy design reuse. Designers lending a ‘formal’ hand to verification engineers enhances productivity, reduces product cycles and helps meet aggressive time-to-market deadlines.

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series
S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy