cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
656 Views
Registered: ‎09-16-2019

Setting False Path on all paths between two clock domains

Jump to solution

Hello, 

 

I have two MMCMs in my design, each having its own external reference clock. Many modules in the design get their clock from one of the MMCMs and many modules get their clock from the other MMCM. Is there a way to set all of the paths that cross these clock domains as false paths automatically rather than individually specifying them? 

Thank you 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
612 Views
Registered: ‎01-23-2009

Is there a way to set all of the paths that cross these clock domains as false paths automatically rather than individually specifying them?

There is (but don't!)

Assuming you have your input clocks (the ports that drive the MMCM inputs) defined with create_clock commands, then you can use

set_clock_groups -asynchronous -group [get_clocks -include_generated_clocks <name_of_first_clock>] -group [get_clocks -include_generated_clocks <name_of_second_clock>]

This will declare all paths that start at a clock in one group and end at a clock in the other group as false.

But I generally discourage doing so...

If paths cross between these domains, then they need proper clock domain crossing circuits (CDCCs); you need different CDCCs for different types of data and different clock frequencies. And while all CDCCs make it so that an exception is legal on the actual clock domain crossing paths, the type and value of the exception can be different for different types of CDCCs. In fact, the set_clock_groups/set_false_path exception is only applicable to a very small subset of CDCCs. Furthermore, the set_clock_groups/set_false_path exceptions are the highest priority exceptions - if you have these exceptions then no other exceptions that you apply to these paths will make a difference.

Finally, if you accidentally have a path going between two domains without a proper CDCC, then this command will "hide" the timing failure that may result. While it is never a good idea to count on timing analysis to catch illegal clock domain crossing paths (the report_clock_interaction and report_cdc commands are better for that), it can serve as an extra safeguard against these kinds of mistakes.

Take a look a this post on the different types of constraints and the different ways to apply them. Also take a look at this post on the dangers of the set_false_path/set_clock_groups command.

Avrum

View solution in original post

3 Replies
hongh
Moderator
Moderator
617 Views
Registered: ‎11-04-2010

Ex: set_clock_groups -async -group [get_clocks MMCM_input_clock_1   -include_generated_clocks ]  -group [get_clocks MMCM_input_clock_2   -include_generated_clocks ]

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
612 Views
Registered: ‎01-22-2015

Hi David,

The short answer is, Yes.  See the "set_clock_groups -async" constraint (ref. page 97, UG903(v2020.1)).

The longer answer that you will get from Avrum and I (but not everyone) starts with the warning that you should never use "set_clock_groups -async".   Avrum explains why in the following classic post.

https://forums.xilinx.com/t5/Vivado-TCL-Community/How-to-set-timing-constraint-in-this-case/td-p/510641/highlight/true

In short, we believe that every crossing of data between two clock domains deserves your personal attention.  Some crossing will get an individualized set_false_path constraint.  -and some will get a full-up clock-crossing circuit (eg. synchronizer) which comes with special constraints (eg. set_max_delay -datapath_only).  The "set_clock_groups -async" constraint is too much of a blanket statement - covering up things that really need your attention - and covering up things that your successor does that really need his/her attention.

Cheers,
Mark

 

 

avrumw
Expert
Expert
613 Views
Registered: ‎01-23-2009

Is there a way to set all of the paths that cross these clock domains as false paths automatically rather than individually specifying them?

There is (but don't!)

Assuming you have your input clocks (the ports that drive the MMCM inputs) defined with create_clock commands, then you can use

set_clock_groups -asynchronous -group [get_clocks -include_generated_clocks <name_of_first_clock>] -group [get_clocks -include_generated_clocks <name_of_second_clock>]

This will declare all paths that start at a clock in one group and end at a clock in the other group as false.

But I generally discourage doing so...

If paths cross between these domains, then they need proper clock domain crossing circuits (CDCCs); you need different CDCCs for different types of data and different clock frequencies. And while all CDCCs make it so that an exception is legal on the actual clock domain crossing paths, the type and value of the exception can be different for different types of CDCCs. In fact, the set_clock_groups/set_false_path exception is only applicable to a very small subset of CDCCs. Furthermore, the set_clock_groups/set_false_path exceptions are the highest priority exceptions - if you have these exceptions then no other exceptions that you apply to these paths will make a difference.

Finally, if you accidentally have a path going between two domains without a proper CDCC, then this command will "hide" the timing failure that may result. While it is never a good idea to count on timing analysis to catch illegal clock domain crossing paths (the report_clock_interaction and report_cdc commands are better for that), it can serve as an extra safeguard against these kinds of mistakes.

Take a look a this post on the different types of constraints and the different ways to apply them. Also take a look at this post on the dangers of the set_false_path/set_clock_groups command.

Avrum

View solution in original post