Questions about clock group in timing constrain

If there's no path between the clocks, the set_clock_groups doesn't do anything. It's like putting a set_false_path on a path that doesn't exist. Now, users might do this to show that they don't exist in case the design changes and a path is added, but it's up to the user.

Note that I would do it in one-line:

set_clock_groups -asynchronous -group {clk1} -group {clk2}

This constraints cuts timing between clk1 and clk2. (The [get_clocks] is implied since the constraint only works on clocks, so you can leave it out if you want).

When you do a constraint with a single clock, like so:

set_clock_groups -asynchronous -group {clk1}

That means to cut timing from clk1 to all other clocks in the design. In your two clock design, that's fine, but it's an implicit cut and that can be dangerous. Let's say 2 months from now someone adds clk3, and it's related to clk1. With the way the constraint is set up, clk1 is cut from all other clocks including clk3, so now those paths are cut. If the user wanted them analyzed, they would have problems. I try to always have 2 or more groups in my set_clock_groups assignment.

Note that I talk a lot about set_clock_groups in the first chapter of the TimeQuest User Guide on the www.alterawiki.com

--- Quote Start ---

If there's no path between the clocks, the set_clock_groups doesn't do anything. It's like putting a set_false_path on a path that doesn't exist. Now, users might do this to show that they don't exist in case the design changes and a path is added, but it's up to the user.

Note that I would do it in one-line:

set_clock_groups -asynchronous -group {clk1} -group {clk2}

This constraints cuts timing between clk1 and clk2. (The [get_clocks] is implied since the constraint only works on clocks, so you can leave it out if you want).

When you do a constraint with a single clock, like so:

set_clock_groups -asynchronous -group {clk1}

That means to cut timing from clk1 to all other clocks in the design. In your two clock design, that's fine, but it's an implicit cut and that can be dangerous. Let's say 2 months from now someone adds clk3, and it's related to clk1. With the way the constraint is set up, clk1 is cut from all other clocks including clk3, so now those paths are cut. If the user wanted them analyzed, they would have problems. I try to always have 2 or more groups in my set_clock_groups assignment.

Note that I talk a lot about set_clock_groups in the first chapter of the TimeQuest User Guide on the www.alterawiki.com

--- Quote End ---

Thanks very much, Rysc.

Yes, I did read the TimeQuest User Guide from you. It is very helpful. But I still have another question about clock groups. For two asynchronous clocks, in what case there will be a data path between them ？ The only case I can point out is the FIFO is used to handle two diffierent clock domains, that clk1 and clk2 are used as read and write clocks individually, they can be asynchronous. Is there any other cases that there are data paths between two asynchours clocks, and we need use `set_clock_groups` to constrain them？

Thanks.

People send signals across asynchronous domains quite a bit. Often it's just a "slow" signal, like status bit or something like that. Sometimes they're even constants, like signals that set modes of the design out of configuration. They also often try faster transfers and might do some hand-shake logic or something like that. If you can keep it so no paths exist or they all go through FIFOs, good for you.

(In fact, one reason people don't cut timing between unrelated domains is that they often show up as timing failures. For example, if clk1 were clk2 had no relationship, the default setup relationship might be some small number, like 1ps. Then if the a designer accidentally added a path between the domains, it would fail timing and they'd see their mistake right away.

--- Quote Start ---

People send signals across asynchronous domains quite a bit. Often it's just a "slow" signal, like status bit or something like that. Sometimes they're even constants, like signals that set modes of the design out of configuration. They also often try faster transfers and might do some hand-shake logic or something like that. If you can keep it so no paths exist or they all go through FIFOs, good for you.

(In fact, one reason people don't cut timing between unrelated domains is that they often show up as timing failures. For example, if clk1 were clk2 had no relationship, the default setup relationship might be some small number, like 1ps. Then if the a designer accidentally added a path between the domains, it would fail timing and they'd see their mistake right away.

--- Quote End ---

Thanks, Rysc. I think I got what you mean. In most cases, the data paths between two async clocks may not be real path used to transfer "data: signals, they may be path that transfer control, status signals as you mentioned.

However, in the case I mentioned that FIFO with two different read and write clocks, in this case, is this a data path between these two clocks? Do I need to define clock groups or set false path for these two clocks?

Thanks very much.