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
585 Views
Registered: ‎03-15-2012

Source Syncronous DDR input

Jump to solution

hi,

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.

lmh_struct.png

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.

Timing without IDELAY.png

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

Timing with IDELAY.png

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?

greetings

PS: this are my constraints (from language template)

# SDI receive clock
# set lmh0341 input

# Center-Aligned Double Data Rate Source Synchronous Inputs
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1/2 cycle, hold = 0 cycle).
#
# input                  ____________________
# clock    _____________|                    |_____________
#                       |                    |
#                dv_bre | dv_are      dv_bfe | dv_afe
#               <------>|<------>    <------>|<------>
#          _    ________|________    ________|________    _
# data     _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_
#

create_clock -period 3.367 -name LMH0341_RECCLK [get_ports IO_B65_L12_GC_AB8_P]

set input_clock         LMH0341_RECCLK;    # Name of input clock
set input_clock_period  3.367;             # Period of input clock (full-period)
set dv_bre              0.700;             # Data valid before the rising clock edge
set dv_are              0.700;             # Data valid after the rising clock edge
set dv_bfe              0.700;             # Data valid before the falling clock edge
set dv_afe              0.700;             # Data valid after the falling clock edge
set input_ports [get_ports {IO_B65_L14_GC_AC6_P IO_B65_L17_AD10_AD4_P IO_B65_L19_AD9_AB3_P IO_B65_L20_AD1_AE3_P IO_B65_L8_AD5_AD10_P}];

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bfe] [get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                                [get_ports $input_ports];
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bre] [get_ports $input_ports] -clock_fall -add_delay;
set_input_delay -clock $input_clock -min $dv_afe                                [get_ports $input_ports] -clock_fall -add_delay;
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Voyager
Voyager
490 Views
Registered: ‎04-26-2012

Re: Source Syncronous DDR input

Jump to solution

@dm78   "But the UltraScales(+) drives me crazy, because there is no special IO-Clocking. I can only use BUFGs."

I've previously posted notes about constraining Ultrascale I/O clock trees to a single clock region & root, which I've found produces more repeatable I/O timing across runs and versions:

   https://forums.xilinx.com/t5/UltraScale-Architecture/Trouble-Implementing-a-Simple-Source-Sync-Input-DDR-Interface/m-p/897828#M7493

-Brian

Tags (1)
6 Replies
Moderator
Moderator
509 Views
Registered: ‎08-08-2017

Re: Source Syncronous DDR input

Jump to solution

Hi @dm78

I have few points to check here

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. 

Capture.PNG

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
-------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
499 Views
Registered: ‎03-15-2012

Re: Source Syncronous DDR input

Jump to solution

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?

0 Kudos
Highlighted
Voyager
Voyager
491 Views
Registered: ‎04-26-2012

Re: Source Syncronous DDR input

Jump to solution

@dm78   "But the UltraScales(+) drives me crazy, because there is no special IO-Clocking. I can only use BUFGs."

I've previously posted notes about constraining Ultrascale I/O clock trees to a single clock region & root, which I've found produces more repeatable I/O timing across runs and versions:

   https://forums.xilinx.com/t5/UltraScale-Architecture/Trouble-Implementing-a-Simple-Source-Sync-Input-DDR-Interface/m-p/897828#M7493

-Brian

Tags (1)
Adventurer
Adventurer
472 Views
Registered: ‎03-15-2012

Re: Source Syncronous DDR input

Jump to solution

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.

@brimdavis: I will look at it. Even more to consider :(

0 Kudos
Moderator
Moderator
463 Views
Registered: ‎01-16-2013

Re: Source Syncronous DDR input

Jump to solution

Hi @dm78,

I have comment on your last post, please refer below.

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.

Thanks,
Yash

 

Adventurer
Adventurer
443 Views
Registered: ‎03-15-2012

Re: Source Syncronous DDR input

Jump to solution

@yashpthe DRC told me that too (seen later), unlucky.

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.

thanks @all

0 Kudos