UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer jcappello
Observer
4,500 Views
Registered: ‎08-10-2009

Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

I understand that I can declare that two clock domains are asynchronous to each other by using the set_clock_groups -asynchronous command, and that declaring these domains as "false" to each other overrides any other lower priority timing constraints that may have been declared between those domains, such as set_max_delay.

 

Let's suppose I have a signal going from one clock domain to the other, and that I am using double rank synchronizer circuit to synchronize this signal into the target domain. Will the ASYNC_REG attribute be effective on those synchronizer flops even though I have declared the paths between the domains as "false"? I wasn't sure if this ASYNC_REG would be overridden by the set_clock_groups -asynchronous command.

 

If the above is true, it would seem that as a developer this is all I need to worry about in terms of using a double rank synchronizer circuit and maximizing my MTBF. But if I wanted to, couldn't I specify a set_max_delay of, say, 1-2 nsec between the synchronizer flops? I understand set_max_delay as a timing constraint gets overridden by the set_clock_groups -asynchronous command. But wouldn't the "jurisdiction" of that set_clock_groups -asynchronous constrain end at the first flop of the target domain? 

 

Thank you.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
8,255 Views
Registered: ‎01-23-2009

Re: Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

I think the answer to most of your questions are "yes".

 

So, the set_clock_groups (or set_false_path) is a timing constraint - it determines whether the tool will perform setup and hold checks on the path that goes between the two domains. In this case, this would be the path between the last FF on the source clock domain and the first FF on the destination clock domain.

 

The ASYNC_REG property is put on both of the FFs in your synchronizer on the destination domain. This instructs the tool (among other things) to keep the two FFs near each other. This is required to minimize the propagation time between the two FFs and hence maximize the time allowed for metastability resolution.

 

Putting a set_maxdelay on the path between the two FFs in the metastability chain effectively has the same effect as setting the ASYNC_REG property. This creates a timing constraint that will cause the placer and router to keep the path between these two FFs short (as opposed to the ASYNC_REG property which is a physical constraint, that controls the placer directly). 

 

The set_max_delay between the synchronizer FFs is not affected by the set_clock_groups, since they are on different paths; the set_clock_groups is between the last FF on the source domain and the first FF on the destination domain. The set_max_delay is on the path between the first FF on the destination domain and the second FF on the destination domain - since they are different paths, they have no effect on each other.

 

Finally, the ASYNC_REG property, as a physical constraint, is not affected by any timing constraint (including the set_clock_groups).

 

BUT (and this is my standard caveat with set_clock_groups) - using this constraint disables all timing paths on all FFs that cross between the two clock domains. This leaves all the clock domain crossing circuits between these domains as unconstrained. This is fine for some synchronizers - notably

  - the synchronizer for a single bit slow changing signal

  - the synchronizer done using a built-in FIFO (i.e. a FIFO36, but not a block RAM or distributed RAM based FIFO)

 

All other synchronizers require constraints. Using the set_clock_groups between clock domains that have any other synchronizer results in that synchronizer being under-constrained (actually unconstrained) and hence subject to failure.

 

For more about synchronizers and constraints see this technical blog post on Constraining Asynchronous Clocks  including the comments that follow it (including the forum posts references within the comment).

 

Avrum 

4 Replies
Highlighted
Historian
Historian
8,256 Views
Registered: ‎01-23-2009

Re: Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

I think the answer to most of your questions are "yes".

 

So, the set_clock_groups (or set_false_path) is a timing constraint - it determines whether the tool will perform setup and hold checks on the path that goes between the two domains. In this case, this would be the path between the last FF on the source clock domain and the first FF on the destination clock domain.

 

The ASYNC_REG property is put on both of the FFs in your synchronizer on the destination domain. This instructs the tool (among other things) to keep the two FFs near each other. This is required to minimize the propagation time between the two FFs and hence maximize the time allowed for metastability resolution.

 

Putting a set_maxdelay on the path between the two FFs in the metastability chain effectively has the same effect as setting the ASYNC_REG property. This creates a timing constraint that will cause the placer and router to keep the path between these two FFs short (as opposed to the ASYNC_REG property which is a physical constraint, that controls the placer directly). 

 

The set_max_delay between the synchronizer FFs is not affected by the set_clock_groups, since they are on different paths; the set_clock_groups is between the last FF on the source domain and the first FF on the destination domain. The set_max_delay is on the path between the first FF on the destination domain and the second FF on the destination domain - since they are different paths, they have no effect on each other.

 

Finally, the ASYNC_REG property, as a physical constraint, is not affected by any timing constraint (including the set_clock_groups).

 

BUT (and this is my standard caveat with set_clock_groups) - using this constraint disables all timing paths on all FFs that cross between the two clock domains. This leaves all the clock domain crossing circuits between these domains as unconstrained. This is fine for some synchronizers - notably

  - the synchronizer for a single bit slow changing signal

  - the synchronizer done using a built-in FIFO (i.e. a FIFO36, but not a block RAM or distributed RAM based FIFO)

 

All other synchronizers require constraints. Using the set_clock_groups between clock domains that have any other synchronizer results in that synchronizer being under-constrained (actually unconstrained) and hence subject to failure.

 

For more about synchronizers and constraints see this technical blog post on Constraining Asynchronous Clocks  including the comments that follow it (including the forum posts references within the comment).

 

Avrum 

Observer jcappello
Observer
4,453 Views
Registered: ‎08-10-2009

Re: Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

Avrum,

Thanks for confirming my thoughts on these issues. With the larger devices and higher frequencies, it seems the developer needs to be more vigilant than ever in addressing CDCs in a systematic manner to make sure all such instances are addressed properly.

Regards,

John

0 Kudos
Historian
Historian
4,447 Views
Registered: ‎01-23-2009

Re: Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

it seems the developer needs to be more vigilant than ever in addressing CDCs in a systematic manner to make sure all such instances are addressed properly

 

Absolutely! That's why, there are two new commands in Vivado for dealing with CDCs;

  - report_cdc, which identifies all clock domain crossing paths and tries to determine if it can recognize the CDC style and also checks for the ASYNC_REG properties

  - report_synchronizer_mtbf (for UltraScale only), which analyzes the CDCs and determines the MTBF for each synchronizer and the system

 

This is in addition to the report_clock_interaction report (which has always been there) which helps you ensure that your constraints between clock domains are what you expected...

 

Avrum

Tags (1)
0 Kudos
Observer jcappello
Observer
4,445 Views
Registered: ‎08-10-2009

Re: Mixing ASYNC_REG with asynchronous (set_clock_groups) clock domains

Jump to solution

Yes, and the benefit to having those CDC-related reports is that finally the developer has the metrics to check up on CDCs systematically. No more just inserting the synchronizer into the code, declaring the paths false, and assuming (with crossed fingers) that everything went as planned. Good stuff.

 

John