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.

DAC38J84: The SYNC cannot be asserted.

Intellectual 465 points

Replies: 33

Views: 4213

Part Number: DAC38J84

Hi

I use Xilinx FPGA and the DAC38J84 to establish the JESD204B developing environment . Now I have some trouble about the SYNC signal. My SYNC can not be toggle. It always stays low. I know CGS is not passed. 

The FPGA always transmit the /K28.5/ and I can see the waveform on the oscilloscope . I don't know what's the matter. Does this error come from he registers configuration or the PCB designe? How do I deal with it?

33 Replies

  • Guru 54040 points

    In reply to Zhipeng lv:

    Zhipeng,

    Does your Xilinx JESD204 IP core require a core and reference clock or just a reference clock? We use two with our design. Are you disabling the scrambler on both sides of the link? Please write and read to the registers in the attached file and send this back so we can see what errors you are getting.

    Regards,

    Jim

    clear_read_alarms_registers.csv

     

  • In reply to jim s:

    Jim

    My Xilinx JESD204B IP core require both core clock and reference clock. And core clock == reference clock = 150MHz. lane rate = 6Gbps. I disabled the scrambler on both sides.The attached file is about the alarm registers. I write 0x0000 to these registers

    to clear them firstly. When I read them config 100~107 are 0x070b. config 108 == 0x0003, config 109 == 0x00FF.

    The SYNC always be high. why do  bit 15~8 of config100 to config107  still have error notification?  It confused me.

    Regards

    Zhipeng

  • Guru 54040 points

    In reply to Zhipeng lv:

    Zhipeng,

    After looking at your error codes, it appears you are never passing CSG. I am not sure why SYNC is high. You need to Chipscope running and verify the K28.5 comma data is coming out of all lanes of the FPGA properly. Have you followed these steps:

    1. Set TXENABLE low

    2. Supply all 0.9-V supplies (VDDDIG, VDDT, VDDDAC, VDDCLK), all 1.8-V supplies (VDDR, VDDS, VQPS,

    VDDIO, VDDAPLL, VDDAREF), and all 3.3-V supplies (VDDADAC). The supplies can be powered up

    simultaneously or in any order. There are no specific requirements on the ramp rate for the supplies.

    3. RESET the JTAG port by either toggling TRSTB low if using the JTAG port or holding TRSTB low if not using

    JTAG.

    4. Start the DACCLK generation

    5. Toggle RESETB low to reset the SIF registers

    6. Program the DAC PLL settings (config26, config49, config50, config51). If the PLL is not used, set pll_sleep

    and pll_reset to “1” and pll_ena to “0”.

    7. Program the SERDES settings (config61, config62) including the serdes_clk_sel and serdes_refclk_div.

    8. Program the SERDES lane settings (config63, config71, config73, config74, config96).

    9. Program clkjesd_div, cdrvser_sysref_mode, and interp.

    10. Program the JESD settings (config3, config74-77, config79, config80-85, config92, config97).

    11. Program the DIG block settings (NCO, PA protection, QMC, fractional delay, etc.) and set the preferred

    SYNC modes for the digital blocks (config30-32).

    12. Verify the SERDES PLL lock status by checking the SERDES PLL alarms: alarm_rw0_pll (alarm for lanes 0

    through 3) and alarm_rw1_pll (alarm for lanes 4 through 7).

    13. Set init_state to “0000” and jesd_reset_n to “1” to start the JESD204B link initialization.

    14. Start the SYSREF generation.

    15. Enable transmission of data by asserting the TXENABLE pin or setting sif_txenable to “1”.

    16. Clear the alarms, then wait approximately 1-2μs and check values

    17. Verify that DAC output is the desired output.

    Regards,

    Jim

  • In reply to jim s:

    Jim

    I can see the K28.5 comma data on the oscilloscope as the following picture.

    1.In the previous post, I didn't start the DAC as the sequency you said. After reading your reply I tried the setup order as what you said. Until I operate to the step 15 I read config 100 to 107 as 0x0001. Then I clear the config100 to 107 as 0x0000. After that I read config 100 to 107 again . They are all 0x0000. config 108 == 0x0003, config 109 == 0x0000. The SYNC is always asserted. Whether it means that there are no errors. 

    2.I found an interesting things. I write the other number to config 100 to 107 and then I read back.  I found what I read back are what I wrote to config100 to 107. If I set a link configuration error on purpose when I program the DAC39J84. I read the config100 to 107. They are all 0x2001. Then I clear them and read back. I found they are also 0x2001.  Does it mean that if there are no errors  config100 to 107 can be write as what user's want.  If there are errors the error bits are asserted and the clear operation can not clear them until the correct status present.

    3. When the TX transfer K28.5 I found the SYNC can also be asserted without SYSREF. Is it normal? 

  • Guru 54040 points

    In reply to Zhipeng lv:

    Zhipeng,

    When you read back 0x2001, this is an error state which is what is expected if you programmed the link to have an error. Sync can go high without SYSREF. This is how subclass 0 and subclass 2 work. Neither mode uses SYSREF.

    Now that you have established SYNC, what is the status of your output?

    Regards,

    Jim

  • In reply to jim s:

    Jim

    1. So if I don't programmed the link to have an error . Until I operate to the step 15 I read config 100 to 107 as 0x0001. Then I clear the config100 to 107 as 0x0000. After that I read config 100 to 107 again . They are all 0x0000. So witch one is the expect status of config 100 ~107? Is there really no errors?

    2. I transmit a square waveform. There is a constant voltage 1.78V at the OUTPUTPa and 1.62V at the OUTPUTN. The OUTPUT is cascaded with a capacitor and 50ohm resister to ground.

    3. DAC39J84 only supports subclass1 mode. Why does the SYNC can be asserted without SYSREF.

    Regards

    Zhipeng
  • In reply to jim s:

    Jim

    I read the file that you provide to me. I saw the trace length of Device clock and the SYSREF  are matched as the following picture shows. Whether  the trace length of Device clock and SYSREF to the same device must be same?  If the length of Device clock and SYSREF are different whether the DAC39j84' work status will be influenced. The difference of the trace length between Device and SYSREF on my board is within 40mils. 

    Regards

    Zhipeng

  • In reply to Zhipeng lv:

    Hi, zhipeng,最近我也在使用这颗芯片,目前进展和你差不多,也是卡在这里了。能否留个联系方式交流。

  • Guru 54040 points

    In reply to user1262354:

    Zhipeng,

    This message is in Chinese. Do you have a question?

    Regards,

    Jim

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.