• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 229 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC37J84: JESD204B protocol cannot be established at sampling rates below 500MSPS

user6000642
Prodigy 20 points
Other Parts Discussed in Thread: DAC37J84

Hi~

When DAC37J84 is used to change the sampling rate，JESD204B protocol can be established at sampling rates 1200MSPS 1000MSPS 600MSPS 500MSPS， but cannot be established at sampling rates below 500MSPS（400MSPS 300MSPS 250MSPS 240MSPS 200MSPS）

The specific performance is as follows: the protocol establishment of CGS, ILAS and User Data Transmission is completed at first, and then the establishment of User Data Transmission fails after waiting for a few seconds. After that, the sync signal sometimes lowers a pulse, sometimes few nanoseconds, resulting in the unstable establishment of the protocol, as shown in the following figure.  

In addition, it was observed that the pulldown of sync signal below 500MSPS was sometimes irregular and sometimes periodic (about 10 LFMC cycles were pulled down and 10 cycles were pulled up, and the time was not completely fixed).  

My DAC configration in 200MSPS sampling rates is below

FPGA：XCKU040-FFVA1156-2-i

L M F S HD: 8 4 1 1 1

DAC input rate: 200MSPS

Lane rate: 2Gbps

Interpolation: 1x

I added configuration below.

8'hFF,16'h0000
8'h00,16'h0018
8'h01,16'h00A3
8'h02,16'h2002
8'h03,16'hA300
8'h04,16'h0000
8'h05,16'hFF03
8'h06,16'hFFFF
8'h07,16'h1E00
8'h08,16'h0000
8'h09,16'h0000
8'h0A,16'h0000
8'h0B,16'h0000
8'h0C,16'h0400
8'h0D,16'h0400
8'h0E,16'h0400
8'h0F,16'h0400
8'h10,16'h0000
8'h11,16'h0000
8'h12,16'h0000
8'h13,16'h0000
8'h14,16'h0000
8'h15,16'h0000
8'h16,16'h0000
8'h17,16'h0000
8'h18,16'h0000
8'h19,16'h0000
8'h1A,16'h0020
8'h1B,16'h0000
8'h1E,16'h9999
8'h1F,16'h9980
8'h20,16'h8008
8'h22,16'h1B1B
8'h23,16'h01FF
8'h24,16'h0020
8'h25,16'h2000
8'h26,16'h0000
8'h2D,16'h0001
8'h2E,16'hFFFF
8'h2F,16'h0004
8'h30,16'h0000
8'h31,16'h1000
8'h32,16'h0000
8'h33,16'h0000
8'h34,16'h0000
8'h3B,16'h0800
8'h3C,16'h0028
8'h3D,16'h0088
8'h3E,16'h0108
8'h3F,16'h0000
8'h46,16'h0120
8'h47,16'h3450
8'h48,16'h31C3
8'h49,16'h0000
8'h4A,16'hFF01
8'h4B,16'h1200
8'h4C,16'h1F07
8'h4D,16'h0300
8'h4E,16'h0F6F
8'h4F,16'h1C61
8'h50,16'h0000
8'h51,16'h00DC
8'h52,16'h00FF
8'h53,16'h0000
8'h54,16'h00FC
8'h55,16'h00FF
8'h56,16'h0000
8'h57,16'h00FF
8'h58,16'h00FF
8'h59,16'h0000
8'h5A,16'h00FF
8'h5B,16'h00FF
8'h5C,16'h6666
8'h5E,16'h0000
8'h5F,16'h0123
8'h60,16'h4567
8'h61,16'h0211
8'h64,16'h0000
8'h65,16'h0000
8'h66,16'h0000
8'h67,16'h0000
8'h68,16'h0000
8'h69,16'h0000
8'h6A,16'h0000
8'h6B,16'h0000
8'h6C,16'h0000
8'h6D,16'h0000
8'h6E,16'h0000
8'h6F,16'h0000
8'h70,16'h0000
8'h71,16'h0000
8'h72,16'h0000
8'h73,16'h0000
8'h74,16'h0000
8'h75,16'h0000
8'h76,16'h0000
8'h77,16'h0000
8'h78,16'h0000
8'h79,16'h0000
8'h7A,16'h0000
8'h7B,16'h0000
8'h7C,16'h0000
8'h7D,16'h0000
8'h4A,16'hFF1E
8'h4A,16'hFF1F
8'h4A,16'hFF01

