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

[Maciej Piechotka]

[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?

[jpeyron]

Hi @Maciej Piechotka,

I have reached out to more experienced engineers about this thread.

thank you,

Jon

[elodg]

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.

[Maciej Piechotka]

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.

[JColvin]

Hi @Maciej Piechotka,

I personally haven't used that particular IP core so this may be incorrect, but I believe @elodg is referring to sections 3 and 6 of the guide you linked to where you need to change the TDMS clock.

Thanks,
JColvin

[Maciej Piechotka]

@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

[elodg]

What makes you think the culprit is RefClk?

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

[mescobar2014]

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

[elodg]

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.

[mescobar2014]

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?

[mescobar2014]

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>
-->

 

[elodg]

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.