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: 
Adventurer
Adventurer
422 Views
Registered: ‎05-18-2018

MMCM CLKIN1_PERIOD being populated with mystery value

I am trying to get an MMCM primitive to work with Vivado 2019.1 and an Ultrascale+ SoC. After synthesizing the design, I see the following errors and warnings:

[DRC PDRC-179] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 699.965 MHz (CLKIN1_PERIOD, net vid_clk) for the VCO operating frequency of the MMCM site MMCM_X0Y0 (cell top_i/lcd/Flex_LCD_Controller_0/U0/ultra_ali3_controller_core_l/clock_generator_serdes/tx_mmcm) falls outside the operating range of the MMCM VCO frequency for this device (800.000 - 1600.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 (20.000999), multiplication factor CLKFBOUT_MULT_F (14.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device.
[DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell top_i/lcd/Flex_LCD_Controller_0/U0/ultra_ali3_controller_core_l/clock_generator_serdes/tx_mmcm. The computed FVCO is 699.965 MHz. The valid FVCO range for speed grade -1 is 800MHz to 1600MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 14.000, CLKIN1_PERIOD = 20.00100, and DIVCLK_DIVIDE = 1 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).
This violation may be corrected by:
  1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run.  Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range.
  2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range.
  3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range.
  4. The MMCM configuration may be dynamically modified by use of DRP which is recognized by an ACTIVE signal on DCLK pin.

 

CLKFBOUT_MULT_F = 14.0 and DIVCLK_DIVIDE = 1 are correct per my HDL. I have hard-coded CLKIN1_PERIOD as 17.0; this should not be "20.000999". An older version of my code had CLKIN1_PERIOD = 20.0, but I do not know where 20.000999 came from.

 

MMCME3_BASE # (
         //.CLKIN1_PERIOD      (CLKIN_PERIOD),
         .CLKIN1_PERIOD      (17.00),
         .BANDWIDTH          ("OPTIMIZED"),
         .CLKFBOUT_MULT_F    (7 * VCO_MULTIPLIER),
         .CLKFBOUT_PHASE     (0.0),
         .CLKOUT0_DIVIDE_F   (2 * VCO_MULTIPLIER),
         .CLKOUT0_DUTY_CYCLE (0.5),
         .CLKOUT0_PHASE      (0.0),
         .DIVCLK_DIVIDE      (1),
         .REF_JITTER1        (0.100)
      )
      tx_mmcm (
         .CLKFBOUT       (px_pllmmcm), // 1/7 incoming rate
         .CLKFBOUTB      (),
         .CLKOUT0        (tx_pllmmcm_div2), // 
         .CLKOUT0B       (),
         .CLKOUT1        (),
         .CLKOUT1B       (),
         .CLKOUT2        (),
         .CLKOUT2B       (),
         .CLKOUT3        (),
         .CLKOUT3B       (),
         .CLKOUT4        (),
         .CLKOUT5        (),
         .CLKOUT6        (),
         .LOCKED         (cmt_locked),
         .CLKFBIN        (px_clk),
         .CLKIN1         (clkin),
         .PWRDWN         (1'b0),
         .RST            (reset)
     );

 

Anyhow, the values shown in my source window should result in CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE = 14.0 * 1000 / (17.0 * 1) = 823.5 MHz, which fits in the [800, 1600] MHz window for the MMCM.

Is there a way to completely flush out older synthesis products, or is this another problem?

 

Tags (3)
0 Kudos
6 Replies
Xilinx Employee
Xilinx Employee
363 Views
Registered: ‎01-30-2019

Re: MMCM CLKIN1_PERIOD being populated with mystery value

Hi @joelschad 

have you tried resetting the synthesis run ?

once you reset the run please check the contents of your <project_name>.runs/synth_1 

Although not recommended but even after resetting the run if there are any files present in the folder delete them and then try.

try this and let us know.

--Suraj 

0 Kudos
Adventurer
Adventurer
329 Views
Registered: ‎05-18-2018

Re: MMCM CLKIN1_PERIOD being populated with mystery value

This pin was being driven by an upstream Clock Wizard block, and I thought I had updated it. The clock was set to run at ~50 MHz (20 ns period). The problem appears to be resolved by changing the Clock Wizard output to 60 MHz to match the 16.666 ns period in the MMCM field, but I have follow-up questions.

If the pin of the MMCM is driven by a something with an assigned frequency (like a Clock Wizard output or a PL clock), why does Vivado throw an error instead of just overriding the value?

What if the values are close but not exactly equal? Right now, I have the Clock Wizard outputting 60 MHz nominal (59.999 MHz actual), but my period input to the MMCM is 16.666 ns, or ~60.0024 MHz. These don't exactly match and no error is being thrown, but does the MMCM somehow compensate for a 59.999 MHz input clock and period value that suggests the clock is running at 60.0024 MHz?

0 Kudos
Xilinx Employee
Xilinx Employee
299 Views
Registered: ‎04-12-2012

Re: MMCM CLKIN1_PERIOD being populated with mystery value

Hi,

Please note that Vivado STA takes timing constraints from “XDC”, not that attribute. Timing constraints are propagated to downstream, so your primary timing constraint(period constraint on input of clocking wizard) must be base for any downstream timing analysis.

Thanks,

Takayoshi

-------------------------------------------------------------------------
Don`t forget to reply, kudo, and accept as solution
-------------------------------------------------------------------------
Adventurer
Adventurer
275 Views
Registered: ‎05-18-2018

Re: MMCM CLKIN1_PERIOD being populated with mystery value

Which XDC file stores this constraint, the XDC for the upstream block or the downstream block?

The pin I'm worried about is driven by the output of a Clocking Wizard, but I don't see the new period (16.6675 ns according to Vivado) listed anywhere in the OOC XDC files in the synth folder for that block.

I also don't see an XDC file in the synth folder for the downstream block that receives the clock signal (a custom IP I built). Am I looking in the wrong place?

0 Kudos
Xilinx Employee
Xilinx Employee
253 Views
Registered: ‎05-08-2012

Re: MMCM CLKIN1_PERIOD being populated with mystery value

Hi @joelschad 

This message usually indicates a descrepancy between the MMCM settins and the constrtaints that affect the MMCM. The 17.00 ns CLKIN1_PERIOD would need to be set in the Clocking Wizard IP customization GUI, unless you are going to instantiate the MMCM.

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
238 Views
Registered: ‎04-12-2012

Re: MMCM CLKIN1_PERIOD being populated with mystery value

Timing constraints should be IP folder which you can see in IP sources tab(ipname.xdc).

That contain only input of clocking wizard and output frequencies are automatically caluculated based on that.

Please check Auto-Derived Clocks section of UG949.

If you want to check clocks in design, you can use report_clocks command to see details of clocks.

Let me know if you cannt find what you want to see.

-------------------------------------------------------------------------
Don`t forget to reply, kudo, and accept as solution
-------------------------------------------------------------------------
0 Kudos