We all know how crucial the Clock Domain Crossing (CDC) topic is. Almost every chip design in the world needs CDC analysis these days. It’s a good idea to have both the theoretical knowledge and the practical skills behind the CDC.
There are quite a few CDC tools available in the market by Synopsys, Cadence etc., but all of them do the same job – looks out for bad CDC design practices in your RTL. These tools are nothing but a collection of rules against which your RTL is analyzed, just like Lint.
Although there can be hundreds of such rules (rules can be enable or disabled, it depends on the company and the type of project), in this article, we will discuss few basic but very important rules. Before jumping straight to rules though, we must first understand how the tool operates.
Since even the smallest partition in a chip now-a-days is very big, the tool works in stages. Each stage does something different. The stages are designed in such a way that if stage 1 is failing, there is no point in running stage 2, it saves us a lot of time. We can resolve the issues in stage 1 and then move over to the next stage. Typically, the tool will have stages like these (mind you, this can change from tool-to-tool and company-to-company):
Setup check – The tool checks if all the paths provided for RTL, clock constraints, and other collaterals are valid or not, all clocks and resets are defined or not, all clock domains are defined or not and stuff like that.
Structural check – Tool will look for signals crossing clock or reset domain and check if there is proper synchronization method used or not depending on single-bit or multi-bit signals, it will search for possible glitches, etc.
Functional check – Tool checks if after synchronization, correct data is read in receiving domain or not.
If you read about these stages carefully, you will notice that it is indeed useless and sometimes not even possible to run the next stage until the current stage is not passing.
Now let’s talk about some rules. Some of these rules are info (no need to fix), some are warning (good if you fix), and some are errors (must fix). These rules can fall in any one of the stages mentioned above.
Black box setup check – This checks if the modules which are defined as blackboxes have proper constraints on their ports or not.
Reset check – This reports sequential elements that do not get active reset during power on.
Clock check – Reports clock signals converging on a MUX.
Ports check – This reports unconstrained ports for top DUT.
Glitch check – Reports CDC signals subject to glitches.
Convergence check – Checks signals that are synchronized separately but are being used in same logic in receiving domain.
Unsync clock check – Checks for bits and buses that are unsynchronized.
Unsync reset check – Reports unsynchronized reset signals in the design.
Quasi static check – Reports quasi static signals in the design.
Data hold check – Verifies if the data synchronized is correct or not.
These are some of the basic rules that a CDC tool must check. Try thinking of some more rules like these which you think are absolutely important for any design based on your knowledge of CDC (like for Gray encoding).
See you in the next article!