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.

ADS58J63: JESD bit packing order changes for some lanes

Part Number: ADS58J63
Other Parts Discussed in Thread: ADS54J60

Hi

I am seeing that the JESD data for some lanes in ADC is received in reverse order by FPGA.

i.e. For some lanes the data is B15 - B0 and for some lanes it comes as B7-B0;B15-B8.

And this changes when I do a JESD reset.

i.e. the lane on which I am receiving bit in order B15-B0 can change to B7-B0;B15-B8 and vice versa.

The attached FPGA capture shows the bit packing order.ADS58J63-MSB1.cfg

In both cases JESD link is stable.

Please let me know why this behaviour can happen.

I have attached my ADC configuration for your reference. Below are main setting of the ADC.

ADC mode: Mode 0

LMFS: 4841

Sampling rate: 500MHz

DDC: Yes, Fs/4

Let me know if you need any further information.

  • I apologize. But mistake I added same snapshot twice for FPGA data capture. 

    Proper order:

    Improper order:

    You can make out the LSB as the bit which is always '0'.

    Regards,

    Kiran

  • Hi Kiran,

    When you mentioned JESD reset, which JESD IP are you resetting? Is it the FPGA JESD RX IP?

    The JESD204 requirement states that the JESD204 TX (ADC) need to be up and running before the JESD204RX IP (FPGA). If you have them in reverse order, the JESD204 RX may not be receiving data properly. This is due to the JESD204 RX has all the smart for the hand-shake, and therefore need to be initialized at a later time.

    I do not believe there are JESD reset on the ADS58J63 on the JESD204 IP itself. There are digital core reset available. 

    If you want to eliminate JESD204 IP on the ADC side, you may use test pattern feature on the 0x0F register of the ADC page, and send out a ramp pattern to double check the validity from the data at the DDC side (before JESD204 TX IP)

  • Hi Kang,

    By JESD reset, I meant FPGA JESD RX IP reset.

    My sequence of operation is a below.

    1. FPGA board is configured. But FPGA JESD RX IP is held at reset.

    2. ADC board is configured.

    3. I can see FPGA receiving "bcbc" characters on JESD lanes. But FPGA JESD RX IP is still in reset.

    4. I then bring the FPGA JESD RX IP out of reset.

    5. I see that JESD links are established and FPGA starts receiving data from ADC.

    Since I am keeping FPGA JESD RX IP in reset until ADCs are configured and then establishing the links, I believe the order of configuring the devices is fine. Please let me know if I need to change the order.

    Regards,

    Kiran

  • Hi Kiran,

    Yes, this is a correct order.

    -Kang

  • Kiran,

    If your FPGA need some sort of SerDes level training before JESD204 link establishment, you may consider the following PRBS based test pattern with scrambling enabled.

    You may initially issue a logical SYNCout from the FPGA from logic HI -> LOW -> HI to create a "dummy" link establishment signal so the ADC can send out the necessary PRBS pattern for your SerDes receiver training. Then you can reset the JESD204B IP core on the FPGA side to issue can actual link establishment setup, and disable the PRBS pattern to start the actual ADC data traffic.

  • Hi Kang Hsia,

    Thanks for the update. I'll try to do this and check.

    In the meantime can you review the configuration and let me know if there are any issues in ADC configuration. I have attached the same here for your reference.

    Basic configuration settings are as below:

    JESD Mode: Mode 0

    LMFS: 4841

    K: 32

    Nyquist zone 2

    0576.ADS58J63-MSB1.cfg

    Regards,

    Kiran

  • Kiran,

    Please try the attached configuration file. These are the only register writes required to get the TI EVM running using your settings. Make sure to give the part a hard reset after clocks are applied and before writing these register values.

    Regards,

    Jim

    ADS58J63-TI.cfg

  • Hi Jim,

    I tried with the configuration you provided in EVM as well as my custom board. I am still seeing the same issue where in some lanes bytes are getting swapped and in some lanes the bytes are coming in proper order as described in my first post. 

    When testing with EVM, if I do JESD reset on FPGA few times, the byte ordering becomes proper. But in my custom board I have 20+ ADCs and this method is not feasible. Hence any inputs from you about what may be going wrong will be very helpful.

    Regards,

    Kiran

  • Kiran,

    Make sure to issue a hard reset to the ADC after power and clocks are applied but before configuring the ADC registers.

    This part requires a certain power up sequence. The IOVDD must come up before DVDD. Please see section 10.1 of the ADS54J60 data sheet. This information will be on the next release of the ADS58J63 data sheet.

    When you have the byte swap issues, read back the ADC registers and make sure they have the correct value.

    You mention 20+ ADC's. Is the issue on all of them or just certain ones? Is the SPI daisy chained to all parts? Is there a chance the SPI data is corrupted?

    Is SYREF always running?

    On an ADC that has the bytes swap; set it to ramp mode and see if the data is still swapped without doing a JESD reset.

    Regards,

    Jim

  • Hi Jim,

    Below are my responses.

    1. While testing in EVM, I had pressed the reset button before configuring ADC as specified in the EVM user guide. But I still see the issue while testing with EVM.

    2. In my custom board, I don't have provision for hard reset. I have kept the pin (pin 48) as "Not Connected". I am doing soft reset through SPI for all devices before I configure them. Will this have an affect? What can be done in this case as hard reset provision is not made?

    3. As of now I'm not following any powerup sequence as I didn't come across such requirement in the datasheet. But I'll see how I can do the sequence and update you.

    4. I read back the register values and all returned values are according to the configuration.

    5. I'm facing issue in all 20+ devices. I don't believe it is SPI configuration issue as the read back values matches with the configuration file.

    6. SYSREF is given in pulsed form. But I have tried with continuous mode also in EVM and the result is the same.

    7. I'll try some test patterns and get back to you how it responds without doing a JESD reset. But I don't have a choice of not issuing JESD reset as it is required to bring the FPGA JESD-RX out of reset.

  • Kiran,

    The part performance is not guaranteed if you do not do the power sequence and hard reset. Sorry, but you need to add these.

    Regards,

    Jim

  • Hi Jim,

    Thanks for the surprising disclosure regarding powerup sequencing requirement for ADS58J63. 

    Section 9 of ADS58J63 datasheet says that there is no specific powerup sequence required for the device. We had taken that into consideration and designed our boards accordingly. Also there is no mention of issuing hardware reset for proper functioning of device. Hence we had used the SPI based soft reset.

    Also as mentioned before I have also tried with ADS58J63 EVM. I am assuming power up sequencing is taken care in the EVM as I don't have any control over that. The sequence of operation I'm following in EVM is:

    1. Configure clock.

    2. Press hardware reset button

    3. Configure ADC

    But even in EVM byte swapping is observed. I'm not getting what may cause this issue. Your further inputs are much appreciated.

  • Kiran,

    I do not see this issue with the TI EVM when using our capture card which is using aa Altera device. What FPGA are you using? If it is a Xilinx device have you try consulting with them regarding this? Are you using separate clocks for the core and reference clock? How does the test pattern look when the normal mode has the bytes swapped?

    When you see the byte swap, does it occur on all 4 ADC of the device? If not, could you swap the outputs using the output mux register (page 0x6900, address 0x21) and see if the issue follows the ADC or the lanes used.

    Regards,

    Jim 

  • Hi Jim,

    Thanks for your support. We found that it was issue on FPGA side. It got resolved now.

    Thanks,

    Kiran