cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cjavid
Adventurer
Adventurer
12,604 Views
Registered: ‎06-30-2013

Timing Constraints for ADC LVDS DDR

Hi forum contributors:

 

This post is a follow-on post to my original post about how to implement a ZedBoard  Zynq 7020 DDR interface with the quad ADS62P49 ADC chips on FMC104 card .  With significant help & education from Avrum I was able to implement a working DDR interface to three of the four ADC channels at 100MSps.  The fourth channel has a data bus that spans two IO banks and that presents a problem for the current IO interface that uses BUFRs  to drive the IDELAYE2 and IDDR elements in the fabric.  I am ignoring this issue for now.  However, I now have a properly designed interface that uses one of the ADC channels' clock fed through an MMCM to generate a common clock domain to bring all three ADC channel data in using a small FIFO to provide the clock crossing for the mesosynchronous interface.  ADC data is now well correlated across the three channels once I properly configured the clock distribution PLL on the FMC104 so that all three of the ADC input clocks are aligned.

 

The reason for this post is to learn what strategies and approaches can be employed to permit operation at higher sample rates and with a sample clock that cannot have a 50% duty cycle.

 

The current design uses IDELAE2 elements driven by a 200MHz ref clock for all data bits with a 13 tap or approximate 1.01 ns delay to help align the clock data window of the ADS62P49 with clock data window that is specified for the Artix fabric for a clock-forwarded BUFIO as found from page 49 of DS187.  Is the specified .38ns of setup time and 1.86ns of hold time for the -1 speed grade applicable even though the IO wizard chose to use BUFRs instead of BUFIOs?

 

Table 77: Data Input Setup and Hold Times Relative to a Forwarded Clock Input Pin Using BUFIO

Symbol Description

Speed Grade

Units

                                                                           -3            -2            -1

Input Setup and Hold Time Relative to a Forwarded Clock Input Pin Using BUFIO for SSTL15 Standard.

TPSCS/TPHCS Setup and hold of I/O clock –0.38/1.39 –0.38/1.55 –0.38/1.86 ns

 

If so, then my design which as the data delay of about 13 taps and a clock  delay of zero taps is probably close to optimum.    Below is an example of the clock and OFFSET constraints that currently meet timing.  This timing is tighter than that required by the ADS62P49 at 100Msps since it is specified with -2ns/2ns setup/hold spec.  So I think I can operate at frequencies closer to 130MSsps.

 

NET "CLK_AB_P" TNM_NET= "CLK_FMC_AB" ;

TIMESPEC "TS_CLK_FMC_AB" = PERIOD "CLK_FMC_AB" 10 ns HIGH 50 %;

 

NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHA_N[*]" TNM = "adc_data_a";

NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHA_P[*]" TNM = "adc_data_a";

TIMEGRP "adc_data_a" OFFSET = IN 1.5 ns VALID 3 ns BEFORE CLK_AB_P RISING;

TIMEGRP "adc_data_a" OFFSET = IN 1.5 ns VALID 3 ns BEFORE CLK_AB_P FALLING ;

 

When I tightened up the OFFSET constraint to 1.2/2.4 I failed with many hold violations:

## failed timing with a score of 6370 at 1.2/2.4

Even this timing is a far cry from the 0.75/1.5ns required by the ADS62P49 for operation at 210MSps.  The folks at 4DSP have told me that they have successfully operated the ADS62P49 on their FMC150 card hosted on a ZedBoard at about 242MSps.

So my most significant questions are:

What strategies can I use to help meet the tighter OFFSET constraint? It appears that the IDELAYE2 and IDDR elements are located very close to the IOBs so are there any physical location constraints that can help meet timing at the IDDR clock/data inputs?  If my faster ADC clock does not have a 50% duty cycle does a modified PERIOD constraint allow the tool to meet the OFFSET constraint as specified?  If not, what do I need to tell the tool so it can handle an asymmetric clock?

If it is not possible to constrain the tool to meet static timing in the 7020 fabric what other clocking options are available to use with the a seven-line DDR interface?

 

Thanks in advance for any valuable guidance,

 

Craig

