07-21-2017 03:18 AM
I have a problem with a DDR interface between an ADC and a Spartan 6 100. I have been reading this post https://forums.xilinx.com/t5/Welcome-Join/ADC-differential-DDR-interface-to-Spartan-6/td-p/277686 but still have some problems.
device -> xc6slx100-3 (fgg484)
ADC -> AD9265
Sampling Frecuency -> 115.2 Mhz
The FPGA clocks the ADC and then uses the DCO form the ADC to get the data
I have 3 ADCs conected to the fpga and follows the schema IBUFGDS_DIFF_OUT -> DCM (with a phase delay) for the clock
and IBUFDS -> IDDR2 for the data.
First question is related with the constraints, I use the following ones (example channel 0)
NET "ADC_0_DCO_P_IN" TNM_NET = "ADC_0_DCO_P_IN";
TIMESPEC TS_ADC_0_DCO_P_IN = PERIOD "ADC_0_DCO_P_IN" 8.68 ns HIGH 50 %;
OFFSET = IN -0.3 ns VALID 2.5 ns BEFORE "ADC_0_DCO_P_IN" RISING;
OFFSET = IN -0.3 ns VALID 2.5 ns BEFORE "ADC_1_DCO_P_IN" RISING;
but I am not sure if they are correct. When using them I get errors in timing.
This is the pinout (again ch 0)
NET "ADC_0_DATA_P_IN" LOC = B21;
NET "ADC_0_DATA_N_IN" LOC = B22;
NET "ADC_0_DATA_P_IN" LOC = C20;
NET "ADC_0_DATA_N_IN" LOC = C22;
NET "ADC_0_DATA_P_IN" LOC = D19;
NET "ADC_0_DATA_N_IN" LOC = D20;
NET "ADC_0_DATA_P_IN" LOC = D21;
NET "ADC_0_DATA_N_IN" LOC = D22;
NET "ADC_0_DATA_P_IN" LOC = E20;
NET "ADC_0_DATA_N_IN" LOC = E22;
NET "ADC_0_DATA_P_IN" LOC = F18;
NET "ADC_0_DATA_N_IN" LOC = F19;
NET "ADC_0_DATA_P_IN" LOC = F21;
NET "ADC_0_DATA_N_IN" LOC = F22;
NET "ADC_0_DATA_P_IN" LOC = A20;
NET "ADC_0_DATA_N_IN" LOC = A21;
NET "ADC_0_DCO_P_IN" LOC = H21;
NET "ADC_0_DCO_N_IN" LOC = H22;
NET "ADC_0_CLK_OUT" LOC = J20;
After the IDDR I register the value with the same clock in the IDDR and introduce the registered value in a dual port memory (clocked by same clock) and read the values with a different clock (same frecuency)
What am I doing incorrectly?
07-21-2017 08:33 AM
So you don't actually tell us what isn't working - is it just failing timing, or is there some other problem?
As for the constraints, its hard to tell. Analog Digital's datasheets are always hard to interpret because they don't clearly show the valid/invalid parts of the data window, so it is hard to interpret tSKEW. There are two ways to interpret it, but I interpret it as follows:
- the data can change as early as 0.9ns before the clock and as late as 0.3ns before the clock
- the tSKEW is shown as being before the clock min=0.3 and max=0.9
(I wish they would clearly show the data valid window... - tSKEW could also be interpreted as the data changes +/-0.9ns around the edge of DCO, which would have pretty radically different timing...)
If so, then the first data window starts 0.3ns before the rising edge of clock and remains there until 0.9ns before the next one, which is 8.68/2-0.9 = 3.44ns, for a total data window of 3.74ns. (I am not 100% convinced of my interpretation of the datasheet numbers... there are far more pessimistic interpretations...)
If so, the constraints would actually be
OFFSET = IN 0.3 ns VALID 3.74 ns BEFORE "ADC_0_DCO_P_IN" RISING;
OFFSET = IN 0.3 ns VALID 3.74 ns BEFORE "ADC_0_DCO_P_IN" FALLING; # You need one for the falling edge too
(you probably need to reduce the 3.74ns to account for duty cycle, but at this size it is more than wide enough for reliable capture)
So tell us what problem you are observing, show us the settings of your DCM (including phase delay) and show us the failing timing report (both setup and hold) for the input paths.
08-21-2017 01:30 AM
Thanks or your reply.
Yor are rigth I copied the rising constraints for ADC0 and ADC1 instead of the rising and falling of ADC0.
On the other hand I interpret that the ADC parameters I must take into account are those for LVDS mode (DCO to data skew -0.3(min)/0.4(typ)/1.2(max) not those for CMOS mode
So following your counts the constraint should be something similar to
OFFSET = IN -0.3 ns VALID 2.84 ns BEFORE "ADC_0_DCO_P_IN" RISING;
OFFSET = IN -0.3 ns VALID 2.84 ns BEFORE "ADC_0_DCO_P_IN" FALLING;
where 2.84 is not considering jitter and uncertainty in the clocks.
*Is this correct?
After doing some implementations, starting with DCM phase shift 0 and reading the timing report I reach a value of 48 for the phase shift where I don't have timing errors in those interfaces, but I still see errors in the captured data. When I say I see errors I mean that the captured signal is not correct and see jumps in the signal, I interpret that the values are not correctly captured. Even, if I configure the ADC in test mode (0x5555/0xAAAA) I get errors.
I have also analyzed the PCB and the delays between data and clock are not relevant (very small differences between data and clk paths).
I prepared this post some days ago, before doing tests in climatic chamber with the devices.
After implementing those tests we have seen that some devices still fail (jumps in the signals that shouldn’t be there) after 1’5h at 45ºC.
Did I correctly interpret the ADC time specs?
If the implementation meets time constraints it should work correctly under all temperature range (we use industrial temp range devices -40/100ºC ) doesn’t it?
Any idea what is wrong configured??
I attach the code