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: 
Highlighted
Visitor pkopyt
Visitor
9,042 Views
Registered: ‎05-23-2014

Strange PLL_ADV problem

Jump to solution

Hallo!

I am trying to set up PLL_ADV primitive (Spartan 6) to generate two clocks: CLK0_OUT = CLK_IN * 2, CLK1_OUT = CLK_IN / 4, CLK2_OUT = CLK_IN / 8. I am using the CoreGenerator to calculate the primitive params for several CLKIN frequencies. And so I get the following settings for

 

CLKIN = 200 MHz:

 

CLKIN1_PERIOD = 5.0,

CLKFBOUT_MULT = 2,

DIVCLK_DIVIDE = 1,

CLKOUT0_DIVIDE = 1,

CLKOUT1_DIVIDE = 8,

CLKOUT2_DIVIDE = 16,

 

I  add the following line in the .ucf file: TIMESPEC TS_DDRClk_p_pin = PERIOD "DDRClk_p_pin" 5.0 ns HIGH 50 % INPUT_JITTER 0.01 ps;

 

and all looks good.

 

I try to repeat the same for CLKIN = 40 MHz

 

This time the CoreGen produces the following data:

CLKIN1_PERIOD = 25.0,

CLKFBOUT_MULT = 10,

DIVCLK_DIVIDE = 1,

CLKOUT0_DIVIDE = 5,

CLKOUT1_DIVIDE = 40,

CLKOUT2_DIVIDE = 80,

 

I add TIMESPEC TS_DDRClk_p_pin = PERIOD "DDRClk_p_pin" 25.0 ns HIGH 50 % INPUT_JITTER 0.01 ps;

 

I copy all the setting into my code and...

 

PhysDesignRules:2449 - The computed value for the VCO operating frequency
   of PLL_ADV instance SERDES_CLK_Inst/rx_pll_adv_inst is calculated to be
   2000.000000 MHz. This falls above the operating range of the PLL VCO
   frequency for this device of 400.000000 - 1000.000000 MHz. Please adjust
   either the input frequency CLKINx_PERIOD, multiplication factor CLKFBOUT_MULT
   or the division factor DIVCLK_DIVIDE, in order to achieve a VCO frequency
   within the rated operating range for this device.

 

Really strange as it looks like the tools still 'think' that the CLKIN is 200 MHz, altough I  do not see what else I should check (apart from the ucf entry). A short test of setting everything up for CLKIN = 200 MHz (CLKFBOUT_MULT = 2, etc.) but leaving the .ucf entry with PERIOD 25.0 ns produces an expected results:

 

PhysDesignRules:2449 - The computed value for the VCO operating frequency
   of PLL_ADV instance SERDES_CLK_Inst/rx_pll_adv_inst is calculated to be
   80.000000 MHz....

 

which suggests that the CLKIN is taken from my ucf and nowhere else.

 

Another test of setting the PLL_ADV like this (for 40 MHz, with correct ucf entry):

 

CLKIN1_PERIOD = 25.0,

CLKFBOUT_MULT = 10,

DIVCLK_DIVIDE = 1,

CLKOUT0_DIVIDE = 1, -- THERE SHOULD BE '5' HERE!!!!

CLKOUT1_DIVIDE = 40,

CLKOUT2_DIVIDE = 80,

 

generetes... no problems (sic!). All is fine for the tools (but clk0 is 5x too high)!

 

I wonder why should CLKOUT0_DIVIDE influence the VCO frequency? Also why the settings copied directly from the Core Gen for my device do not work in the first place? I will appreciate any hints at this points -- I am a bit confused about the suggestions from the CoreGen and the messages from the tools.

 

Best regards

 

Pawel

 

 

 

 

 

 

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Visitor pkopyt
Visitor
15,385 Views
Registered: ‎05-23-2014

Re: Strange PLL_ADV problem

Jump to solution

Hi!

 

One more observation based on several experiments... it looks like the tools work fine after all.

 

When one looks at Fig. 3-5 (ug382_c3_04_081710) and the neighbouring formulas to calculate VCO freq. for the PLL in a feedback loop, then it becomes obvious why my design worked fine for CLKIN 200 MHz (CLKOUT0_DIVIDE = 1) and did not work for 40 MHz (CLKOUT0_DIVIDE = 5). It seems like the CoreGen suggestions cannot be followed blindly as it does not account for the feedback network at all! Pity, as this means that I need to calculate all the coeff. by hand.

 

