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: 
9,826 Views
Registered: ‎03-11-2015

Virtex-5 Derived Clocks Problem

Hi!

 

I have a circuit with 4 Clocks, one main clock (used from the board (ML509), 100 MHz) and 3 derived via DCM (x2, x4, x8). I want to create an internal reset, so that the systems starts with a known phase relation between the clocks. To do that, I wrote the following code:

	locked_and <= and_reduce(locked);
	
	gen_phase_procs:for i in 0 to 3 generate
		proc_i:process(clks(i), rst) is 
		begin
			if (rst='1') then
				toggle_flops(i) <= '0';
			elsif rising_edge(clks(i)) then
				toggle_flops(i) <= not(toggle_flops(i)) and locked_and;
			end if;
		end process;
		
	end generate;
	
	--Logic to check if known phase relation happened (all rising_edge)
	process(clks(0), rst) is
	begin
		if (rst='1') then
			capture_flops <= (others => '0');
			fix_phase_relation <= '0';
		elsif rising_edge(clks(0)) then
			capture_flops <= toggle_flops;
			fix_phase_relation <= fix_phase_relation or and_reduce(toggle_flops xor capture_flops);
		end if;
	end process;
	
	int_rst <= rst or not(fix_phase_relation);

The vector locked are the 3 locked signals from the DCMs, the clks vector contains the 4 clocks (100 MHz to x8).

 

The point is, that this works as I want to in Simulation (added tiny delays to avoid shoot-through situation). The int_rst goes low after the first time all edges rise at the same time. But on the FPGA it doesn't work. I checked with Chipscope and all locked signals are high, but the fix_phase_relation remains low forever.

 

Any ideas?

0 Kudos
9 Replies
9,820 Views
Registered: ‎03-11-2015

Re: Virtex-5 Derived Clocks Problem

Not to be confused: by x2, x4 and x8; I meant multiplying the period, not the frequency.
0 Kudos
Professor
Professor
9,813 Views
Registered: ‎08-14-2007

Re: Virtex-5 Derived Clocks Problem

Did you do a post-route timing simulation?  It's possible that a behavioral simulation would not properly account for buffer delays.

-- Gabor
0 Kudos
9,808 Views
Registered: ‎03-11-2015

Re: Virtex-5 Derived Clocks Problem

I just realized that the edges does not have to be all rising at the same. All derived clocks are deskewed to CLK0, but they are not "aligned". Do you have quick tip, how I can make them have all the "same" phase? I'll try to explain with 2 pictures:

 

These are the clocks now:

        _   _   _   _   _
clk0  _| |_| |_| |_| |_| | 
___ ___ __
clk1 _| |___| |___|
_______
clk2 _____| |____

 

But I want them all aligned on the rising edges:

        _   _   _   _   _
clk0  _| |_| |_| |_| |_| | 
___ ___ __
clk1 _| |___| |___|
_______ __
clk2 _| |_______|

 

Is there an easy way to make it like that?

0 Kudos
Professor
Professor
9,798 Views
Registered: ‎08-14-2007

Re: Virtex-5 Derived Clocks Problem

Do the three clocks all come from the same DCM?  It might be easier to use a PLL for this type of issue.  On the other hand from a single DCM, I think you can use an input divide of 2, then use the CLK2X, CLK0, and CLKDIV (CLIKDIV_DIVIDE = 2.0) and end up with what you want.

-- Gabor
0 Kudos
9,795 Views
Registered: ‎03-11-2015

Re: Virtex-5 Derived Clocks Problem

Thanks for the elegant idea. I tried to solve it kind of quick and dirty with the risk of having additional skews by simply feeding the clock out to the next clock in of the next dcm. Seems to work, let's see if I can use it.

0 Kudos
Guide avrumw
Guide
9,788 Views
Registered: ‎01-23-2009

Re: Virtex-5 Derived Clocks Problem