0 Kudos
5 Replies
avrumw
Guide
Guide
12,599 Views
Registered: ‎01-23-2009

Craig,

 

Post the datasheet report for this interface that is failing hold checks (at 1.2/2.4). Also send us the complete timing path report, both for the failing hold check as well as for the (presumably passing) setup check on the interface.

 

Avrum

0 Kudos
cjavid
Adventurer
Adventurer
12,562 Views
Registered: ‎06-30-2013

Hi Avrum:

 

Sorry for the delay in responding.  I hope you are having a nice Holiday.  I have attached the TRCE report for the faiiling condition that corresponds to operation of the ADS62P49 at 150MHz.  The daya sheet gives a min of 1.15 set-up and 1.1 hold at 153 MHz.  So I chose to set the clock to 150MHz and used the following constraints:

 

## constrain clock supplied each ADC's clock output from the FMC104
## banking conflict in CHE may preclude chip-sync interface????
## limit to two channels for now
## we cannot assume that CLK_AB=CLK_CD=CLK_EF=CLK_GH
NET "CLK_AB_P" TNM_NET= "CLK_FMC_AB" ;
####TIMESPEC "TS_CLK_FMC_AB" = PERIOD "CLK_FMC_AB" 10 ns HIGH 50 %;
TIMESPEC "TS_CLK_FMC_AB" = PERIOD "CLK_FMC_AB" 6.666 ns HIGH 50 %;

NET "CLK_CD_P" TNM_NET= "CLK_FMC_CD" ;
####TIMESPEC "TS_CLK_FMC_CD" = PERIOD "CLK_FMC_CD" 10 ns HIGH 50 %;
TIMESPEC "TS_CLK_FMC_CD" = PERIOD "CLK_FMC_CD" 6.666 ns HIGH 50 %;

NET "CLK_GH_P" TNM_NET= "CLK_FMC_GH" ;
####TIMESPEC "TS_CLK_FMC_GH" = PERIOD "CLK_FMC_GH" 10 ns HIGH 50 %;
TIMESPEC "TS_CLK_FMC_GH" = PERIOD "CLK_FMC_GH" 6.666 ns HIGH 50 %;
##assume 0.75ns setup and hold for ADS62P49 at 210MSps even though it would be 1.6/1.45ns
## at 125Msps or 2/2ns at less than 100MSps
## passed timing at 1.5/3
## failed timing with a score of 6370 at 1.2/2.4
## failed timing with a score of 2170 at 1.35/2.7
## failed timing with a score of 856 at 1.4/2.8
## failed timing with a score of 56 at 1.45/2.9

 

##use 1.15 set-up and 1.1ns hold for specified operation at 153MHz.  Use 150MHz or 6.666ns period
NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHA_N[*]" TNM = "adc_data_a";
NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHA_P[*]" TNM = "adc_data_a";
TIMEGRP "adc_data_a" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_AB_P RISING ;
TIMEGRP "adc_data_a" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_AB_P FALLING ;
NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHC_N[*]" TNM = "adc_data_c";
NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHC_P[*]" TNM = "adc_data_c";
TIMEGRP "adc_data_c" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_CD_P RISING ;
TIMEGRP "adc_data_c" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_CD_P FALLING ;

NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHG_N[*]" TNM = "adc_data_g";
NET "system_i/zed_panther_0/zed_panther_0/zed_top_0/CHG_P[*]" TNM = "adc_data_g";
TIMEGRP "adc_data_g" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_GH_P RISING ;
TIMEGRP "adc_data_g" OFFSET = IN 1.15 ns VALID 2.25 ns BEFORE CLK_GH_P FALLING ;

 

 

I have attached the timing report (.twr) saved as a text file but am not sure that this is the report you requested?  Ivwould appreciate any guidance that would enable to obtain cosure at the sample rate and perhaps even faster.

 

Thank you,

 

Craig

0 Kudos
avrumw
Guide
Guide
12,554 Views
Registered: ‎01-23-2009

Craig,

 

It would be nice to see the detailed timing report for the OFFSET IN timespecs, to ensure that the path is as expected.

 