Pawel

 

View solution in original post

0 Kudos
4 Replies
Professor
Professor
9,026 Views
Registered: ‎08-14-2007

Re: Strange PLL_ADV problem

Jump to solution

This sounds like the classic "cached" data problem.  The stock answer is to "cleanup project files" in an attempt to lose all previous saved (precompiled) data.  The UCF indeed sources the value used in the design rule check.  However this gets converted to a PCF file during Map (if I remember correctly) and it's possible that the PCF file didn't update when you made the change.  Another possibility is that you have more than one UCF tied to the project.  I believe you can run a "conflicting constraint" report as one option to see if there is more than one place where the PERIOD constraint comes from.  Finally make sure you don't also have an XCF (synthesis) constraint file that overrides the UCF value.

-- Gabor
0 Kudos
Visitor pkopyt
Visitor
9,018 Views
Registered: ‎05-23-2014

Re: Strange PLL_ADV problem

Jump to solution

Hallo!

Many thanks for the reply.

 

> The stock answer is to "cleanup project files" in an attempt to lose all previous saved (precompiled) data

 

Well, I did that many times, even restarted the ISE environment afterwards. However the problem survives my cleaning up. I also copied all the files manually to another folder, set-up another ISE project and added the files one by one to make sure that nothing unnecessary bundles in. Does not help for CLKIN = 40 MHz case. Works as expected for the CLK_IN = 200 MHz case!

 

> and it's possible that the PCF file didn't update when you made the change

 

I also checked the contents of the PCF file, just in case. It does not hold anything suspicious -- the correct PERIOD info is copied from the UCF (i.e. if UCF says that PERIOD is 5 ns, the PCF repeats this, the same happens when the UCF has PERIOD of 25 ns -- PCF also holds this piece of info).

 

> I believe you can run a "conflicting constraint" report as one option to see if there is more than one place where the PERIOD constraint comes from

 

Well, it looks like the TSI report  cannot be generated without NCD file, which is created during mapping. Map stops when it discovers problems with the PLL_ADV set-up. However, the TSI report generated for my 200 MHz case (which implements all right) showed that there is no intesecting constraints for the CLK_IN time network that feeds the PLL_ADV. So either they appear only for the 40 MHz case, or this is not the cause of the problem.

 

> Finally make sure you don't also have an XCF (synthesis) constraint file that overrides the UCF value.

 

I checked if I have this file -- no I do not have it! I also carefully went over the "Hierarchy" of instances displayed in ISE to see if I do not have doule .ucf files. Well, only one such file is shown.

 

Well, my only chance is that the final goal is to have the CLK_IN 200 MHz or higher. Also all works fine when CLK_IN is 450 MHz (with proper changes made to UCF file, and PLL_ADV settings).

 

The 40 MHz case was needed only at the testing stage (to have a slow signal). If it does not work -- tough luck.

 

Regards

 

Pawel

 

0 Kudos
Visitor pkopyt
Visitor
15,386 Views
Registered: ‎05-23-2014

Re: Strange PLL_ADV problem

Jump to solution

Hi!

 

One more observation based on several experiments... it looks like the tools work fine after all.

 

When one looks at Fig. 3-5 (ug382_c3_04_081710) and the neighbouring formulas to calculate VCO freq. for the PLL in a feedback loop, then it becomes obvious why my design worked fine for CLKIN 200 MHz (CLKOUT0_DIVIDE = 1) and did not work for 40 MHz (CLKOUT0_DIVIDE = 5). It seems like the CoreGen suggestions cannot be followed blindly as it does not account for the feedback network at all! Pity, as this means that I need to calculate all the coeff. by hand.

 

Pawel

 

View solution in original post

0 Kudos
Visitor pkopyt
Visitor
8,983 Views
Registered: ‎05-23-2014

Re: Strange PLL_ADV problem

Jump to solution

Hallo!

 

So the reason for the error messages is known, now. I will however appreciate a lot hints at setting up the PLL so that I can generate low freq. signals that would normally require that CLK0_DIV be greater then one. If I want to work with CLK_IN of say 40 MHz how do I arrive at proper coeffs. if the CoreGen does not take into account the feed-back loop? What is the procedure you normally follow in such situation?

 

Regards

 

Pawel

 

0 Kudos