If I understand correctly, you have a clock coming in at a frequency of X. You are using this clock as the input clock for 3 different DCMs, each using the CLKDIV output to generate clocks with frequencies of  X/2, X/4 and X/8 (they have to be different DCMs since there is only one CLKDIV from each DCM). You then want to control the phase of these so that they are aligned in some way...

 

The first thing to consider is the phase relationship between the input clock and the clock outputs of the DCMs. Assuming all the DCMs use the same feedback (i.e. a BUFG feedback from the CLK0 outputs), the 3 DCM clocks will have the same clock insertion latency, so if the edges aligned (due to the different dividers), the edges will be in phase and you can cross synchronously between them. However, the input clock will not be in phase with these other clocks - at very least you would need to use CLK0 from one of the DCMs for this clock.

 

As for controlling the dividers in the DCM, you probably can't do that... But you have a couple of options.

 

First, the Virtex-5 has PLLs. A PLL can generate multiple outputs using the same PLL. If you program the PLL for frequencies of X, X/2, X/4 and X/8, all 4 clocks will be phase aligned - there is one edge every 8 clock periods where all 4 clocks will be aligned. It is then easy to find which clk_X period corresponds to the change in state of the X/8 clock (use a toggle FF on the X/8 clock; on the clk_X clock where the state of that toggle FF has changed state is the clock after they all aligned).

 

Another option is to ignore the DCMs and PLLs and just use BUFGCEs. Run your input clock to 1 BUFG (for clk_X) and 3 BUFGCEs, one for each of the other clocks. Implement a counter on clk_X that enables the BUFGCEs every other clock, every 4th clock and every 8th clock respectively. By definition, this counter determines the relative phase of the 4 clocks, and you can use that counter to generate status signals to the logic in all 4 clock domains to determine what they should do in each phase.

 

Using the BUFGCEs, all 4 clocks will be in phase. The only thing you need to be aware of is that the divided (really decimated) clocks will not have 50/50 duty cycle, so you cannot use the falling edges or ODDR cells with them.

 

Avrum

0 Kudos
Professor
Professor
9,781 Views
Registered: ‎08-14-2007

Re: Virtex-5 Derived Clocks Problem


@slackborrower wrote:

Thanks for the elegant idea. I tried to solve it kind of quick and dirty with the risk of having additional skews by simply feeding the clock out to the next clock in of the next dcm. Seems to work, let's see if I can use it.


Cascading DCMs is generally considered bad practice.  Jitter through the DCM is never attenuated, and jitter created by each DCM is therefore additive.  In the end your final DCM will be prone to losing lock.  I think that either using a PLL or BUFGCEs and a fabric-based counter as suggested by Avrum would be a better approach.

-- Gabor
0 Kudos
9,769 Views
Registered: ‎03-11-2015

Re: Virtex-5 Derived Clocks Problem

Yes, I know it's a bad way to do it. It actually did work, although throwing me a lot of Component Switching Limit errors after P&R.

So I want to do it in a nice way now and using a PLL with 3 divided CLK-outputs. Now I get the message "Unusually high hold time violations" at all the clock domain crossing nets. It did not set any additional constraints except my main clock should be 10 ns. Are the clocks now seen as asynchronous or why am I getting so many hold time violations suddenly? And how to fix?

 

Ah, and btw thanks for this great help and effort here in general :).

0 Kudos
Guide avrumw
Guide
9,762 Views
Registered: ‎01-23-2009

Re: Virtex-5 Derived Clocks Problem

Your input clock should only go to the CLKIN of the PLL, and not be used by anything else. The four clocks you want should come from 4 outputs of the PLL and they should all go through a BUFG before being used. If you do this, then there shouldn't be any hold time issues in the system - even between different domains.

 

If all 4 clocks come from the same PLL, the tools understand that they are related and understand the timing relationships between them. If you have a PERIOD constraint on the input clock, then you shouldn't need anything else.

 

Avrum

0 Kudos