RBD has been adjusted 8, 16, 24, 28 and 32, but this problem still exists below the sampling rate of 500MSP  

 

After reading the registers 0x64~0x6B, it is found that if the value is above 500MSPS, it is 0000. if the value is below 500MSPS, there are three possibilities as follows: 0002, 0100 and 8100, but the cause of the problem cannot be located  

 

In addition, since FPGD_DCLK and GTH CLK need to switch as the sampling rate changes, the FPGA constraint constrains these two clocks to a sampling rate of 1200MSPS (below), not sure if this will cause a problem (in fact,  We tried to constrain it to 200MSPS with the FPGD_DCLK and GTH CLK clock constraints, both of which are 100MHz, but the protocol for 200MSPS cannot be established.)  

Create_clock-period 3.333-name jesd204_dac_refclk [get_ports refclk0p]  

Create_clock -period 1.667-name GLBLCLKP [get_ports GLBLCLKP]  

 

In addition, the maximum line rate in this design is 12Gbps, but the FR4 material is used. It is uncertain whether it will cause problems (but if it is the material problem, why is the establishment of high frequency protocol normal while the establishment of low frequency protocol failed).  

Thank you for your help  

  • 0
    TI__Guru 66054 points

    Hi,

    Please refer to the attached debug guide.

    Two things that need further attention.

    1. there are FIFO read error. This would mean that the rate on the Serdes transmitter is not stable that cause the SerDes receiver on the DAC to unlock to the data stream. Please check the Serdes transmitter PLL for stability

    2. There are 8b/10b disparity error, but not "not in table" error. This means that the JESD204 IP may need to be reset for the 8b/10b encoding to work properly. We have seen cases like this where the JESD204 IP was not reset properly and caused disparity error, but not not-in-table error.

    General Alarms for All Converters.pptx

  • 0
    TI__Guru 66054 points

    Hi,

    Please refer to the attached debug guide.

    Two things that need further attention.

    1. there are FIFO read error. This would mean that the rate on the Serdes transmitter is not stable that cause the SerDes receiver on the DAC to unlock to the data stream. Please check the Serdes transmitter PLL for stability

    2. There are 8b/10b disparity error, but not "not in table" error. This means that the JESD204 IP may need to be reset for the 8b/10b encoding to work properly. We have seen cases like this where the JESD204 IP was not reset properly and caused disparity error, but not not-in-table error.

    6864.General Alarms for All Converters.pptx

  • 0 in reply to Kang Hsia
    Prodigy 20 points

    Thank you very much for your reply
    According to the suggestions in your reply, I have made the following attempts——
    1.check the Serdes transmitter PLL for stability
    Result: QPLL1 is used in the design. It is found by detecting the "qpll1_lock_out" signal that the signal can be pulled up steadily at all sampling rates

    2. Ignore the SYNC request
    Result: useless

    3.Minimize the length of /K/ pattern by reducing the length variation and delay variation of the JESD204B lanes and also data logic paths.
    Result: Trying to set both the K value and the RBD value to 8, those sampling rates still cannot establish a stable agreement

    4. Set match_specific to 1b’0 to see if the link establishment can proceed.
    Result: No matter the value is set to 1'b0 or 1’b1, JESD204B protocol cannot be established at sampling rates below 500MSPS

    We have tried many methods, but the JESD204B protocol clock cannot be established stably when the sampling rate is below 500MSPS. This problem has troubled us for a long time. Please help.

  • 0 in reply to user6000642
    TI__Guru 66054 points

    Hi,

    Could you please confirm the DAC setting? We will need to duplicate it