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 efpkopin
Observer
236 Views
Registered: ‎01-20-2017

clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

I am building logic for a sub-block that will be integrated into a higher level project.  In that project, there is a clock generator that creates two 200 MHz clocks that are 180 degrees out of phase.  My sub-block only knows that these two clocks are inputs.  So I added the above constraint lines to define these two clocks into my IP:

create_clock -period 5.000 -name clk_200_A -waveform {0.000 2.500} [get_ports clk_200_A]
create_clock -period 5.000 -name clk_200_B -waveform {2.500 5.000} [get_ports clk_200_B]

But when I synthesize the design and look at the Clock Interaction matrix, the tool reports 'Partial False Paths' for these clocks (one unsafe). 

Attached is my clock interaction report

 Is there something else I have to specify to tell the tools to treat these as identical frequency but 180 degrees out of phase?

Or maybe the problem is that there is something else in my design identifying these as 'false paths'  There are fifo_rd_clks in the system - but I've identified these as asynchronous to these two input 200 MHz clocks (b/c the latter are my fifo_write_clocks, etc...) by using constraints as follows:

set_clock_groups -asynchronous -group [get_clocks fifo_rd_data_clk_clk_gen] -group [get_clocks clk_200_A]
set_clock_groups -asynchronous -group [get_clocks clk_200_A] -group [get_clocks fifo_rd_data_clk_clk_gen]
set_clock_groups -asynchronous -group [get_clocks fifo_rd_data_clk_clk_gen] -group [get_clocks clk_200_B]
set_clock_groups -asynchronous -group [get_clocks clk_200_B] -group [get_clocks fifo_rd_data_clk_clk_gen]
set_clock_groups -asynchronous -group [get_clocks clk_200_A] -group [get_clocks fifo_rd_clk_clk_gen]
set_clock_groups -asynchronous -group [get_clocks fifo_rd_clk_clk_gen] -group [get_clocks clk_200_A]
set_clock_groups -asynchronous -group [get_clocks clk_200_B] -group [get_clocks fifo_rd_clk_clk_gen]
set_clock_groups -asynchronous -group [get_clocks fifo_rd_clk_clk_gen] -group [get_clocks clk_200_B]

How can I figure out what is causing the 'false path' problem?

 

 

Capture.PNG
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
216 Views
Registered: ‎01-23-2009

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

So first,

 

create_clock -period 5.000 -name clk_200_A -waveform {0.000 2.500} [get_ports clk_200_A]
create_clock -period 5.000 -name clk_200_B -waveform {2.500 5.000} [get_ports clk_200_B]

is sufficient and correct to describe the two clocks coming in to the block for out-of-context (OOC) synthesis. For the real implementation, these constraints will be automatically generated by the MMCM that generates the two clocks.

 

As for your other constraints, there is nothing obvious in them that would affect the clk_200_A to clk_200_B paths...

But - these contraints are way overcomplicated and verbose.

First, when you use the set_clock_groups command it is bidirectional; -group {A} -group {B} declares all paths from A->B and all paths from B-> as false (so you can remove half of your commands).

Furthermore, if you have multiple clocks that you wish to remain synchronous, then just put them in the same group. Therefore, all 8 of your commands can be replaced by a single command

 

set_clock_groups -asynchronous -group [get_clocks {fifo_rd_data_clk_clk_gen fifo_rd_clk_clk_gen}] \
-group [get_clocks {clk_200_A clk_200_B}]

But, that being said - are you sure that these can really be declared as asynchronous paths? Take a look at this post on constraining clock domain crossing circuits and the comments that follow and the posts referenced in it. The set_clock_groups constraint it overrides all other constraints and can leave you with under-constrained clock domain crossing circuits.

