cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Advisor
Advisor
5,138 Views
Registered: ‎02-12-2013

constraining clocks inside IP cores

Jump to solution

I am running into more and more situations when I need to deconstrain clocks that are down inside an IP core.  For example, here I want to say these two clocks are asynchronous.


set_clock_groups -asynchronous -group [get_clocks clk_out2_little_clock_wiz] -group [get_clocks clk_out1_little_clock_wiz]
set_clock_groups -asynchronous -group [get_clocks clk_out1_little_clock_wiz] -group [get_clocks clk_out2_little_clock_wiz]

 

The problem is that these clocks are not known until after synthesis so I cannot include them with all my other timing constraints that reference pins on the design.

 

So far I have handled this by creating a second late_timing.xdc file that I source after synthesis. I run tcl scripts in non-project flow.

 

Is there a better more general way to handle this common situation?

----------------------------------------
DSP in hardware and software
-----------------------------------------
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
8,804 Views
Registered: ‎01-23-2009

Take a look at this post on different ways of applying exceptions.

 

In general I greatly prefer setting exceptions on paths, not on clocks, and on anything more complex than a simple slow single bit synchronizer (and even sometimes then)  I generally prefer set_max_delay -datapath_only over set_false_path.

 

What puzzles me is that you get a timing violation from a clock crossing FIFO. If the FIFO comes from the IP catalog, then it also comes with an XDC file that has the proper path-based timing exceptions to cover the clock crossing paths. If the FIFO is a hand instantiated FIFO18 or FIFO36, then there are no timing paths between the domains - so where are you getting violations from?

 

Avrum

View solution in original post

0 Kudos
7 Replies
Highlighted
Guide
Guide
5,119 Views
Registered: ‎01-23-2009

So, normally IP constraints are placed in a scoped XDC file for that IP. In non-project batch mode, this is done using the

 

read_xdc -ref <name_of_IP_module> ip_constr.xdc

or

