This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS5294: Reading PHASE_DDR Register

Part Number: ADS5294

Hi team,

ADS5263 Reading PHASE_DDR Register

One of our customers is experiencing the following issue, which is similar to the issue in the link above, but no resolution is given above.


This customer using the ADS5294 occasionally get a clock 8 channel full data error in test patterns mode. An attempt was made to modify ADDR 0x42H [D6:D5], but it was read out as 10, indicating a write failure. What are the prerequisites for reading and writing this register?

Best Regards,

Amy Luo

  • Hi Amy, 

    Sure, we will look into this. Does the customer see the exact same signature as mentioned in ADS5263 Reading PHASE_DDR Register? That is - a) it is observed in all ADS5294 devices b) You are able to write-to and read-from all other register bits (including 0x42 except [D6:D5])? 

    Thanks,

    Karthik 

  • Hi Karthik,

    The customer can now read and write the 0x42 register. He can modify the D6:D5 bit after changing the 0x42 register D15 bit to 1. Don't know why there is such a restriction.

    However, the customer is still not able to output properly in test patterns mode. What I want to confirm to you is that in test patterns mode the device can only output 14bits and modifying the EN_bit_SER register does not work? 

    Best Regards,

    Amy

  • Hi Amy, 

    Okay. Thanks for the update. We are currently checking this on bench and might need to discuss with the design team as well. Give us a few days time and we will get back to you by July 18 (Monday). 

    Thanks,

    Karthik 

  • Hi Karthik,

    I would like to describe the customer's original issue as follows 

    The customer has output data exception when using test pattern mode. The last two bits of a byte are lost in the output, as shown in the figure below, when the theoretical value is 36, the last two bits " 10 " are lost, and the subsequent data is added. The result is 35 (which should be 36 theoretically), while the subsequent data is read out abnormally due to the advance of two digits. After a certain period of time (the length of time is not fixed), for example in this case until the theoretical value is 38, add the last two digits " 00 ". The next data was OK again, that is, it was correct at 39.

    When an exception occurs, 8 channels occur simultaneously and resume simultaneously.

    Changed 14-bit output to 12-bit output, problem persists. However, changing the 14bit output to 16-bit output (modifying ADDR 46 [11:8]) does not have this problem.

    What could be the problem? How to guide the customer to troubleshoot the issue 

    Best Regards,

    Amy

  • Hi Amy,

    Karthik has transferred this E2E to me due to non availability of the EVM at his end. Hence, I am looking in to this issue.

    Unfortunately, last week my EVM stopped working and I got a fresh one. I have set it up in India lab and will continue with the experiment. 

    I am also consulting with my team on this one. You should receive an update by tomorrow.

    Thanks & regards,

    Abhishek

  • Hi Amy,

    I brought up the EVM and so far I am not seeing the issue of incorrect data in test pattern mode.

    To me, it looks like a timing issue. It could happen at high speeds if there is any routing mismatch. It could be at the FPGA side or the device side.

    Can you please provide the following information:

    1. At what frequency are the customer operating? - If it is timing violation, we can confirm it by running the device at lower speed and see if the issue occurs.

    Can you ask the customer to check the same at various lower speeds. My be at half the speed.

    2. Are they using TI EVM + TSW1400 solution or they have their own board?

    Regarding the read/write of the PHASE_DDR register, it looks quite possible that some of the bits are device trim bits which are internally used. So to read it correctly usually trim bypass is needed. Hence you may need to set bit[15]. I still will have to confirm with the designer about this register. I will confirm the same and let you know.

    Thanks & regards,

    Abhishek 

  • Hi Abhishek,

    This customer's feedback is as follows 

    1. clock input is 75MHz, also tried 40MHz, both have problems. The actual test clock jitter is 12PPM. Cutting the 75MHZ into half the internal PLL is also problematic.

    2. using our own circuit board, did not validate TI EVM + TSW1400 solution.

  • Hi Amy,

    Understood. 

    Most likely it is data serialization logic timing violation in the customer system. We need to understand their data capture architecture and see where and why this is happening.

    I will talk with Shabbir on this and get back to you with some suggestions.

    Regards,

    Abhishek

  • Hi Abhishek,

    Thanks, Please let me know if you need any further information.

  • Hi Amy,

    I have already shared the concern with my team members. I am waiting for their response. 

    I will loop you in on the thread, once I hear back.

    Thanks & regards,

    Abhishek

  • Sorry for pushed, any update on here?

  • Hi Amy,

    Abhishek is currently out of office due to personal emergency and he should return next week and will provide an update. Thanks for your patience and understanding.

  • Hi Amy,

    Thanks for your patience. 

    I have tested ADS5294 EVM yesterday in various test modes and I am not seeing any issues in test pattern mode even at higher sampling speed of 80 Msps.

    The test patterns in my case were consistent.

    Next thing that I would suggest the customer to look at is to provide custom test pattern on constant dc value say 36 and read it to see if there is any issue coming. Then check at dc value 37 and see if the issue comes up.

    Since it is happening on all the channels, most likely the issue is with FCLK or DCLK alignment. If it is indeed the case, then the same signature should come with constant pattern as well. It would give us a clue about the timing violations are happening on the FPGA side or not.

    Thanks & regards,

    Abhishek