Post Go back to editing
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion


Hi Team-ADI,

We are trying to interface ADRV9008-1W/PCBZ and ADRV9008-2W/PCBZ on HPC0 and HPC1 connector of ZCU102.

We have brought out two spi's from processor and generated bitstream succesfully.

We need your help with reference to configuration of ADC,DAC using SDK.As per our knowledge,such project is not available.

But atleast if you can guide with respect to what modifications can be done in reference project of ADRV9008-1/2 to make it work.

FYI: We have succesfully interfaced ADRV9008-2W/PCBZ on ZCU102.

@Adrian C "request and appreciate your response on this"



More information
[edited by: Sid@123 at 3:41 PM (GMT -4) on 24 Mar 2021]
[locked by: buha at 8:13 AM (GMT -5) on 22 Nov 2021]
  • Hello,

    Are you using Linux or No-OS ? 

    In my opinion, the two boards can be brought up sequentially, as if they are the only ones on the ZCU102, so the code you've used for a single ADRV9008-2 should work on this project, with the SPI/GPIOs adjusted to reflect the new design. I suppose, you'll need also GPIOs, not only SPI to each board. If the two boards need common clocking, or have other synchronization requirements, things may be more complex.



  • Waiting for your reply...

  • Hi Siddharth,

    Regarding the SPI question:

    devices/adi_hal/parameters.h contains these chip select definitions:

    #define CLK_CS 0
    #define ADRV_CS 1
    If HPC0/HPC1 wiring and HDL allows it, you may simply use SPI0 with 3 chip selects => rename with something like:

    #define CLK_CS 0
    #define ADRV_RX_CS 1 // <--- for adrv9008-1
    #define ADRV_TX_CS 2 // <--- for adrv9008-2
    You could modify adi_hal structure to have 2 chip select members spi_adrv_rx_csn and 
    spi_adrv_tx_csn and make sure they get passed correctly from headless.c to their usage in no_os_hal.c in function ADIHAL_openHw() which initializes the SPI.
    If using 3 Chip Selects on SPI0 is not an option you will need an extra SPI descriptor (for SPI1) to handle, just follow along the SPI0 descriptor and immitate.
  • Hello Buha,

    Thanks for the detailed reply.

    Using 3 Chip Selects on SPI0 is not possible even if its possible in HDL, as there are only 2 CS lines brought out from SoC to each HPC connector in hardware.(Please confirm if i am correct).

    We will try to use 2 SPI for ADRV9008-1 and ADRV9008-2 on ZCU102.

    But in between we tried to interface only ADRV9008-1_WPCBZ on ZCU102 but its popping up

    error: RFPLL not locked.

    Following Changes were made in no-os project files of ADRV9009 for ADRV9008-1 as per the sequence of configuration mentioned in headless.c generated from ADRV9009(ADRV9008-1) TES GUI :

    In talise_setup function:


    uint32_t trackingCalMask = TAL_TRACK_NONE;

    talAction = TALISE_setRxTxEnable(pd, TAL_RX1RX2_EN, TAL_TXOFF);

    I have commented the TX and ORX portions in headless.c. I have attached app_talise.c,headless.c and talise_conif.c files


    Please help us out on this.

    FYI :While interfacing ADRV9008-2 with ZCU102,we used the same code(hdl_2019_r2(Vivado 2019.1)+No-Os software) as it is,,which is there for ADRV9009 and it(ADRV9008-2) is configured successfully.

     Also we have interfaced ADRV9009_WPCBZ successfully.



  • Hi Buha

    We are waiting for your response



  • Hi Siddharth,

    Sorry for delay,

    The no-OS project under 'projects/adrv9009', as you can see only supports adrv9009 based hardware.

    In theory, what you are trying to do should work by only initializing RX-related stuff (for adrv9008-1). I saw that you are disabling TX-related stuff, that is reasonable. You also change initCalMask (probably because that's what TES software output was) and I checked that the linux driver, known to work, actually uses the same initCalMask you use for adrv9008-1 so that's good:

    I don't see anything obviously wrong. What I would do is draw inspiration from the linux implementation at the above link and try to match it. 

    This would be the device tree configuration for zcu102 + adrv9008-1:


  • Hi ,

    I have some good news, someone from the team has created a pull request to add support for adrv9008-1 and adrv9008-2:

    Please try the code by simply checking out branch dev/adrv9008 and building as usual, making sure to enable the flags in projects/adrv9009/src/app/app_config.h 

    Best regards

  • Thanks Buha for the help.

    Actually we were able to configure ADRV9008-1 on ZCU102.Main problem what we observed is

    Error"RF PLL Not Locked" is there for some specific profiles generated by TES.

    When i changed with other profiles from TES on trial and error basis,it worked for us.

    Now what we will do is try using this code and i will run the profile for which error was thrown earlier.



  • Hi Adrian,

    Now we want to configure "as discussed earlier in this thread" ADRV9008-1 on HPC0 and ADRV9008-2 on HPC1 at a time. As advised by you, we used SPI0 for HPC0 and SPI1 for HPC1.Similarly for gpio lines we mapped to both HPC's. Also pin planning is being done for both HPC corresponding lines towards FPGA. Now regarding JESD lines,since MGT banks corresponding to HPC0 and HPC1 are not adjoined,we need to replicate GTHE4 XCVR block in block design of reference HDL design.Please guide us in, how to add another GTHE4 XCVR block for the other HPC and what all changes needs to be done so that our HDL design for both HPC is ready.



  • Hello Siddharth,

    Ultimately you'll need two util_adxcvr blocks, one for each HPC, which will either connect one RX (2 RX lanes) or one TX and one ORx( 4 TX lanes and 2 RX lanes) and reconnect the data link layers to the coresponding util_adxcvr. 

    As an intermediary step you could copy the whole data path for JESD204 so you'll have support for two ADRV9009s, with the correct pinout and reference clocks (for one path pinout for HPC0 and for the other HPC1) and afterwards remove the pieces that are not needed.

    Do you have a github repository with your HDL changes ? I could take a look and give specific pointers.



  • Hello Adrian,

    I replicated only util_adxcvr part as my requirement is ADRV9008-1 on 1 hpc and ADRV9008-2 on other hpc. Also i cloned spi and gpio connections as advised by you. In implemented design, tx and rx jesd data lines are placed in respective banks corresponding to hpc0 and hpc1.

    Before validating whole setup on hardware, with this bitstream what i hv generated now,is it ok to connect only adrv9008-2 on hp1 and check whether its working fine and then similarly for only adrv9008-1 on hp0 and then go for combined setup with changes in no-os code that caters both adrv9008.



  • Hello,

    Yes, validating independently should be good steps in validating the whole design.



Reply Children
  • Hello Adrian,

     I validated independently ADRV9008-2 on hp1 and ADRV9008-1 on hp0 using bitstream(combined logic hp0 and hp1) and in both the cases device is in data mode which means its all fine.

    But 1 observations:

    I routed spi0 to hp0 in hdl design and in no-os platform, device_id is set to 0 and gpios for adrv9009_resetb and ad9528_resetb has been set with an offset of 78. Next when I checked ADRV9008-2 on hp1,i only changed device id to 1 as spi1 is mapped in hdl but didn't change the gpios value for ADRV9008-2 and AD9528 resets in parameters.h, then it should not have been configured. But its configured successfully with data mode. Also when I gave the required gpio values its working in data mode.



  • Hello Adrian!!

    Waiting for your reply...

    If this part what I asked is clear,then I can focus on configuring both hp0 and hp1 sequentially in baremetal.

    Thanks n regards 


  • Hello Siddharth,

    Do you have a branch with the full design or a block diagram ?

    I wasn't sure if it was a question or just an observation, but indeed it seems strange, but I cannot say why it happen from the description above.



  • Regarding the software changes you did, maybe somebody from the software group may add additional comments, but I suppose they would also need additional clarifications with the exact changes.

  • Hello Adrian!!!

    Thanks so much for all the guidance regarding HDL. Also i would like to thank buha for helping in getting no-os project with code segregation between ADRV9008-1 and ADRV9008-2. This was really helpful while doing no-os for both ADC and DAC together.

    Now i am able to configure both ADRV9008-1+AD9528 on HPC0 and ADRV9008-2+AD9528 on HPC1 simultaneously.

    It took much time as i was not continuously working on it.

    Also with respect to last question what i asked,i think i got the clarity now. My doubt was, without proper gpio assignment for reset signal in HPC0,still ADC was getting configured. Actually it can be configured what i observed,only problem will be when we want to re run the system debugger for configuration,ADC wont configure.It will fail in Talise_initialize. We have to repower the board in this case. Once i did the proper assignment of gpio,this was solved.

    I have to do a RF-loop back test and will ask for your support if required.

    Thanks & Regards


  • Hi Siddharth,

    Thanks for letting us know that it works. I will lock this thread now for commenting since too long threads may be hard to read by people looking for solutions on EngineerZone.

    As always, feel free to open new threads if you think you need help from ADI engineers.

    Slight smile