Multiple clocks are inevitable in today's designs. Systems-on-chip (SoCs) have grown significantly in complexity, as well as in the variety of intellectual-property (IP) blocks that can be integrated. These SoCs often contain multiple processors, peripherals for each processor, memories and specialty functions. Each of those blocks operates at a different frequency, and hence, the SoCs require multiple clocks.
Multiple clocks are necessary for communication ICs because they often must work on external clocks or data obtained from an external clock. Moreover, larger and denser devices are power hungry, so an increased awareness of low power also causes designers to use multiple clock domains to reduce activity in certain portions of the device.
Although multiple clock domains provide many benefits, they also present many challenges that must be dealt with as early in the design cycle as possible. For a design with multiple clock sources, data originating from one clock domain would need to be sampled by devices being clocked by another clock domain. Such a situation is called a "clock-domain crossing," posing two problems:
- Data loss: Data generated by Clock1 might get changed even before it has been captured by the Clock2 domain. Typically, this problem does not occur if the destination clock is running at a much higher frequency than the source clock.
- Metastability: Since there is no timing relationship between source and destination domain, there may be a case where both data and clock reach the destination flip-flop at the same time. In such a situation, the FF output might go to a metastable state. If the FF has multiple fanouts, different paths might sample different logical values from the FF output. Thus, metastability poses reliability issues. Therefore, synchronization is required to prevent metastability problems.
Various methods are used for synchronization. However, it is common to limit the different synchronization styles in each design and allow only one method based upon company guidelines. Some of the most commonly used synchronization mechanisms include
| A good predictive analyzer quickly synthesizes and flattens the design. In this case, the analyzer propagated the clocks, identified a clock domain crossing and now shows the error in RTL coding and in an automatically created schematic to ease in debugging. |
a double flip-flop technique, in which the output of the destination FF is sent directly to another FF in the destination domain; a control-signal synchronization technique, in which the actual data crossing the clock domains is not synchronized; and a FIFO-based approach, in which a first-in first-out (FIFO) memory serves as a form of elastic buffer.
But clock-domain crossing and synchronization techniques cannot be checked easily.
Predictive analysis can be used to identify crossings and check for valid synchronization techniques in Verilog and VHDL register-transfer-level (RTL) code. The SpyGlass Predictive Analyzer quickly synthesizes and flattens the design. SpyGlass propagates the clocks to reach the various FFs. It identifies all flop-to-flop paths and it is able to identify paths that cross
| A good predictive analyzer can not only point out faults, but can also verify correct implementation. In this case, it has validated that a synchronization technique has been correctly used. |
clock domains. Once crossings are pinpointed, it checks for the presence of "allowed" structures around the crossings to determine whether the crossings are synchronized properly.
Because SpyGlass can detect unsynchronized crossings at Verilog and VHDL RTL, the design engineer can save valuable time-avoiding iterations of RTL changes plus verification and resynthesis. This reduces the risk of schedule slips and allows the design team to have confidence in multiple-clock-domain designs.
Sanjay Churiwala (sanjayc@ noida.atrenta.com) is a senior engineering manager at Atrenta Inc.(San Jose, Calif.).