Most SoC designs in today's world employ multiple clocks and commonly have many clock domains. As data crosses from one clock domain to another within the design, the potential for metastability problems arises due to asynchronous clock domain crossings (CDCs).
An asynchronous crossing with simple double flop synchronization.
In Figure 1, there is an asynchronous CDC for the data going from flop F1 (clocked by C1) into F2 (clocked by C2), assuming that C1 and C2 are asynchronous with respect to each other.
This asynchronous CDC at F2 can cause the F2 flip-flop's output to go metastable. Data from F2 can potentially be read as different logic values if it feeds multiple logic paths if F2 enters the metastable state. The usual solution to protect against such ambiguity is synchronization. Figure 1 shows a simple synchronization technique where the data output of F2 feeds only one flip-flop (F3). In turn, F3 can feed into as many paths as desired -- subject to meeting other electrical/design rules.
This additional flip-flop (F3) -- triggered by the same clock -- effectively gives the output from F2 one full clock cycle to reach a stable logic value before being sampled by F3, which is then distributed to the rest of the design. (Many more synchronization techniques are used to combat metastability in addition to this simple double flip-flop scheme, depending on the design needs.)
The timing challenge
Because clocks C1 and C2 are asynchronous with respect to each other, data originating from F1 can reach F2 at any time with respect to F2's clock, C2. Data will sometimes arrive well before the active C2 clock edge, sometimes just before the active edge (setup violation), sometimes just after the active edge (hold violation), etc. Timing analysis tools consider the worst-case combination of all possible data and edge values, and these CDC paths result in setup and hold violations being reported by the timing analysis tool because of the asynchronous timing between F1 and F2.
The timing-analysis tools are not wrong in reporting violations. There will really be setup and hold violations at the data input to F2. However, the design already has the mitigation plan for dealing with setup/hold violations through the synchronizer (F3). Consequently, designers are not interested in seeing timing violations being reported at CDCs where they have placed synchronizers. More importantly, the design tools may needlessly over-allocate resources to those paths to meet timing, while starving other paths that could benefit from those extra resources.
Fixing this problem is therefore a real issue and not just a nuisance for the designer. An excellent way to tackle this issue is through the use of appropriate constraints. The industry standard for constraint files is the Synopsys Design Constraints (SDC) format, which specifies design intent, including timing, power, and area constraints. SDC has been in use and evolving for more than 20 years, making it the most popular and proven format for describing design constraints. For example, Xilinx incorporates the SDC format in its Xilinx Design Constraints (XDC) files used with the Vivado Design Suite.
To Page 2 >