03-02-2018 09:37 AM
Does the set_property CLOCK_DELAY_GROUP work if you have a series of BUFGx components.
I have two clock trees to balance , both have a series of 3 BUFG components, will setting this property on the final clock net of each of the two trees work?
03-04-2018 08:11 AM
The dedicated clock tree resources are fixed and matched in hardware,
Constraints assume the clock trees are matched (because they are).
03-06-2018 08:33 AM
Please read your own documentation! Clearly clock trees can be configured in different ways with different delays depending on how the trees are built from the various clock distribution and clock routing elements. The delay due to each element is constant, but configurations may vary.
This is clearly stated in UG572 (v1.6) pp12-15.
hence the new property :
set_property CLOCK_DELAY_GROUP <name> [get_nets <clk_net>]
Implicitly this recognises that clock trees can be configured in various ways. [ This is different from 7 series devices ]
03-06-2018 08:45 AM
Note the document states you should allow the tools to manage the clocking, and warns that attempts to modify things may result in issues (un route-able clocks, errors, etc.).
Just because their is a TCL command, doesn't mean it must get used, rather it is evidence that the 'feature' is exposed in order to have a finer control if needed (as the tools may not do what is needed).
Check these out:
(look at the three answer records -- only use if timing is not being met)
Thank you for referring us to ug572 --
03-06-2018 09:48 AM
Thanks for your reply. I have studied the three references you gave.
From my perspective the most interesting is the comment from AvrumW who answers the following question in
The CLOCK_DELAY_GROUP property is interesting. If I did not use that, would Vivado have a difficult time meeting inter-clock timing because of large skew?
"Yes, it could. It all depends on where it places the CLOCK_ROOT of the two different domains. If they are near each other, then the skew will be reasonable, but if they are far apart then the skew can get large. The CLOCK_DELAY_GROUP forces the implementation process to place the CLOCK_ROOT of the different domains within the group in the same clock region. "
I have looked closely at my timing reports and see that even if I constrain my clock trees by using the following property to balance (legal) clock region placement on all the buffers
set_property CLOCK_REGION ......
The tools are over-riding this by placing the CLOCK_ROOT in different clock regions for my two clock trees.
Therefore I need to use CLOCK_DELAY_GROUP to over-ride the tools.
If I am right and this is the case, then you should document the relative rules of priority for assignment of clock buffer placement for balanced clock trees in UG572 .