CLK104 ADC locked but DAC's not locked

I thought I’d ask here to see if anyone has an idea. I’ve PetaLinux 2.7 and the latest PYNQ library running on a ZCU208 with the CLK104 board. The ADC is locked, but the two DAC’s that are enabled don’t lock. I believe the cables are correct between the CLK104 module and the ZCU208. I have ADC 226 and DAC 230/231 enabled in the Vivado design, with the DAC 230 clock set to “Input RefClk” (the ADC is set to not distribute the clock). I’m using a relatively recent version of xrfclk.py. The application code to check for clock locking looks like this (it’s derived from the QICK project):

def clocks_locked(self):
    """
    Checks whether the DAC and ADC PLLs are locked.
    This can only be run after the bitstream has been downloaded.

    :return: clock status
    :rtype: bool
    """
    print("clocks_locked")
    dac_locked = [self.usp_rf_data_converter_0.dac_tiles[iTile]
                  .PLLLockStatus == 2 for iTile in self.dac_tiles]
    adc_locked = [self.usp_rf_data_converter_0.adc_tiles[iTile]
                  .PLLLockStatus == 2 for iTile in self.adc_tiles]
    return all(dac_locked) and all(adc_locked)

The ADC status returns 2, and the DAC status returns 1. Does anyone have a suggestion on where to look? Thank you.

Hi there,

I don’t have a clk104 in front of me, so not sure how helpful I can be. Have you had a working configuration before, and made some changes, or have the DACs never locked? Have you made any custom tics projects for this?

Also quick thing to check, does the clk104 have a DAC lock LED? I see in the manual page 10, there’s a reference to U7 PLL Lock LED (DAC RF PLL). If it exists and it’s on but the software says it’s off, there might be something off with the code.

Thanks
Shawn

HI Shawn,

Thanks for your response. I spent some time looking at this more. I have had a working configuration; there’s a demo application from Xilinx that uses the ZCU208 with the CLK104 board (ZCU208_4g_play_cap_2021p2_RevA). But, I’m not using the Vivado design that comes with that sample; I’m using a modified Vivado design that was derived from the QICK open source project (that project uses the ZCU216), because QICK supports PYNQ on the ZCU216 (an easier adaptation to the ZCU208; at least I “think” it is). You’re right; there are two LEDs on the CLK104 board that indicate DAC and ADC PLL lock status, and both are lit. I’m now trying to get the Xilinx embeddedsw rfclk program working that I built for PetaLinux (after I fixed the Makefile). I suspect there’s an issue with the SPI MUX not being set, because it’s not in the Vivado design as the rfclk example fails the write/read test. The ZCU208_4g_play_cap_2021p2_RevA design has a axi_gpio_spi_mux IP added to the design so the CLK104 SPI MUX select can be supported. I don’t see that in the original QICK ZCU216 design. One thing, the ZCU208_4g_play_cap_2021p2_RevA demo uses Vivado 2021.2 and I’m using the PYNQ suggested 2020.2 (I assume there’d be other issues if I moved to 2021.2 for PYNQ). I’m not sure if there’s a difference in the IP library, but I don’t see a specific axi_gpio_spi_mux IP in the 2020.2 design. But it’s a mystery as to why the LEDs would be lit if the SPI MUX isn’t accessible, which means the I2C interfaces on the CLK104 boards aren’t able to be reached by the ARM code (I don’t have an answer to this yet, but I’m still looking at it). I’ll keep working at solving this. Thanks, again.

Thanks for the updates.

One quick comment I can give is that, while Vivado 2020.2 is what we use for image builds, you should still be able to use later versions for your individual overlay bitstreams (if you’re loading these designs during runtime e.g. using the Overlay class).

Thanks
Shawn