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

ADRV9008-1 + ADRV9008-2 + ZCU102 REFERENCE DESIGN HELP

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"

Regards

Siddharth



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]
Parents
  • 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.

    Regards,

    Adrian

  • Waiting for your reply...

  • Hello Siddharth,

    Assuming you have ADRV9008-1 on HPC0 and ADRV9008-2 on HPC1, starting with the default reference design you should have all things needed for ADRV9008-2 (SPI and GPIO).

    When adding ADRV9008-1, you need to clone the same SPI and GPIO connections (you'll need a connection to AD9528 and another to ADRV9008-1). Of course, the same goes for the JESD204 path.

    After the HDL is create, the addition of ADRV9008-1 should not interfere with ADRV9008-2, meaning the same software should work to bring the device up. Is this the case ?

    Regards,

    Adrian

  • Hi Adrian

    Thanks for the response.

    I would like to clarify the exact details what we want to do.

    Our custom board is almost similar to ADRV9009-ZU11EG hardware design.

    We have  ADRV9008-1(1)+ADRV9008-2(1)+AD9528(In place of HMC7044)+Xilinx MPSoC all in same board.

    Now we are trying to replicate the above scenario using ZCU102+ADRV9008-1(HPC0)+ADRV9008-2(HPC1).

    In order to replicate this hardware wise,we will use only one of AD9528(lets say HPC0) and drive the  dev clock and sysref of AD on HPC1 using cables.

    "When adding ADRV9008-1, you need to clone the same SPI and GPIO connections (you'll need a connection to AD9528 and another to ADRV9008-1). Of course, the same goes for the JESD204 path."

    Do you mean 2 AD9528 on ADRV9008-1 and ADRV9008-2 or only 1 AD9528 (either from ADRV9008-2 or ADRV9008-1)? 1 AD9528 will be like common clock source for SoC,ADRV9008-1 and ADRV9008-2.

    If its 2 AD9528,then SPI_MISO corresponding to 2 AD9528 will be difficult to make since we have only 3 CS.

    "After the HDL is create, the addition of ADRV9008-1 should not interfere with ADRV9008-2, meaning the same software should work to bring the device up. Is this the case ?"

     Yes exactly same software should work to bring the device up.

    Regards

    Siddharth

  • Hello Siddharth, 

    The problem is that the HPC0 and HPC1 are connected to different transceiver banks, which are not adjoined, so they need their own reference clock. On our ADRV9009-ZU11EG, this is not a problem, as they are connected to adjoined banks.

    Regarding SPI, i was thinking to use SPI0 to connect to HPC0 evaluation board ICs and SPI 1 to connect to HPC1 evaluation board ICs(or vice versa), so you should have 3 CS per SPI, but given that you have 6 CS, should be enough.

    I know there were customers that synchronized two ADRV9009 evaluation boards on ZCU102 by synchronizing the AD9528, but I don't know exactly the details on how to do that. This would bring the evaluation system closer to your final design.

    Regards,

    Adrian

  • Hello Adrian,

    Thanks for the prompt response.

    "The problem is that the HPC0 and HPC1 are connected to different transceiver banks, which are not adjoined, so they need their own reference clock. On our ADRV9009-ZU11EG, this is not a problem, as they are connected to adjoined banks."

     So for our custom board,since ADC and DAC are connected to adjacent banks,we should be able to use ADRV9009-ZU11EG HDL reference design but in software we need to take into account of AD9528 in place of HMC7044 and ADRV9008-2 and ADRV9008-1 in place of 2 ADRV9009. We will be needing your help in configuring the same in no-os in near future.

    "Regarding SPI, i was thinking to use SPI0 to connect to HPC0 evaluation board ICs and SPI 1 to connect to HPC1 evaluation board ICs(or vice versa), so you should have 3 CS per SPI, but given that you have 6 CS, should be enough."

    As of now we would like to configure the way you have described using 2 SPIs.Please guide us what changes needs to be done in no-os software that is available for ADRV9009 so that we can configure ADRV9008-1+ADRV9008-2.

     FYI: Once again mentioning that I tried to independently interface ADRV9008-1 with ZCU102 by using the same code  which is there for ADRV9009 with few changes like we made TX_Enable as OFF and RX_Enable to be ON,we disabled the DAC initilazation part from Transport to PHY layer including clock  also, but its popping the following error: ERROR:247:TALISE_waitArmCmdStatus() failed due to thrown ARM error.ARM time out error:TALISE_waitInitCals() failed.

     

    Regards

    Siddharth

  • So for our custom board,since ADC and DAC are connected to adjacent banks,we should be able to use ADRV9009-ZU11EG HDL reference design but in software we need to take into account of AD9528 in place of HMC7044 and ADRV9008-2 and ADRV9008-1 in place of 2 ADRV9009. We will be needing your help in configuring the same in no-os in near future.

    That's correct. You could also probably squeeze both ADRVs in a single transceiver bank, if the application suits that.

    Regarding the no-os configuration, I will move the question to the appropriate forum and somebody from that group can give you specific instructions.

    Regards,

    Adrian

  • Moved to No-OS forum

  • 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.
    Regards
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.
    Regards
Children
  • 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 initCalMask = TAL_ADC_TUNER | TAL_TIA_3DB_CORNER | TAL_DC_OFFSET | TAL_RX_GAIN_DELAY | TAL_FLASH_CAL | TAL_RX_QEC_INIT;

    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

    .forum_adrv9008-1.rar

    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.

    Regards

    Siddharth

  • Hi Buha

    We are waiting for your response

    Regards

    Siddharth

  • 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:

    https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/adrv9009.c

    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:

    https://github.com/analogdevicesinc/linux/blob/master/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev10-adrv9008-1.dts

    Regards

  • Hi ,

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

    https://github.com/analogdevicesinc/no-OS/pull/1018

    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.

    Regards

    Siddharth