Post Go back to editing

AD9154 produces no output after successful JESD link

Category: Hardware
Product Number: AD9154
Software Version: hdl_2019_r2

Hello,

I am currently working on controlling the AD9154 DAC from a Xilinx development board and am running into a problem where, sometimes, the JESD link comes up but the DAC does not output any data.

To make the current design I started with the dac_fmc_ebz ZCU102 example in the hdl_2019_r2 branch. I built this design for mode 10 and then ported it over to a ZCU104. I then used the example no-OS project from the AD9172 and adapted it to run with the AD9154. In the C project I am using the default DDS mode to drive the JESD pipeline.

When I load the no-OS project code into the ARM and it runs, the JESD link comes up every time (verified by checking the link status register 0x280 in the ADI Transmit IP - bits 7:0 return 0x13 which means that SYNC is de-asserted and the link is in DATA phase.) However, about 1/3 of the time, no waveform comes out and the DAC's output stays at 0. The other 2/3 of the time, when the data comes out, it seems to be very reliable and can run for hours without issue.

Are there any specific registers I should look at to get an idea of why this is happening? Is there a clean way to separate the JESD link side (which seems to be working according to the initialization, which succeeds) from the data input and processing side (which could be causing the issue?)

Thank you,

svv9

  • Hello,

    I would check the link in subclass 0 first if presents the same behavior. Then I would try to adjust the LMFCDel, LMFCVar registers from the part.  See the "LINK LATENCY SETUP" section of the datasheet.

    I would also dump the registers of the part w/ and w/o the output working and look for the differences.

    Thank you,

    Laszlo

  • Inagy,

    Thank you for the pointers.

    I did a few runs and checked the cases when the output works and doesn't work. The only thing I noticed is indeed related to the DYN_LINK_LATENCY_x. When the outputs are good, the DYN_LINK_LATENCY_x value is equal to or less than the default LMFCVar of 10. When they are bad, the DYN_LINK_LATENCY_x is more than LMFCVar. Below I list the measured DYN_LINK_LATENCY_x and whether the output is good or not:

    4 (good)
    3 (good)
    6 (good)
    6 (good)
    4 (good)
    6 (good)
    7 (good)
    2 (good)
    2 (good)
    12 (BAD)
    8 (good)
    0 (good)
    9 (good)
    10 (good)
    4 (good)
    1 (good)
    13 (BAD)
    3 (good)
    4 (good)
    15 (BAD)

    These values seem pretty evenly spread out over the entire possible range of PClockPerMF which for my system is 16.

    In the datasheet, the following formula is presented:

    LMFCVar = (FALL_COUNT_Delay + 1) − (MinDelay − 1)

    There is also the note that "Note that if LMFCVar must be more than 10, the AD9154
    cannot tolerate the variable delay in the system."

    It seems that the LMFCVar I would calculate above would exceed 10 so does that mean that I will not be able to achieve reliable system performance in subclass 0 and need to use subclass 1? Or that the system cannot reliably function at all? If the latter is true, what would cause this?

    Also, why would I see successful linking but no output when DYN_LINK_LATENCY_x > 10? or, is that just a coincidence?

    Thank you,

    svv9

  • Is the FPGA side configured for subclass 1? 

    Can you please share the values of the following registers from the Tx Link layer core :

    0x0100     SYSREF_CONF
    0x0108     SYSREF_STATUS 

    Thank you,

    Laszlo

  • Laszlo,

    The FPGA is configured for Subclass 0 mode.

    The values of these registers are: 0x0100 - 1, 0x0108 - 1.

    Thanks,

    svv9

  • If the converter operating in SC 1  then the FPGA as well must be set in subclass 1, other case you will get random link latency.

    Reg 0x0100 should be set to 0 to work in SC 1.

    Thank you,

    Laszlo

  • Inagy,

    I want to operate the converter and the FPGA In subclass 0.

    In the converter I set register 0x301 to 0 for subclass 0.

    In the FPGA I also select subclass 0 in the tx_jesd_init struct.

    Is the error that I describe in this post something that is unavoidable with subclass 0 and the only way to guarantee that it doesn't happen is to move to subclass 1?

    Thanks,

    svv9