read_xdc -cell [get_cells <instances_of_ip>

 

In either of these cases, the XDC file is scoped to the IP; the hierarchical names referenced in the XDC file assume the IP is the "top" level of the design.

 

XDC files invoked this way should only be processed when the IP exists; in the early part of synthesis (where the IP is a black box) this XDC file should not be processed.

 

What you are doing is also fine executing a new constraint file after synth_design completes (which is after the IP black boxes are filled in).

 

But I want to point out a few things about your constraints.

 

First, the two commands are redundant - by placing two clocks in different -group options of a set_clock_groups command, you are saying that all paths between them are false. It goes both ways; all paths from A->B and all paths from B->A are declared as false.

 

Second, (standard caveat) - setting asynchronous clock groups - especially in an IP - can be dangerous. If these two clocks interact in any way then they will need a clock domain crossing (CDC) circuit between them, and most CDC circuits need some form of constraints (usually a set_max_delay -datapath_only). By placing them in different clock groups, the paths are false - nothing else you can do will apply any constraints to it (the set_clock_groups/set_false_path commands are the highest priority exception). So often this command will end up underconstraining any CDC circuits between the clocks.

 

It gets worse, though. If these clocks propagate out of the IP block, then even if the constraint is applied in the scoped XDC file (with the -ref) these clocks are now in different clock groups. This means any paths on these clocks anywhere in the design are considered false paths. So, even if the set_clock_groups are appropriate for the circuitry in your IP (and, again, they rarely are), having this command will declare false paths between these two clocks throughout your design. So that means that if a designer using your IP has a different CDC between the two clocks, but outside the IP block, and the CDC does need constraints, there is nothing he can do - these paths will be declared false by your set_clock_groups command.

 

Avrum

Highlighted
Moderator
Moderator
5,041 Views
Registered: ‎01-16-2013

Hi,

 

Just to add one point when you declare clock group constraints no need to write it twice.

set_clock_groups -asynchronous -group [get_clocks clk_out2_little_clock_wiz] -group [get_clocks clk_out1_little_clock_wiz]
set_clock_groups -asynchronous -group [get_clocks clk_out1_little_clock_wiz] -group [get_clocks clk_out2_little_clock_wiz] {This is not required}.

 

The 1st constraint will take clk_out2 to clk_out1 and as well as clk_out1 to clk_out2.

 

Thanks,
Yash

0 Kudos
Highlighted
Advisor
Advisor
5,020 Views
Registered: ‎02-12-2013

Thanks guys,

 

I thought the "set_clock_groups -asynchronous -group ..." command worked in both directions but never took the time to verify that.

 

On the bigger question, I'm not sure I understand all your warnings and I don't see a suggestion. 

 

My situation is not uncommon.  I have clock generator IP core that makes a 125MHz clock and a 200MHz clock.  The two domains meet in a fifo IP core where I cross the clock domains. I get a timing error from inside the fifo core because there are paths between the two domains.

 

It sounds like you are saying that when I make two clocks asynchronous all other types of constraints between registers on the two domains are cancelled.  Even set_max_delay which can be useful for constraining clock domain crossing paths is disabled.  Even worse, this effect will propagate into other IP cores with scoped constraints and disable constraints in there.

 

Is there a better way to de-constrain two asynchronous clock domains like this?

 

Positive suggestions would be useful.

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
Highlighted
Guide
Guide
8,805 Views
Registered: ‎01-23-2009

Take a look at this post on different ways of applying exceptions.

 

In general I greatly prefer setting exceptions on paths, not on clocks, and on anything more complex than a simple slow single bit synchronizer (and even sometimes then)  I generally prefer set_max_delay -datapath_only over set_false_path.

 

What puzzles me is that you get a timing violation from a clock crossing FIFO. If the FIFO comes from the IP catalog, then it also comes with an XDC file that has the proper path-based timing exceptions to cover the clock crossing paths. If the FIFO is a hand instantiated FIFO18 or FIFO36, then there are no timing paths between the domains - so where are you getting violations from?

 

Avrum

View solution in original post

0 Kudos
Highlighted
Advisor
Advisor
4,999 Views
Registered: ‎02-12-2013

I went back and recompiled with the asynchronous clock groups removed.  It was not a fifo path that created an error. It was a register to register path in my rtl.

 

I'm also beginning to see your point about asynchronous clock groups.  It can be dangerous.  It overrides constraints that may be wanted.  Also, if someone later adds a path that erroneously crosses domains you won't get a timing violation.

 

It is better to just go to the paths that you know are crossing domains and set_max_delay on exactly those paths.

 

Thanks for the advice.  Happy holidays.

 

  Pete

----------------------------------------
DSP in hardware and software
-----------------------------------------
Highlighted
Advisor
Advisor
4,957 Views
Registered: ‎02-12-2013

I tried the set_max_delay technique to deal with asynchronous clocks in a little design I have.  Below you can see the two asynchronous clock group commands commented out and the set_max_delay commands I use in place.

 

I think I do like this way of dealing with asynchronous clocks.  The process forces you to look at and address each type of path between domains.

 

#set_clock_groups -asynchronous -group [get_clocks clk_out2_little_clock_wiz] -group [get_clocks *TXOUTCLK]
set_max_delay -datapath_only -from [get_clocks *TXOUTCLK] -through [get_nets lane_up[*][*]] -to [get_clocks clk_out2_little_clock_wiz] 8
set_max_delay -datapath_only -from [get_clocks *TXOUTCLK] -through [get_nets channel_up[*]] -to [get_clocks clk_out2_little_clock_wiz] 8
set_max_delay -datapath_only -from [get_clocks *TXOUTCLK] -through [get_nets hard_err[*]]   -to [get_clocks clk_out2_little_clock_wiz] 8
set_max_delay -datapath_only -from [get_clocks *TXOUTCLK] -through [get_nets soft_err[*]]   -to [get_clocks clk_out2_little_clock_wiz] 8
set_max_delay -datapath_only -from [get_clocks clk_out2_little_clock_wiz] -through [get_nets reset[*]] -to [get_clocks *TXOUTCLK] 8

#set_clock_groups -asynchronous -group [get_clocks clk_out1_little_clock_wiz] -group [get_clocks clk_out2_little_clock_wiz]
set_max_delay -datapath_only -from [get_clocks clk_out2_little_clock_wiz] -through [get_nets gt_reset[*]] -to [get_clocks clk_out1_little_clock_wiz] 8

 

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
Highlighted
Guide
Guide
4,951 Views
Registered: ‎01-23-2009

That should work. While I don't like "clock to clock" constraints, the addition of the -through makes it much safer (basically equivalent to "cell to cell").

 

Of course, all these paths should have proper synchronizers on them - including having the ASYNC_REG property set on the flip-flops that are actually doing the metastability resolution.

 

Avrum

0 Kudos