cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Nuno137
Visitor
Visitor
237 Views
Registered: ‎02-22-2021

false path between clocks

Jump to solution

Hi and thank you in advance. I already look for a way to set all paths between two clock domains as "false". I find that you need to add this constraint:

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

I have two clocks but I don't need to use them together. Basically, one clock is very slow and just loads configuration registers. Once they are loaded, they are static. 
But I guess you just don't add this tcl command in your constraint file (like top.xdc) but you send this tcl command when your synthesized design is opened, do you confirm? When can I run this command? Before implementation? After? Can I put this in a file and load it in tcl.pre or tcl.post of synth/impl?

Also, If I do so, does the implementation run automatically optimizes my design because of that? I've some timing problems because of that, and I would love that the implementation tool optimizes my design without tanking "care" of those common paths. Is that possible?

Thank you again.





0 Kudos
1 Solution

Accepted Solutions
richardhead
Scholar
Scholar
202 Views
Registered: ‎08-01-2012

Using false paths, or async clock groups between clock domains is not recommended. You're giving vivado the ability to place the registers in opposite corners of the chip.

Ideally, you use max delays and set the period between the clocks to be one clock on the fastest clock.

 

set_max_delay -from [get_clocks $clk1] -to [get_clocks $clk2]  [expr $fasterDelayPeriod] -datapath_only
set_max_delay -from [get_clocks $clk2] -to [get_clocks $clk1]  [expr $fasterDelayPeriod] -datapath_only

 

View solution in original post

5 Replies
viviany
Xilinx Employee
Xilinx Employee
227 Views
Registered: ‎05-14-2008

Are the two clocks defined in your xdc?

set_clock_groups constraint is used in xdc just like other constraints.

I don't quite get your point here. 

"I would love that the implementation tool optimizes my design without tanking "care" of those common paths." --- What common paths are you referring to? Are they the paths between the two clock domains?

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Nuno137
Visitor
Visitor
208 Views
Registered: ‎02-22-2021

Well yes, I mean not really common paths, more like paths from clk1 to clk2 and viceversa. I basically want ti ignore any interaction whatsoever from clocks and focus only on the "fast clock" clk1. 

0 Kudos
richardhead
Scholar
Scholar
203 Views
Registered: ‎08-01-2012

Using false paths, or async clock groups between clock domains is not recommended. You're giving vivado the ability to place the registers in opposite corners of the chip.

Ideally, you use max delays and set the period between the clocks to be one clock on the fastest clock.

 

set_max_delay -from [get_clocks $clk1] -to [get_clocks $clk2]  [expr $fasterDelayPeriod] -datapath_only
set_max_delay -from [get_clocks $clk2] -to [get_clocks $clk1]  [expr $fasterDelayPeriod] -datapath_only

 

View solution in original post

Nuno137
Visitor
Visitor
151 Views
Registered: ‎02-22-2021

Well I technically don't have a problem with that. Since my "clk2" could be even 1kHz or something very low like that, I can accept FF with clk2 very far away from each other. What I really need, what I'm kinda desperate about, is FFs with clk1 very close from each other. This is a problem because my design has like 50% usage of the board resources, so the logic is already spread out and the area is big.
You still suggest that async groups is a bad idea in this scenario? If yes, why?
Thank you for your help.

0 Kudos
richardhead
Scholar
Scholar
124 Views
Registered: ‎08-01-2012

If you have a clock constraint for clk1, then it will ensure all FFs meet the timing requirement. No other constraints are needed as the routing will always attempt to get them close enough to each other to meet the timing requirement.