Clock domain crossing timing constraints for Altera

Question

I have a slight problem with my clock domain crossing timing constraints.

I have two clock groups

set_clock_groups -asynchronous -group {clk_A} -group {clk_B}

As I understand it this will cause all signals from clk_A to clk_B to be treated as false paths.

However I would like to constrain a few of these paths as

set_max_delay -to [get_registers {*|*|some_reg}] 8

But if I understood the Altera documentation correctly. The implicit false paths created from the asynchronous clock groups will cause the later constrain to be ignored.

For now it beats my why a more specific constrain has less priority then the more general one.

Has anyone solved this in a practical fashion, or do I need to stop using clock groups and constrain all relevant paths manually?

Answer 1

Despite being fairly common in the industry to globally cut all paths between two clock groups, I would strongly advise against this practice as it makes it very hard to spot places where you unintentionally re-sampled a signal between clock domains.

You are better off using a common block for transferring data between domains. Embed the constraints in the common block, or use wildcards in the paths to constrain every instance of the block in your design. Make the use of a common synchronisation block part of your coding guidelines.

You can then report all clock-domain crossings and find places where you weren't using a safe transfer mechanism. You can also include automatic checking in your flow and quickly locate any accidental clock crossings in your design.

You will also be able to use your set_max_delay constraint and not have it ignored :)

Answer 2

+1 for @chiggs comments suggesting you not cut paths between domains. It's easy to do and it often works but it can fail when the P&R tools are pushed hard such as when the part is nearly full.

If you're going to use set_max_delay then you'll also need to use set_min_delay. Be aware that because of the way paths are analyzed it's possible for delays to be negative. For example if you're going for a 8ns window then you might set min delay to -1, and max delay to 7. However, even though you know the total window size (aka skew) that you're going for, all you can do is make an educated guess as to where to place the window with respect to the clock, [-1,7], or [-2,6] etc. For that reason this approach is not necessarily optimum, particularly for high clock rates.

Ultimately for functional correctness what you really care about is the skew between the set of nets crossing the boundary. And the the best way to specify that is with a max skew constraint. For usage information refer to Altera's documentation for set_max_skew