cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cospandesign
Observer
Observer
5,061 Views
Registered: ‎07-23-2013

MMCM_ADV Clocking Wizard Generates an FVCO out of spec (just barely)

Jump to solution

Hello,

 

I'm working with an Artix7 XC7A200T-1FBG676C and I want to use a 150MHz clock to generate

CLK0 = 150MHz

CLK1 = 400MHz

CLK2 = 200MHz

 

I used the coregen tool to generate it. I selected the MMCM_ADV and coregen selected the following settings to achieve these clocks

 

CLKFBOUT_MULT_F = 8.00

CLKOUT0_DIVID_F = 8.00

CLKOUT1_DIVIDE = 3

CLKOUT2_DIVID = 6

 

The CLK1 and CLK2 are to be used for a DDR3 SODIMM with CLK1 as the sys_clk and clock 2 as the ref_clk. The problem arrise when I am running through map, here is the specific error:

 

[LIT 693] Block 'MMCME2_ADV symbol "instance_name/mmcm_adv_inst"' has its target frequency, FVCO, out of range. Valid FVCO range varies depending on speed grade: 600MHz - 1200MHz(-1), 600MHz - 1440MHz(-2), 600MHz - 1600MHz(-3). The computed FCVO is a function of the input frequency CLKIN1_PERIOD, the division factor DIVCLK_DIVIDE, and the CLKFBOUT_MULT_F attribute (FVCO = 1000*CLKFBOUT_MULT_F/(CLKIN1_PERIOD*DIVCLK_DIVIDE)). The CLKIN_PERIOD attribute may have been set by ngdbuild based on the user specified PERIOD constraint. The current calculated FVCO is 1200.120012 MHz.

 

As you can see coregen generated a clock slightly out of spec. I'd like to know what my options are, I have a few proposals/questions:

 

1. Can I just override this error and use the slightly out of spec frequency?

2. I would prefere to use this 150MHz clock because it's very clean and comes in on the IBFUGDS from one of the GTXs but I could potentially use the 100MHz clock that is used for the rest of my logic. This would easily generate all the frequencies I desire.

3. Can I slightly reduce the multiplier and divider of clock 0 to achieve a frequency just under 1.2GHz because the inputs to the CLKFBOUT_MULT_F and CLKOUT0_DIVID_F are floating point so I could modify these values and CLK1 and CLK2 would be silght less than 400MHz and 200MHz respectively. The issue I have with this is that the 200MHz is used as a reference for the tap controller and I am unsure how accurate it needs to be.

 

Thanks in advanced for any help.

 

Sincerely,

Dave McCoy

 

0 Kudos
Reply
1 Solution

Accepted Solutions
avrumw
Guide
Guide
6,495 Views
Registered: ‎01-23-2009

Dave,

 

The warning comes from the calculation done by the timing analyzer, which is based on your constraints.

 

The VCO is running at Fclkin * CLKFBOUT_MULT_F. It gets the frequency of CLKIN from your PERIOD constraint on the input clock, which (by inference) you set to 6.666ns. This corresponds not to 150MHz, but to 150.01500150MHz. When multiplied by 8, this gives 1200.120012 (which is what the report tells you).

 

If you change the PERIOD constraint to 6.667ns, this error will go away. Alternatively, you can specify it as 150MHz (instead of 6.666ns), and this should give you exactly 1200 after the multiplication - the UCF format allows the PERIOD constraint to be specified either in nanoseconds or in frequency.

 

The only warning is if you have any related timespecs in your UCF (i.e. a FROM/TO or PERIOD constraint that is specified as TS_<primary_clock> * factor. If the primary clock is specified in ns, then the derived period is the period of the primary clock multiplied by the factor (the clock runs slower than the primary clock). If the primary clock is in MHz, then the frequency of the derived clock is mulitplied by factor - thus the clock is faster than the primary clock.

 

Avrum

View solution in original post

0 Kudos
Reply
2 Replies
austin
Scholar
Scholar
5,059 Views
Registered: ‎02-27-2008

Dave,

 

I do not understand why it gives you 1200.12 MHz, as it will generate exactly 1200 MHz in the PLL VCO.  Sounds like the tools are rounding off the numbers for the period....

 

Regardless, we can only sell what we gaurantee, so if it mutiplies the input clock up to exactly 1200 MHz (because it must get 1200 MHz when it runs....as long as you do not round off the period to 6.67 ns!) is is going to work, and it is gauranteed.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
avrumw
Guide
Guide
6,496 Views
Registered: ‎01-23-2009

Dave,

 

The warning comes from the calculation done by the timing analyzer, which is based on your constraints.

 

The VCO is running at Fclkin * CLKFBOUT_MULT_F. It gets the frequency of CLKIN from your PERIOD constraint on the input clock, which (by inference) you set to 6.666ns. This corresponds not to 150MHz, but to 150.01500150MHz. When multiplied by 8, this gives 1200.120012 (which is what the report tells you).

 

If you change the PERIOD constraint to 6.667ns, this error will go away. Alternatively, you can specify it as 150MHz (instead of 6.666ns), and this should give you exactly 1200 after the multiplication - the UCF format allows the PERIOD constraint to be specified either in nanoseconds or in frequency.

 

The only warning is if you have any related timespecs in your UCF (i.e. a FROM/TO or PERIOD constraint that is specified as TS_<primary_clock> * factor. If the primary clock is specified in ns, then the derived period is the period of the primary clock multiplied by the factor (the clock runs slower than the primary clock). If the primary clock is in MHz, then the frequency of the derived clock is mulitplied by factor - thus the clock is faster than the primary clock.

 

Avrum

View solution in original post

0 Kudos
Reply