STA is excellent at one thing: checking that signals arrive on time with respect to clock edges that it knows. When a signal crosses from one clock domain into another that has no fixed relationship, the question is no longer about the arrival time. The capture flip-flop can sample the data just as it changes, and the result is an unstable output, which no arrival time can prevent. This article explains why STA cannot judge such a crossing, what the checks it does make are worth, and which separate checks a design needs.
8 min read | Intermediate
What You'll Learn
- Explain what metastability is and why a timing check cannot prevent it
- Say what STA does check on a clock crossing and what it does not
- List the problems of a crossing that need a separate check
- Describe how STA constraints and CDC checks work together
Why a Crossing Is Different
Within one clock domain, the launch edge and the capture edge are related. STA knows exactly how far apart they are, so it can state that the data arrives early enough. When the sending flip-flop and the receiving flip-flop use unrelated clocks, the edges drift against each other. Sometimes the data changes just before the capture edge, and sometimes right at it. No fixed arrival time is safe, because the relative timing changes all the time.
When the capture flip-flop samples a signal at the moment it changes, its output can hover between 0 and 1 for a while before it settles to one of them. This is metastability. It cannot be prevented, only made very unlikely. The usual circuit is a synchronizer, two or more flip-flops in a row on the receiving clock: the first one may become metastable, and it has a full clock period to settle before the second one samples it. The article about synchronizers and clock domain crossing explains the circuit.
What STA Does on a Crossing
For two clocks that STA is told are related, it checks the crossing like any path, with the closest launch and capture edges. In the article about clock groups, the path from clka (2.0 ns) to clkb (3.0 ns) had a window of 1.0 ns and a slack of 0.62 ns. This is useful when the clocks are really related, for example when both come from the same PLL.
For clocks that are unrelated, the designer declares them asynchronous with set_clock_groups -asynchronous. STA then removes the paths between the groups from all its checks. After the command, the path from the sending flip-flop to the receiving flip-flop is no longer in the reports. STA says nothing about the crossing, safe or not.
What STA Cannot Check
A crossing has to be correct in several ways, and none of them is a question about an arrival time:
- The crossing must have a synchronizer. STA does not know which flip-flops are synchronizers. A crossing with no synchronizer and a crossing with a perfect one look the same after the asynchronous clock group.
- A bus must be safe as a whole. If the several bits of a bus change together and are sampled by independent synchronizers, the receiver can see a mix of old and new bits. The values are individually safe and together wrong. STA does not see that the bits belong together.
- Two signals that are synchronized separately must not meet again in logic, because their relative timing after the synchronizers is not defined. This is called reconvergence.
- A signal must be stable long enough for the receiving clock to see it. A pulse that is shorter than the receiving clock period can be missed. This is a question about the width of a pulse, not about an edge.
- The data must not glitch before the synchronizer. A glitch can be sampled as a real change.
Separate Checks for Crossings
The missing checks are done by other tools and methods:
- CDC analysis tools that read the netlist with the clock definitions. They find every crossing, check that it ends at a synchronizer of an accepted form, check buses and reconvergence, and report the rest.
- Simulation with randomized delay or clock jitter on the crossings, to find the functional effects of a late or early arrival.
- Design rules and reviews: only synchronizers from an approved list, no logic between the clock domain and the first synchronizer flip-flop, and handshake or FIFO structures for buses.
STA and the CDC checks complement each other. STA proves that the logic in each domain is fast enough, and it takes care that the synchronizer flip-flops are timed against their own clock, with the path to them as short as possible. A constraint such as a maximum delay on the crossing wire keeps the first flip-flop of the synchronizer close to the sender, which gives the signal a short and defined path.
Using the Constraints for Crossings
- Declare unrelated clocks asynchronous, so that STA does not report meaningless violations.
- If a crossing needs a short path, for example from a gray-coded pointer to the first flip-flop of a synchronizer, use
set_max_delayon it, as in the article about min and max delay exceptions. This keeps the arrival of all bits within a small window, even though STA does not check the clock relation. - Keep a list of every asynchronous crossing and the reason why it is safe, and check it against the result of the CDC tool.
Common Mistakes
Mistake #1: Declaring clocks asynchronous and considering the crossing handled
The command removes the checks. It does not add a synchronizer. If you declare two clocks asynchronous, you take on the responsibility of the CDC checks.
Mistake #2: Treating a passing STA report as proof that the crossing is safe
For related clocks, a met setup check only says that the data arrives before the capture edge of the closest pair. It says nothing about the other edge pairs that can occur, or about the synchronization of the receiver. Use a CDC check for every crossing.
Quick Check: After set_clock_groups -asynchronous, what does a timing report say about a path between the two groups?
Nothing. The path is not checked. The report shows no violation, and it does not say whether the crossing is safe.
Practice Exercise
Challenge: See the Crossing Disappear
Paste the two-clock design from the article about clock groups into the lab, with the clocks clka (2.0 ns) and clkb (3.0 ns) and no synchronizer. Print the setup summary with and without the asynchronous group:
set_clock_groups -asynchronous -group clka -group clkb
Say which endpoint disappears, and what this tells you about the design.
Open the ready-made example in the lab, run synthesis, and then run STA. Editing constraints.sdc and re-running only STA, and choosing another library or corner, are PRO features.
Hint
Compare the lists of endpoints and the slack of the data pin of the capture flip-flop.
Solution
Without the group, the data pin of the capture flip-flop (rb/D) is in the summary with a slack of 0.6200 ns. With the group, it is not in the list, because the only path that ends there comes from the other clock. STA reports no violation. The design has no synchronizer, which is a real problem, and STA does not report it. Only a CDC check or a design review can find it.
Summary
- A signal that crosses between unrelated clocks can be sampled while it changes, which causes metastability. No arrival time prevents it.
- For related clocks, STA checks the crossing like any other path. For unrelated clocks,
set_clock_groups -asynchronousremoves the check. - STA cannot see whether a synchronizer exists, whether a bus is safe as a whole, whether synchronized signals reconverge, or whether a pulse is long enough.
- These questions need CDC analysis, simulation and design rules.
- Constraints such as a maximum delay on a crossing wire support the CDC design, but they do not replace the checks.
- Declaring clocks asynchronous makes the designer responsible for the safety of every crossing.