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!

Source Syncronous DDR input

i have to capture data from a LMH0341 SDI Deserializer. The data is send in DDR and center-aligned. The clock can be 27, 148.5 or 297 MHz depending on the SDI-Source. The setup and hold time is 650 ps each according to the data sheet.

For Spartan-6 and 7Series, it was quite simple. All i needed were IDDRs and IO-Clocking.

But the UltraScales(+) drives me crazy, because there is no special IO-Clocking. I can only use BUFGs. These BUFGs add a large delay, which i have to compensate or take into account eg. as multicycle. I would like to avoid using a PLL/MMCM for delay compensation, since they are not that many, take additional power and has to be reconfigured for each possible input clock.

So i use IDELAYs to delay the data till the clock arrives.

This worked for Vivado 2018.2 with one change, i had to increase the setup/hold to 700 ps. For 650 ps the timing analysis reports violation either for hold or for setup, because either fast clock and slow data or slow clock and fast data does not pass (although i think, it is too pessimistic). This work so far.

Recently i updated to 2018.3 and I struggle again although i did not change anything. I always have a large hold violation. Surprisingly the hold violation got worst if i add the IDELAYs.

This is a path without IDELAYs.

The same with IDELAYs (setted up for just 50 ps) looks like this:

As you can see, even the clock path is slower although the path wasn't changed. Now the violation is about 1.5 ns instead of 0.945 which cannot be compensated via IDELAY (max 1.1 ns for US+).

What does 2018.3 do different compared to 2018.2? Is 2018.3 brocken or 2018.2? Or (this is more likely) what did I do wrong?

How can i fix this to get the interface working, preferable without MMCM or PLL?

Re: Source Syncronous DDR input

1 .The setup and hold time is 650 ps each according to the data sheet -> Is this specifications same for DDR data rate corresponding to clocks 27, 148.5 and 297MHz ? as per my understanding from LMH0341 datasheet, this specification characterized at 2.97Gbps, 1.485 Gbps and 270 Mbps , production tested at 270 Mbps only.

You may need to talk to the Texas Support to get the accurate LVDS Switching characteristics for 297 MHz i.e 594 Mbps.

2. Considering LVDS Switching characteristics are same for 595 Mbps ,

As you can see, even the clock path is slower although the path wasn't changed. Now the violation is about 1.5 ns instead of 0.945 which cannot be compensated via IDELAY (max 1.1 ns for US+)

-> max 1.1ns for US+ is when Delay mode is TIME where the delay line is calibrated, controlled, and maintained for voltage and temperature by the IDELAYCTRL component. When Delay mode is COUNT , the total delay is equal to delay corresponds to number of Taps and delay line is not calibrated and maintained for VT changes. The more detailing of this is available in SelectIO user guide and in AR#60802

Consider 1.5ns fixed delay will solve the hold violations , then the recommendation is to cascade the Delay lines . The delay cascading detailing is documented on page 174 of SelectIO user guide

I hope ,i understood your issue.

-------------------------------------------------------------------------------------------------------------------------------Reply if you have any queries, give kudos and accept as solution-------------------------------------------------------------------------------------------------------------------------------

Re: Source Syncronous DDR input

Thanks for the answer, i was not aware of the cascade feature. I will try it, but i'm not confident that this will work, because i already had trouble using only one delay (i had to relax the 650 ps to 700 ps).

Nevertheless, is the timing report for 2018.2 with only 1 delay (which seems to work) broken? Or is it an option to roll back, because 2018.3 is broken or is there just a constraint missing?

Re: Source Syncronous DDR input

I may found a solution. As i thought, cascading 2 DELAYs make the timing worse. It allows passing the hold, but before that the setup gets violated. The solution (and i hope it is a valid solution) was simple disable the VTC. Since the longer clock path is not compensated over VT, the data path shouldn't be too. According to STA, it works even with the original values.

Re: Source Syncronous DDR input

Disabling the PVT analysis (over all the process) and getting it passed at timing is incorrect approach for timing closure. Xilinx do not recommend to analyze your design over specific PVT or specific corner by neglecting the rest.

Let's take your case if by disabling the some analysis timing may look clean but this won't ensure that the design will work over the range of PVT. You maybe getting positive numbers in software but you don't know if hardware might fall under different worst case corner.

Xilinx ISE previously has the temperature and voltage prorating options for specific voltage and temperature. But intentionally it's got deprecated so timing has to be fixed by user over the range and for all process corner.

At last Xilinx recommend to use all four process corner analysis for timing closure and then only guarantee the functional correctness over the range of VT.

Re: Source Syncronous DDR input

But, now i think i've a solution. @brimdavis mentioned CLOCK_LOW_FANOUT. This seems to revert the behaviour from 2018.3 to 2018.2 or at least makes it similar. With that constraint, the additional clock path delay is much smaller and only one DELAY (with VTC enabled) is needed again. Even the original parameter of 650 ps is met.