Poorly designed clock-domain crossings kill chips. They kill products. They slip through simulation, are elusive in hardware validation, and can masquerade as other issues. The designer is held accountable for the results, and if not careful can be left in the lab for long nights of frustrating debug - or worse. Like the age-old verification question "how do you know when you're done testing?" It's fair to ask the designer "how do you know when to stop looking for CDC issues?" But in this era of many clock and power domains, third party or legacy IP, and intense PPA pressure, rigorous design and reviews are simply not enough. So how much CDC checking is enough? In this session you will learn whether or not you might still have an asynchronous clock or reset issues lurking in your design, despite having identified the crossings, ensured synchronizers are present, and reviewed your code – or even already run CDC analysis, ensuring that all CDCs are solid.
What you will learn:
How to complete an incomplete CDC analysis
Whether or not you’re at risk for CDC issues in silicon even though the RTL checked out as clean
What reconvergence and protocol verification is
The difference between CDC and RDC and why it matters