As for the partial false paths, I don't know why it is doing this - there may be some other constraint from some other IP that applies to paths on clk_200_A. But even if you fix this, it is still going to claim that the paths between clk_200_A and clk_200_B are "unsafe" - it will always say this on paths from two different primary (create_clock) clocks - even if they have the same attributes. The tools cannot tell if these two 200MHz clocks are phase related (as they are in your case), or if they derive from two different oscillators, so it assumes the latter, in which case they would be "unsafe".

Avrum

 

5 Replies
Historian
Historian
217 Views
Registered: ‎01-23-2009

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

So first,

 

create_clock -period 5.000 -name clk_200_A -waveform {0.000 2.500} [get_ports clk_200_A]
create_clock -period 5.000 -name clk_200_B -waveform {2.500 5.000} [get_ports clk_200_B]

is sufficient and correct to describe the two clocks coming in to the block for out-of-context (OOC) synthesis. For the real implementation, these constraints will be automatically generated by the MMCM that generates the two clocks.

 

As for your other constraints, there is nothing obvious in them that would affect the clk_200_A to clk_200_B paths...

But - these contraints are way overcomplicated and verbose.

First, when you use the set_clock_groups command it is bidirectional; -group {A} -group {B} declares all paths from A->B and all paths from B-> as false (so you can remove half of your commands).

Furthermore, if you have multiple clocks that you wish to remain synchronous, then just put them in the same group. Therefore, all 8 of your commands can be replaced by a single command

 

set_clock_groups -asynchronous -group [get_clocks {fifo_rd_data_clk_clk_gen fifo_rd_clk_clk_gen}] \
-group [get_clocks {clk_200_A clk_200_B}]

But, that being said - are you sure that these can really be declared as asynchronous paths? Take a look at this post on constraining clock domain crossing circuits and the comments that follow and the posts referenced in it. The set_clock_groups constraint it overrides all other constraints and can leave you with under-constrained clock domain crossing circuits.

As for the partial false paths, I don't know why it is doing this - there may be some other constraint from some other IP that applies to paths on clk_200_A. But even if you fix this, it is still going to claim that the paths between clk_200_A and clk_200_B are "unsafe" - it will always say this on paths from two different primary (create_clock) clocks - even if they have the same attributes. The tools cannot tell if these two 200MHz clocks are phase related (as they are in your case), or if they derive from two different oscillators, so it assumes the latter, in which case they would be "unsafe".

Avrum

 

Observer efpkopin
Observer
206 Views
Registered: ‎01-20-2017

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

Avrum

Thanks for your quick reply.  It's quite helpful.  So I guess I should just leave the primary clocks defined as such and not set them as asynchronous to each other?  I guess when I bring this sub-block into the larger project, the constraints from the MMCM there will flow down & communicate to the tools that the clocks are phase related.  Do you agree?

Thanks for the link to the other post - I will review and reconsider.  I guess I just assumed the whole point of the FIFO is to allow two sets of clocks to operate independently on the flow of data.  But maybe there is something I'm not considering!

Thanks again

0 Kudos
Highlighted
Historian
Historian
188 Views
Registered: ‎01-23-2009

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

So I guess I should just leave the primary clocks defined as such and not set them as asynchronous to each other?

