• 0
Maciej Piechotka

Error [DRC PDRC-34] when trying to use dvi2rgb on Vivado 2017.4

Question

[DRC PDRC-34] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 1650.165 MHz (CLKIN1_PERIOD, net CLK_IN_hdmi_clk) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X0Y0 (cell test_i/dvi2rgb_0/U0/TMDS_ClockingX/DVI_ClkGenerator) falls outside the operating range of the MMCM VCO frequency for this device (600.000 - 1200.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 (6.059999), multiplication factor CLKFBOUT_MULT_F (10.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device.

I tried to use both clocking wizard and clock from Zynq. I set them to 200 MHz but I got the error above. What have I done wrong?

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

Translation of the error message:

The MMCM primitive in dvi2rgb is getting a 165MHz input clock, which it multiplies by 10 and divides by 1, resulting 1650 MHz internal VCO frequency. This is outside its operating range as per the Zynq datasheet.

The problem is that the DVI implementation needs a serialization clock five times the frequency of the input clock. There are several sets of multiplier and divider values possible to achieve this, but not all result in a valid VCO frequency and no single set covers the whole range of pixel frequencies (video resolutions). Adjust the IP settings to higher expected resolutions: >120 MHz (1080p).

BTW all this is already described in the dvi2rgb user guide.

Edited by elodg

Share this post


Link to post
Share on other sites
  • 0
8 hours ago, elodg said:

Translation of the error message:

The MMCM primitive in dvi2rgb is getting a 165MHz input clock, which it multiplies by 10 and divides by 1, resulting 1650 MHz internal VCO frequency. This is outside its operating range as per the Zynq datasheet.

The problem is that the DVI implementation needs a serialization clock five times the frequency of the input clock. There are several sets of multiplier and divider values possible to achieve this, but not all result in a valid VCO frequency and no single set covers the whole range of pixel frequencies (video resolutions). Adjust the IP settings to higher expected resolutions: >120 MHz (1080p).

BTW all this is already described in the dvi2rgb user guide.

Thanks. I just figure it out yesterday (I thought that I posted update). However where is the guide? The one I was using refers to clock consistently as 200 MHz. There is mention about problems but it seems to be connected from the guide to be for HDMI clock recovery. It might be clear for someone that already knows that but if one tries to figure it out it's rather opaque.

Share this post


Link to post
Share on other sites
  • 0

@JColvin The problem with section 3 and 6 is that they refer to TMDS Clk only. However the problem seems to be in RefClock which is only documented as 200 MHz in section 4 and 5 - signal is literally described as "200 MHz reference clock" in signal description...

It might be that someone more familiar with FPGAs and/or DVI might've deduce it from documentation but after reading 3 times after I know what the solution is I have no idea how was I suppose to get it from documentation

Share this post


Link to post
Share on other sites
  • 0

What makes you think the culprit is RefClk?

I will add a debugging section to the documentation to make recognizing the error message easier. 

Share this post


Link to post
Share on other sites
  • 0
On 1/30/2018 at 12:51 AM, elodg said:

Translation of the error message:

The MMCM primitive in dvi2rgb is getting a 165MHz input clock, which it multiplies by 10 and divides by 1, resulting 1650 MHz internal VCO frequency. This is outside its operating range as per the Zynq datasheet.

The problem is that the DVI implementation needs a serialization clock five times the frequency of the input clock. There are several sets of multiplier and divider values possible to achieve this, but not all result in a valid VCO frequency and no single set covers the whole range of pixel frequencies (video resolutions). Adjust the IP settings to higher expected resolutions: >120 MHz (1080p).

BTW all this is already described in the dvi2rgb user guide.

I ran into the same issue on the using the DVI-to-RGB 1.9 IP Core when building the Nexys HMDI example (https://github.com/Digilent/Nexys-Video-HDMI). I tried building with Vivado 2017.4, and had to manually update DVI-to-RGB from 1.7 to 1.9 to point to the correct version in vivado-library (https://github.com/Digilent/vivado-library).

Upon changing the resolution to >120 MHz (1080p), I am able to generate a bitfile. However, when reporting timing, the design fails to meet timing. I have included the timing report (timing1.txt), the WNS is -4.2 ns and the TNS is about -13,000 ns. I tried removing the debug ILA cores in DVI-to-RGB (debug off) to see if that helped timing, along with changing the implementation strategy with no luck.

 

I was able to successfully build and test the project from this release using Vivado 2018.2 and DVI-to-RGB 1.7 IP Core:
- Configured for < 120 MHz
https://github.com/Digilent/Nexys-Video-HDMI/releases/download/v2018.2-1/Nexys-Video-HDMI-2018.2-1.zip

 Not sure how else to troubleshoot these timing errors on DVI-to-RGB 1.9 and  >120 MHz (1080p)

timing1.txt

Share this post


Link to post
Share on other sites
  • 0

Writing to confirm that there are indeed timing errors in the reference project that will take some time to fix. There is an XDC in dvi2rgb that is getting synthesized by mistake (lost property during an update) and the locked signal not being synchronous to PixelClk as the reset module is expecting.

Share this post


Link to post
Share on other sites
  • 0
On 10/7/2019 at 10:37 AM, elodg said:

Writing to confirm that there are indeed timing errors in the reference project that will take some time to fix. There is an XDC in dvi2rgb that is getting synthesized by mistake (lost property during an update) and the locked signal not being synchronous to PixelClk as the reset module is expecting.

So a workaround would be to remove the xdc file sets from the component.xml file?

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, mescobar2014 said:

So a workaround would be to remove the xdc file sets from the component.xml file?

Can confirm that commenting out the xdc files in component.xml resolves timing errors for DVI-to-RGB 1.9 IP Core with >120 MHz (1080p) configuration.

Thanks for the help! :)

https://github.com/Digilent/vivado-library/blob/master/ip/dvi2rgb/component.xml

<!--
<spirit:file>
  <spirit:name>src/ila_timing_workaround.xdc</spirit:name>
  <spirit:userFileType>xdc</spirit:userFileType>
  <spirit:userFileType>USED_IN_implementation</spirit:userFileType>
  <spirit:userFileType>USED_IN_synthesis</spirit:userFileType>
  <spirit:define>
    <spirit:name>processing_order</spirit:name>
    <spirit:value>late</spirit:value>
  </spirit:define>
</spirit:file>
<spirit:file>
  <spirit:name>src/dvi2rgb.xdc</spirit:name>
  <spirit:userFileType>xdc</spirit:userFileType>
</spirit:file>
<spirit:file>
  <spirit:name>src/dvi2rgb_ooc.xdc</spirit:name>
  <spirit:userFileType>xdc</spirit:userFileType>
</spirit:file>
-->

 

Share this post


Link to post
Share on other sites
  • 0

Upgraded dvi2rgb to 2.0 and pushed the changes of Nexys-Video-HDMI to GitHub. If you take that and change the TMDS Clock frequency constraint in the xdc and the dvi2rgb clock range, it should meet timing.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now