cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
427 Views
Registered: ‎06-13-2018

Generated clock is part of asynchrouns clock groups by default

Jump to solution

Hi,

I have clk1 and clk2, coming inside FPGA. I have declared clk1 and clk2 with periods and put them into asynchronous clock groups in constraint file. There are other two clocks generated from clk1 and clk2 each. Clk3 and clk4 are generated using mmcm from clk1. Clk5 and clk6 are generated using mmcm from clk2.

I have two questions here.
Do I need to declare clk3, clk4, cllk5, and clk6 as generated clock?
Do I also need to include generated clocks in asynchronous clock groups?

Thanks in advance.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
389 Views
Registered: ‎01-22-2015

@cpandya 

Do I need to declare clk3, clk4, cllk5, and clk6 as generated clock?
The MMCM is one of the FPGA devices for which Vivado auto-generates clocks.  That is, a create_generated_clock constraint is automatically written by Vivado for each of the clock outputs of the MMCM (see page 90, UG903(v2019.2)).


Do I also need to include generated clocks in asynchronous clock groups?
Vivado considers ALL clocks to be synchronous.  So, it is up to you to specify which clock-pairs are asynchronous.  frederi has shown you how to specify that clk1 and its derived clocks (clk3 and clk3) are asynchronous with clk2 and its derived clocks (clk3 and clk4).   -and this is fine if you never ever attempt to directly cross data between clock-domains where the clocks are asynchronous.

However, if sometime in the future, you accidentally attempt to directly cross data between two async clock domains, then Vivado will not issue a timing analysis warning/error - because your "set_clock_groups -async" exception has disabled timing on paths between the async clock domains.  That is, your crossing of data will fail in hardware and you will have no warning from Vivado that the hardware is failing!

So, some of us never use "set_clock_groups -async".  Instead, we strive to give individual attention to every clock crossing of data.  If we know it to be an async clock crossing then we insert appropriate clock crossing circuits and use other timing exceptions (eg. set_max_delay -datapath_only) that apply to the specific crossing (and not to all crossings between the two clock domains).  Avrumw explains this best in <this> post.

Cheers,
Mark

View solution in original post

2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
407 Views
Registered: ‎03-29-2013

UG903 - Vivado Using Constraints - p.96:

The previous example can also be written as:
set_clock_groups -name async_clk0_clk1 -asynchronous \
-group [get_clocks -include_generated_clocks clk0] \
-group [get_clocks -include_generated_clocks clk1]

 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug903-vivado-using-constraints.pdf

Highlighted
390 Views
Registered: ‎01-22-2015

@cpandya 

Do I need to declare clk3, clk4, cllk5, and clk6 as generated clock?
The MMCM is one of the FPGA devices for which Vivado auto-generates clocks.  That is, a create_generated_clock constraint is automatically written by Vivado for each of the clock outputs of the MMCM (see page 90, UG903(v2019.2)).


Do I also need to include generated clocks in asynchronous clock groups?
Vivado considers ALL clocks to be synchronous.  So, it is up to you to specify which clock-pairs are asynchronous.  frederi has shown you how to specify that clk1 and its derived clocks (clk3 and clk3) are asynchronous with clk2 and its derived clocks (clk3 and clk4).   -and this is fine if you never ever attempt to directly cross data between clock-domains where the clocks are asynchronous.

However, if sometime in the future, you accidentally attempt to directly cross data between two async clock domains, then Vivado will not issue a timing analysis warning/error - because your "set_clock_groups -async" exception has disabled timing on paths between the async clock domains.  That is, your crossing of data will fail in hardware and you will have no warning from Vivado that the hardware is failing!

So, some of us never use "set_clock_groups -async".  Instead, we strive to give individual attention to every clock crossing of data.  If we know it to be an async clock crossing then we insert appropriate clock crossing circuits and use other timing exceptions (eg. set_max_delay -datapath_only) that apply to the specific crossing (and not to all crossings between the two clock domains).  Avrumw explains this best in <this> post.

Cheers,
Mark

View solution in original post