11-21-2019 02:33 AM - edited 11-22-2019 12:37 AM
We have a board with xc6slx100 and 3 AD9265 ADCs.
The clocks for the ADCs are generated by the FPGA at 115 MHz.
The interface is 8 differential pairs in DDR (16 bits) mode and the DCO (p and n). All signals from the same ADC are in the same BUFIO2 clocking region.
We are following xapp1064 with the following configuration:
*serdes_1_to_n_clk_ddr_s8_diff.vhd for the input clock modifying the BUFIO2_2CLK by a BUFIO2 with DIVIDE = 1 in order to get the correct serdesstrobe signal, so:
IBUFDS_DIFF_OUT -> IODELAY (FIXED AT 0) -> BUFIO2 ->rxioclkp, rx_bufio2_x1and rx_serdesstrobe
-> IODELAY (FIXED AT 0) -> BUFIO2 ->rxioclkn
*serdes_1_to_n_data_ddr_s8_diff.vhd for the data configured with S=2 and D= 8. The only modification in the code is the order of the bits in the output to generate the correct 16 bits word.
In the first version, we used IODELAY2 with FIXED delay and IDDR2 components but had problems to get the correct data/clock alignment, so we have changed to ISERDES2 thinking that the recalibration feature could help us. So we are using the ISERDES2 to deserialize a DDR signal and it works but, is it the correct solution? is there a better one?
On the other hand, when we test the system at "high" temperature (45º) we have errors in the input signal (we use the PN23 pseudo-random signal from the ADC to check the incoming data and receive incorrect values). Apparently, the Calibration and Phase Detection State Machine is working but not sure if correctly due to the errors in the data.
Finally, I have one more doubt regarding the constraints for the design. As we are using the IODELAY2 for the data in DIFF_PHASE_DETECTOR mode, are constraints "OFFSET IN VALID BEFORE" necessary? or as the ISERDES2 will modify dynamically the path delays those constraints are not necessary?
If they are necessary and taking into account the ADC datasheet with tskew between -0,3 and 1,2ns which should be the constraints?
Comments are very appreciated.
Thanks in advance.
11-22-2019 02:25 PM
You don't need a timing constraint in this case since the interface is dynamic.
The fact that the idelay calibrates regularly then the interface should be robust over temperature. Do you do the initialization at low temperature and then raise the temperature in the case where you get the failure.
The fact that you change the bit slip pattern could be something to look at. Did you check that out in simulation?
11-25-2019 01:39 AM
First of all thanks for your answer!
regarding your question...
Do you do the initialization at low temperature and then raise the temperature in the case where you get the failure.
Does it really matter? Normally I use a device in a hoven at that temperature and reinitialize the device when having something to test (after testing the version in a device at ambient temperature). But I suppose that if the code works for a device with temp variations it should also work for a device that is powered on at 45º (or more). Is this assumption correct or there are differences between the 2 scenarios?
11-25-2019 02:11 AM
It should be robust across all temperatures.
I am just trying to understand.
What about the question I asked with the bit slipping.
Have you tried in simulation?