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.

DAC38RF83: Link configuration error reported by DAC

Part Number: DAC38RF83
Other Parts Discussed in Thread: DAC38J84

Hi,Jim:

   When debugging DAC38RF83, we find that there are several error report.

   one of them is  Link configuration error which can re-triger a SYNC~.

    Link configuration error =TX and RX parameters do not match

    Can you elabrate which kind of parameters will be match?

    I know that L-M-F-S-K-HD-N must be met. Other parameter such as BID/ DID /Lane ID /CS must be met?

    Since L-M-F-S-K-HD-N have already met between the link partners, there is still such "Link configuration error" and we are confused.

  Thank you.

   

  

  • Hi,

    You may ignore the link configuration parameter in the DAC bring-up by going to the SYNC_REQUEST register and write the link configuration check bit (bit 5) to 0. This will allow the JESD204 RX state machine to ignore the ILAS sequence and continue to finish the link establishment.

    Here is an example ILAS for DAC38j84 with similar JESD204 implementation as the DAC38RF83. The ILAS is programmable in the DAC registers. There are checksum value for the ILAS that also need to be met.

    I typically think ILAS is not critical for link establishment. It is just a protocol to ensure the TX and RX device would match. As you can see, it definitely complicates the bring-up process, therefore, most of our customers just choose to ignore the ILAS check

    DAC3xJ8x ILA Sequence.xlsx

  • Hi:

      Thank you for your professional answer.

       I do believe that ILAS parameter is not critical for link establishment.  I have used many other DAC with JESD204B interface .Almost all of them

       ignore the TX's parameter send during ILAS. But I find that DAC38RF83 indeed check the parameters. Recently, I find that those parameters influence

       my link establishment.  

       I will try it as your suggestion  soon.

     Best Regards

  • I agree with your assessment. 

    -Kang

  • Hi,Kang:

       My TX side repeatly send out K28.7 for lane sync when the L-M-F-S-Hd= 82121

       DAC will re-sync due to receiving K28.7.  Can you advise more?
     Best Regards

      

  • Hi Xiaotao,

    The handshake character should be K28.5 or 0xBCBC characters. The K28.7 character is for frame alignment. This may mean your FPGA is not initialized correctly. Please double confirm if you can reset your FPGA JESD IP to have it send out K28.5 for handshake in CGS mode.

    -Kang

  • Hi,Kang:

      May my description is misleading.  It doesn't means that K28.7 was send always. 

      JESD TX side have finished CGS and ILAS,during the USERDATA phase ,the K28.7.mentioned is the JESD204B.01 STANDARD chapter <<5.3.3.4.2Character replacement without scrambling>>  . 

      

       

      

  • Xiaotao,

    The JESD RX receiver on the DAC is checking for the k28.7 character in the character replacement for proper alignment of frame. A frame boundary is defined to "F", which is 1 in your case. This mean F = 1 octet per frame. 

    The fact that you see SYNC request or SYNC toggle low upon K28.7 character potentially indicates the JESD TX on your FPGA side has "drifting" or "unlocked" frame boundary with respect to the DAC. We have seen cases where customers did not initialize the FPGA IP correctly and such behavior happens. Also, if the FPGA and DAC have unlocked reference clock, such behavior shows up.

    In the SYNC REQUEST register, simply set Frame Alignment Check to 0, and see if the issue can be improved. 

    -Kang

  • Hi,Kang:

       May problems comes from TX side . I have make some changes and taken some optimizations in system.

       When DAC ‘s register 0x51@page 1 = 0x00DF |  0x51@page 1 = 0x00DF

       SYNC~ monitored by TX side in FPGA always keep high . SYNC~ flipping never happens.

      

  • Hi Xiaotao,

    good to know. Yes, please check your FPGA frame alignment and character insertion capabilities in your JEDS204 IP

  • Hi,Kang:

       In my opoinion, The fact that SYNC~ always keep high means the JESD204B link has been established successfully.(DAC ‘s register 0x51@page 1 = 0x00DF |  0x51@page 1 = 0x00DF)

      So I generated a  test tone in FPGA  and send them to DAC. DAC output nothing.

     DAC has some flags  can be readback  to make sure that the link is ok ?

     Best Regards

  • Hi XiaoTao,

    Yes, your understanding is correct.

    However, we have various zeroing blocks that trigger zeroing of the datapath when JESD204 alarm is issued. Until you fix and clear the alarm, the zeroing of the data path is enabled to protect your output circuits like amplifiers. You will need to read back and clear the alarm by writing 0s to the alarm registers to ensure the zeroing are cleared.

    You may also disable the zeroing circuits (zero JESD, zero FIFO, and zero TXENABALE) if you do not need them.

    -Kang

  • Hi,Kang:

      Sorry for a late reply. My configuration has already disabled the  zeroing circuits (zero JESD, zero FIFO, and zero TXENABALE) by Register 0xA@page 1/2 

      with 0xC340. 

      

  • Hi,

    JESD204 standard require the JESD TX to be initialized and ready before the JESD RX (DAC). Please be sure to initialize JESD TX on the FPGA side before you start the DAC. You can also go through the resync procedure outlined in the DAC38RF8x datasheet.

    We have many customers start the DAC before the FPGA, and see no data due to the reverse order. The smarts of the hand-shake lies on the DAC side, therefore, the FPGA must be ready before the DAC.

    -Kang

  • Hi,Kang:

      Yes, I indeed follow the process . 1.configure PLL and let PLL work well first. 2. then  JESD TX  be launched. 3.Lastly DAC is configured after TX is ready.

      Soon,I will try go through ReSync procdure.

      Thanks.

  • XiaoTao,

    Please advise your latest status. I would like to close out the E2E forum per the guidelines. If you have any feedback, you may always reply back to re-open the forum.

    -Kang