From the datasheet report, though, something is odd. The tools are clearly telling you that the pins need 0.854ns setup and 1.446ns hold time (with the adjustment of your IDELAYs). This is a total wondow of 2.3ns, which is significantly higher than the datasheet values for Tpscs/Tphcs of -0.38, 1.86 for a window of 1.48ns. This is 820ps wider than it should be...

 

So, we need to figure out why.

 

First, we need to ensure that the clocking is constructed correctly - particularly that both the clock and data each go through IDELAYs with one of them (ideally the data) set to a tap value of 0 - an IDELAY with a tap value of 0 is not the same as having no IDELAY in the path.

 

There are a couple of things that (correctly) will widen the window. One is the clock jitter - but from your timing constraints, you haven't specified one, so it is 0 (although you probably should factor that in).

 

Another is the input buffer type. The Tpscs/Tphcs are specified for the SSTL15 I/O standard - I don't know what standard you are using (and if you have correctly informed the tool about this), but other I/O standards could be slightly different. However, since this is an input interface, the delay of the clock input and data input should almost completely cancel eachother out, so this shouldn't really be a significant factor.

 

After we rule these out, we have to figure out why there is this difference. I don't know if you have webcase access, but this might be a good question for them...

 

As for your other questions

 

What strategies can I use to help meet the tighter OFFSET constraint?

 

This mechanism is the best mechanism for static data capture. If this doesn't satisfy the OFFSET IN constraint, there is nothing better.

 

 It appears that the IDELAYE2 and IDDR elements are located very close to the IOBs so are there any physical location constraints that can help meet timing at the IDDR clock/data inputs?

 

There are fixed connections between the IBUF, IDELAY and IDDR, and there is a one-to-one relationship between them. Specifying a LOC on the pin (connected to the IBUF) automatically forces the IDELAY and IDDR to the correct location. No other locations are legal, and hence the tools don't need any other constraints.

 

 If my faster ADC clock does not have a 50% duty cycle does a modified PERIOD constraint allow the tool to meet the OFFSET constraint as specified?

 

If your clock is not 50/50, you have a big problem. This will mean that one of the two data windows is larger, and the other is smaller. The larger one doesn't help you, but the smaller one hurts. For example if your high time is 500ps shorter than your low time, then the total data capture window is 500ps smaller... There isn't really anything the tool or FPGA can do about this - if the window is smaller, you just can't run as fast.

 

 If not, what do I need to tell the tool so it can handle an asymmetric clock?

 

The "50%" at the end of the PERIOD constraint tells the tool about the clock duty cycle. However, it doesn't allow you to specify a range; you can say 60%, which means that the high time is 60% of the period, and therefore the low time is 40%. But, what is really important is how does this affect your data windows. Your ADC specifies the provided SU and H, and these are what you used to specify the OFFSET IN. But these numbers are only valid under some conditions stated in the ADC datasheet; clearly if you provide it with a very assymetric clock, it can't possibly generate these SU/H numbers. For example if your clock is 75/25, then the low time is only 1.66ns long - there is no way the ADC can provide a 2.25ns window in this 1.66ns 1/2 clock cycle!

 

If it is not possible to constrain the tool to meet static timing in the 7020 fabric what other clocking options are available to use with the a seven-line DDR interface?

 

If you can't capture it statically, then you will have to do it dynamically. Basically you have a state machine that finds the "ideal" IDELAY tap value at this process/voltage/temperature point - presumably using a training pattern (which may or may not be possible with the ADC). I am sure there is an XAPP note describing how to do this for the 7 series (or for a Virtex 5/6, which is basically the same) - but I couldn't find it quickly.

 

Avrum

0 Kudos
cjavid
Adventurer
Adventurer
12,546 Views
Registered: ‎06-30-2013

Hi Avrum:

 

You have answered many of my questions but I am still a bit ignorant of  some of the fundamentals so let me clarify  your responses and requests:



It would be nice to see the detailed timing report for the OFFSET IN timespecs, to ensure that the path is as expected.

 

How do I provide you with that info?  Do I need to change the configuration for the TRCE generation?  Or, is there different report that needs to be generated?

 

 

