As we bring Blue Pearl’s advanced design verification solutions to India, let’s share the knowledge on the problems being addressed using these products. Here, in this article we leverage on Blue Pearl’s introductory article.
Quoting straight from http://www.bluepearlsoftware.com/ace/
At its most basic level, metastability is what happens within a register when data changes too soon before or after the active clock edge; that is, when setup or hold times are violated. A register in a metastable state is in between valid logic states, and the process of settling to a valid logic state takes much longer than normal. It will eventually fall into a stable “1″ or “0″ state, but there is no way to predict which way it will fall or how long it will take. If the metastable state lasts longer than one clock cycle, it can be transferred to the next register.
When data is transferred between two registers whose clocks are asynchronous, metastability will happen. There is no way to prevent it. All you can do is to minimize its impact by placing the two clocks in different clock domains and using a clock synchronization technique at the crossing point. Hence the name “clock domain crossing” (CDC).
Putting two clocks into the same clock domain is a declaration that these two clocks are synchronous to each other, and CDCs between them do not need to be synchronized. If the clocks are from the same source, or one is derived from the other, then they are synchronous and should be placed into the same clock domain.Clocks that are asynchronous to one another should always be placed in different clock domains, and any CDCs between them should be synchronized. Even two clocks of the same frequency should be placed into different domains if they come from independent sources. All specifications have tolerances or “error bars,” and two independent clock sources of the same frequency will drift relative to one another over time. Failing to synchronize CDCs between two such clocks will cause metastability problems.