Which "primary" clocks? clk_200_A and clk_200_B - you should definitely not declare them as aysnchronous to eachother. Your description, your constraints for creating them and even your existing (and my modified) set_clock_groups -asynchronous constraints (which don't have these two clocks in different groups) all tell the tool exactly that, and the tools will correctly time paths between them as 1/2 of a clock period.

As for the relationship between {clk_200_A clk_200_B} and the fifo clocks, I can't speculate as to whether they should be in different clock groups or not - it all depends on how the clocks interact (although probably not - there are very few correct cases for using set_clock_groups). If the FIFO is a proper clock crossing FIFO, then, it allows you to pass data between two different (and asynchronous) clock domains - they are a clock domain crossing circuit (CDCC). Whenever there is a CDCC, some paths should not be timed synchronously. If the FIFO is a native FIFO (i.e. FIFO18* or FIFO36*) then there is no timing arc between the two sides of the FIFOs, so no exceptions are required (other than maybe one for reset). And regardless of whether the FIFO is native, or created by the FIFO wizard, the resulting IP will have all the exceptions required (all IP in Vivado comes with a scoped XDC file) - no other exceptions need to be written by the user.

So it is not possible for me to answer this question without knowing more specifics about what you are doing with these FIFOs and these clocks...

Avrum

Observer efpkopin
Observer
126 Views
Registered: ‎01-20-2017

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

Avrum,

Ok - I read the discussions in the posts you referenced and I'm a believer in the use of the set_max_delay for my system.  It is true that I am using the FIFO to handle the majority of the clock crossing data.  However, there are handshaking signals that I send back and forth to control the writing to and reading from the FIFO.

So I want to implement a constraint as you wrote in one of those other posts:

set_max_delay -from <source_FFs_on_source_domain> -to <destination_FFs_on_destination_domain> <value_less_than_source_clock_period> -datapath_only

Some questions:

 1. Is it prudent, as a first guess, to set the <value_less_than_source_clock_period> to 1/2 of that clock period?

2. I see that there are a lot of ways to specify the -from and -to values.  I'm new to this.  Is it possible for me to define named FF's that collect just the signals that cross the clock domains and specify my -from/-to using those names.

Let me give an example:

If I have source signals I want to send across the clock domain defined in a process as follows:

	sig_send_seq : process(clk_200_A, resetA)
	begin
		if (resetA = '1') then
			sig1_send	<= '0';
			sig2_send	<= '0';
			sig3_send	<= (others => '0');
		elsif rising_edge(clk_200_A) then
			sig1_send	<= sig1_comb;
			sig2_send	<= sig2_comb;
			sig3_send	<= sig3_comb;
		end if;	
	end process sig_send_seq;

and I 'receive' these signals on the 'other side' with a process as follows:

	sig_recv_seq : process(fifo_rd_data_clk, resetB)
	begin
		if (resetB = '1') then
			sig4		<= '0';
			sig5		<= (others => '0');
		elsif rising_edge(fifo_rd_data_clk) then
			sig4		<= sig4_comb;
			sig5		<= sig5_comb;
		end if;	
	end process sig_recv_seq;

where sig1_send, sig2_send and sig3_send are 'received' by combining them logicially (with other signals) to make up the signals sig4_comb and sig5_comb.

In this case, can I write my constraint in a form kind of like the following?

set_max_delay -from [get_FFs sig_send_seq] -to [get_FFs sig_recv_seq]  2.5 -datapath_only

Now, I know that 'get_FFs' is not a valid query.  But is there some easy way to pick off just the data signals you care about (by isolating them in a process) and specify them in a single constraint line in the spirit of what I just wrote?

 

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
Historian
Historian
109 Views
Registered: ‎01-23-2009

Re: clock constraints for two synchronous input clocks 180 degrees out of phase

Jump to solution

 1. Is it prudent, as a first guess, to set the <value_less_than_source_clock_period> to 1/2 of that clock period?

That is pretty conservative. The reality is that most people use the period of the source clock even though it should technically be the period of the source clock minus (the setup and hold requirement of the destination flip-flop plus the clock skew). But the reality is that these other factors are small - certainly well less than 1ns. So you could use the period of the source clock minus 1ns (rather than 1/2 of the clock period).

As for your second question, you cannot use the process name - that is lost during synthesis. However, Vivado supports all kinds of wild-card constructs for finding element (and a whole bunch of other mechanisms for finding things).

There is no "get_FFs" command; you use get_cells. If you want to restrict it to sequential cells, you can use

get_cells -filter {IS_SEQUENTIAL} <names of cells including wildcards>

Note that all flip-flops get the suffix _reg after synthesis, so you can do

set_max_delay -from [get_cells sig?_send_reg] -to [get_cells sig?_reg] ...

(or a whole bunch of other ways of doing wildcards -including full regular expressions using the "get_cells -regexp" command...

Avrum