This is a total window of 2.3ns, which is significantly higher than the datasheet values for Tpscs/Tphcs of -0.38, 1.86 for a window of 1.48ns. This is 820ps wider than it should be...

 

I originally thought the total data window would have been 0.38ns + 1.86ns = 2.24ns but the 1.48ns value you state implies that the set-up time is really negative and data can actually be changing up to 0.38ns after the clock edge - I this correct?  If not please help me understand how to interpret the negative sign.

 

 

First, we need to ensure that the clocking is constructed correctly - particularly that both the clock and data each go through IDELAYs with one of them (ideally the data) set to a tap value of 0 - an IDELAY with a tap value of 0 is not the same as having no IDELAY in the path.


My understanding from your previous guidance was to use IDELAYE for all DDR signals with 13 taps (78ps per tap with a 200MHz REF clock) and to pass the clock signal through an IDELAYE with a zero tap delay.  Did I misunderstand what you told me previously about the strategy to align the clock data given the clock forwarded Tpscs/Tphcs specs?  As to your other question about IO standards, I actually raised the issue in a previous post  because I am using LVDS_25  and a BUFR in the clock/data input section.  From what I could find in the Artix data sheet, the Tpscs/Tphcs specs were for a BUFIO with SSTL_15 standard.  So I am not even sure if the numbers -0.38, 1.86 are correct?  How does one treat the BUFR and and the use of a different IO standard?

 

 

There are a couple of things that (correctly) will widen the window. One is the clock jitter - but from your timing constraints, you haven't specified one, so it is 0 (although you probably should factor that in).

 

Yes, I understand that it is not zero but I am not sure how to specify the jitter for each ADC input clock (which is the same for each channel clock presumably since it is the re-generated clock form the ADC chip.  Is this specified in the UCF file together with the PERIOD and duty cycle?  If so, how?

 

 

If your clock is not 50/50, you have a big problem. This will mean that one of the two data windows is larger, and the other is smaller. The larger one doesn't help you, but the smaller one hurts. For example if your high time is 500ps shorter than your low time, then the total data capture window is 500ps smaller... There isn't really anything the tool or FPGA can do about this - if the window is smaller, you just can't run as fast.

 

OK, it sounds like I need to choose sample clock frequencies with which the external synthesizer chip can generate with a 50/50 duty cycle.  150MHz and 200MHz can be generated at a 50% duty cycle so I try and target operation at one of these frequencies.

 

 

If you can't capture it statically, then you will have to do it dynamically. Basically you have a state machine that finds the "ideal" IDELAY tap value at this process/voltage/temperature point - presumably using a training pattern (which may or may not be possible with the ADC). I am sure there is an XAPP note describing how to do this for the 7 series (or for a Virtex 5/6, which is basically the same) - but I couldn't find it quickly.

 

OK, this would appear to be similar to the approach used for DDR2 /DDR3 memory and I was aware of its use when I implemented a V4 design using the Xilinx MIG tool to support external DDR2 memory but  I never had to deal with the details of the training and delay calculation used to drive the IDELAYE tap values.  This is obviously more complex but it might be possible because the ADS62P49 can be put in a mode where it outputs a fixed pattern.  Perhaps the pattern is suitable as a training pattern?  I am hoping I can avoid this route and stick with the static timing approach.

 

Happy New Year and again thank you for your continued support and guidance,

 

Craig

0 Kudos
cjavid
Adventurer
Adventurer
12,497 Views
Registered: ‎06-30-2013

Hi Avrum:

 

Have you had a chance to review my last post?  I know your response will help me to understand the tools and funcdamental of DDR interface design better.   I think the issue that I have raised about the set-up/hold specs for the BUFIO vs. BUFR could be part of the problem?

 

I know you requested additional timing report info but I wanted to make sure I am generate the TRCE report correctly.  I see some of the fialing hold paths and they indicate that component delays alone exceed the constraint.  That does not make sense to me since the paths are from the IOB through the IDELAYE and intoit he IDDR blocks.  I did not think any additional physical constraints are requied but unclear becasue my ability to read the TRCE report with good understaing is limited.

 

Thanks again for any additional help you can provide.

 

Craig

0 Kudos