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 2
June 20th, 2013 by Vaishnav Gorur, Sr. Applications Engineer
In Austin, at the 50th DAC earlier this month, I delivered a poster presentation on “Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures”. In this second blog in a series, I discuss a set of failures in a common clock domain crossing synchronizer.
The design used for this case study closely mirrors the CDC synchronization scheme shown earlier in Part 1. Two components of the scheme are represented generically in the schematic below. They are
A designer can use one of many techniques for implementing the generic components which can be considered as variables for design exploration.
The clock frequencies of the transmit and receive domains, specifically the ratio they imply and the relative reset release of the two clock domains can be considered as the System variables in this experiment.
On the following illustration, we show results from the Data Stability checks for the following configuration of the DUT:
For the Control Logic, we have chosen a repeating counter which holds the ‘Control’ signal valid for the second half of its count and the ‘Data’ signal for the full duration of the count.
For the Detector, we have chosen a low-to-high transition detect.
The Data Stability check results exhibit a non-monotonic trend as the counter value progressively increases for each clock frequency multiplier. There are intermediate PASSes at certain counter values and frequency multipliers.
The PASS outliers are situations where the data cannot be captured in the next receiving clock cycle AND where the data is not changing at the time of capture, both together indicative of a clean data CDC crossing.
Consider the PASS when the Tx clock frequency = 3Rx clock frequency and the counter value is 15. Since the test passed at a counter value of 15, there would be an assumed expectation that everything would continue to pass with an increased value of cycle count, but there is a failure at cycle count of 16. This occurs because, although the first transaction completes successfully, the second transaction occurs at a time when the data and the control can be changing at the same time, causing the receive flop to potentially become metastable.
This non-intuitive failure signature is valuable information to understand the behavior of the design at different frequency ratios and to not make an assumption that the design is robust with a counter value of 15.
Below we take a look at the failure waveforms at a counter value of 14.
The Control signal is held high by the counter during the second half of the total count of 14 (from 0x7 to 0xd).
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 since the Data signal exhibits single-cycle behavior rather than a multi-cycle behavior.
Next time we will look at the causes for the Fail when counter = 16 and then look at pulse width results when using both aligned or offset reset signals.