Professional Documents
Culture Documents
Step 1
Check for the presence
of valid synchronizers in:
All asynchronous clock
domain crossings, and,
those cases of synchronous clock
domain crossings where there
can be metastability as described Figure 15. Formal verification helps catch gray-encoding failure.
in the section on rational multiple
clocks. incoherency. Figure 15 shows a Asserting that each source that there is no FIFO overflow
A multi-flop synchronizer is control bus clock domain cross- data launch is always captured or underflow.
sufficient to ensure that there will ing, which is synchronized using in the destination domain can • Mux recirculation: With refer-
be no metastability. However, a multi-flop synchronizer but is validate these. ence to Figure 8, check that
there can still be a problem of not Gray-encoded. A waveform In the case of fast to slow syn- while the synchronized con-
data incoherency. So, it is advis- trace is generated for the asser- chronous clock domain cross- trol signal EN_Sync is active,
able to check at this stage only, tion failure. ings, where a synchronizer is not the following two conditions
that multi-flop synchronizers are In case the converging sig- required and for the simple cases hold:
used only for scalar signals. They nals cannot be Gray-encoded, of multi-flop synchronization, o Source data A[0:1] is stable,
can also be used for control bus- change the synchronization check that after every transition and,
ses. They should not be used for scheme to one which uses a on the source data an active o at least one active edge of
data busses however. common control signal, for ex- edge of the destination clock ar- destination clock arrives
A rule-based checker can be ample, MUX recirculation, FIFO rives where there is no setup or
used to automatically detect all or handshake. These schemes hold violation. The methodology described
clock domain crossings and to still need to be validated for For other synchronization in the above four steps is also
check for the presence of valid proper functionality as described schemes, some standard func- depicted in Figure 16.
synchronizers at all places where in Step 4. tional checks can be done to
they are required. ensure that there is no data loss, Summary
If there are missing synchro- Step 3 which are described in Step 4. Traditional verification methods
nizers, the designer should mod- Once the proper synchroniza- like simulation and static tim-
ify the design to add appropriate tion logic is in place and the Step 4 ing analysis are not sufficient
synchronization logic. Gray-encoding checks have been In all cases, where some special to detect all types of problems,
done, the next step is to verify synchronization schemes are which can occur in clock domain
Step 2 that there is no data loss while used, it is necessary to verify that crossings. The problems that can
Check for the presence of sepa- transferring data from one clock they are performing the intended occur depend on the types of
rately synchronized signals that domain to the other. This needs function correctly. This is impor- clock domain crossings. Similarly,
are converging. These are prob- to be checked for the following tant to ensure that there will be the solutions to those problems
able candidates for data incoher- two cases: no metastability, data incoher- are also different and hence the
ency. Doing structural analysis ency or data loss problem. verification techniques required
of the design can identify these • Synchronous clock domain The required checks are given are different as well. Some of the
candidates. crossings here for three commonly used basic problems of clock domain
The candidate signals for data • All fast to slow crossings schemes: crossings have been discussed
incoherence should be verified to • Slow to fast crossings where here. The solutions to those issues
be Gray-encoded. This validation the clock edges can be close • Handshake synchronization: are also discussed and a verifica-
can be done through assertions. together for continuous Check that the request-data tion methodology is proposed
A structural checking tool could cycles and request-acknowledge which will ensure that data is
even generate the assertion • All asynchronous clock do- protocols are working as per correctly transferred across clock
itself whenever it sees signals, main crossings the specifications. domains.
which are candidates for data • FIFO synchronization: Check