05-16-2018 08:55 AM
OK, so I am trying to use an MMCM to take in a differential 200MHz clock, and divide it down to 100MHz, and 20MHz. Both are even divisions. But for some reason, the MMCM wants to PLL internally up to 6859.863 MHz whish is WAAAAAAY out of it's range. I get the following error:
[DRC PDRC-34] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 6859.863 MHz (CLKIN1_PERIOD, net clk_div_10) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X1Y0 (cell u1_clink_top/u1_pll_clock/inst/mmcm_adv_inst) falls outside the operating range of the MMCM VCO frequency for this device (600.000 - 1440.000 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please run update_timing to update the MMCM settings. If that does not work, adjust either the input period CLKINx_PERIOD (7.143000), multiplication factor CLKFBOUT_MULT_F (49.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device.
So I tried to find the way to "update the timing", but there seems to be no way to do this in Vivado 2017.2 I'm trying to put this design into a Kintex-7 "-2" part. The dev board clock is set at 200MHz, so that's all I have to work with.
I can see why so many FAA DERs have refused to work with Vivado. There still seem to be many bugs and incapabilities in it.
Thanks in advance. Jim.
05-16-2018 09:06 AM
Did you use the clocking wizard in the IP Catalog. If not, I'd try that, and your issues will go way. 200 to produce 100 and 200 is a cake walk and won't result in a VCO frequency that is out of range. The VCO frequency will be 1GHz unless you're going into manual override (which in this case there is no reason to manually override clocking wizard multipliers/divders).
05-16-2018 12:03 PM
I'd be very very surprised if this was a tool bug. Now it's true that the clocking wizard is supposed to prevent you from generating MMCM parameters that violate the data sheet, but this kinda sounds like you started playing with the parameters and broke it. I instantiate MMCM primitives all the time, so I no longer bother with the clocking wizard, since it just generates a bunch of useless stuff for me.
Please dig into the Clock Wizard IP and post the actual VHDL/Verilog code containing the MMCM instance. I'll bet if we look at the parameters, the problem will be visible.
05-16-2018 03:15 PM
05-16-2018 03:16 PM
05-16-2018 08:38 PM - edited 05-16-2018 08:41 PM
Yes, I use the clocking wizard. And you're right, dividing by 2 and 10 should be a cakewalk. So I'm certain it's a bug in Vivado.
This is almost certainly not a bug - you have an error in your constraints and/or in the generation of the MMCM.
The clocking wizard is setting the M and D and O dividers of the MMCM based on the inputs you clocks you specify and the desired output clocks. The tools say that M=49, D=1 - these don't make sense for a design that is expecting to take in a 200MHz clock - that would result in a VCO frequency of 9800MHz, which is WAY out of range. So the MMCM is not configured correctly.
But it's even worse than that, this check is performed based on constraints. There is a clock that is arriving on the CLKIN pin of the MMCM - a "create_clock" command created a clock upstream of the net that drives the MMCM - either directly or through some other clock modifying block (i.e. another MMCM). The clock on this net has a frequency.
The check that generates this message takes that clock frequency on that input net and multiplies it by M/D to determine the VCO frequency (and check if it is in range). Given that M=49, D=1 and the tools are claiming that the resulting VCO frequency would be 6859.869, the tools think that a clock of frequency 140MHz is being applied to the CLKIN pin of the MMCM (not 200MHz).
It is almost inconceivable that this is a tool bug - a bug this significant would be seen by many people pretty much immediately (and I have seen no mention of anything like it) - it is far more likely that it is operator error...