adrv9001-sdk hardware addresses

I am able to successfully build the adrv9001-sdk.

However, I have a custom platform and I do not see where the SDK gets its addressing for the IP.

The notes state that the zc706 platform is used, but I do not see any addressing for this platform.

There is no hardware importing for this sdk and no xparameters.h.

So how do I map the IP to the custom hardware addressing.

Is there an example of this?

Modifying the HAL in some way?

Thanks

Parents
  • 0
    •  Analog Employees 
    on Apr 6, 2021 10:23 AM

    Hi Dan,

    I've moved this question here, as it is the more appropriate place for it.

    To begin answering your questions and some of your follow-up questions, I'll start by saying that we do not provide a way for you to program a custom setup dynamically the same way you do with the TES on the ZC706 or ZCU702. Our own SW uses a proprietary Client-Server platform which we develop, and as such we do not support customers modifying the Client or Server code to suit their own bespoke platform, meaning that TES will never connect to your platform.

    As for the SDK, the IP address of your bespoke platform, whatever platform it is, doesn't matter for programming the part. The IP address only matters for the compile_on_platform.py script that we provide. This script will push your SDK with your bespoke platform code to your platform at the IP address you provide at runtime. To see a guide for using this compile_on_platform.py script, view this guide:

    https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/w/documents/15577/produce-and-compile-sample-c99-code

    Focusing now on your follow up questions:

    1. As I stated, the IP address of your platform does not matter for program execution, so there is no need for writing the IP addresses into any part of the HAL.
    2. You are in part correct. The best way to begin development of your own platform HAL is as follows:
    • Navigate to the adrv9001-sdk\pkg\production\c_src\platforms\customer\ folder.
    • Into each file that pertains to devices that you intend to use, write your custom code.
    • Navigate to the adi_platform.c file you mentioned in your question. At the beginning of the file type: "#define CUSTOMER_PLATFORM". Now all of your bespoke code will be used, rather than our default platform code.
    • For the makefile, this will only need editing if you have included libraries that we do not natively support. If you have included external libraries, simply link them in the makefile using the -llibrary_name functionality.

    That should get you most of the way, we've not had a customer needing to modify CFLAGS or deal with the BASE or OFFSET addresses while using this methodology.

    I do hope this helps!

    Best Regards,
    Oisín.

  • Hello Oisín,

    Thank you for the reply, however that does not answer my question.

    I am not referring to the IP address.

    I have no problem starting with the SDK and using the TES files in the test1 folder and then running compile on platform.
    This all works fine.

    My problem is with defining another platform and understanding the AXI addresses that are defined in the files: adrv9001_zc706.h and add the adrv_zcu106.h.

    There are two ifdefs options in these files. BASE and OFFSET.

    If OFFSET is used, how does the code know the BASE address to use?

    Thanks for the help

  • 0
    •  Analog Employees 
    on Apr 6, 2021 2:39 PM in reply to swie

    Hello Dan,

    Apologies for the confusion! I'll take your question to the SW engineers and get back to you once they reply.

    I also noticed that you have another question on the Design Support forum posted at this link:
    https://ez.analog.com/wide-band-rf-transceivers/design-support-adrv9001-adrv9007/f/q-a/543254/adrv9001-sdk-example-hardware-axi-addresses-do-not-match-files-in-sdk

    This questions seems to hit a lot of the same key points as that one does. Would you have any issues with this question being removed? If there are elements of that question not addressed here thus far you can add them as a comment.

    Thanks again! I'll be back when I hear more answers from the SW team.

    Best Regards,
    Oisín.

  • +1
    •  Analog Employees 
    on Apr 9, 2021 10:10 AM in reply to swie

    Hi Dan,

    Yes, just got a response late yesterday evening. Here is everything the SW engineer gave me:

    There is NO Xilinx peripherals or IP cores in MPG’s design (TES SD card image). That is only in SDG (IIO scope or No-OS)

    You don’t see any AXI_QUAD_SPI or you will not find any matching registers, because it is NOT there.

    As to what you should use, it is a decision only you can make.

    All of them work same, but have different features and implementation.

    If – and only If—you use our SPI core, will we support you.

    Here is a comparison of all options you mentioned:

    1. AXI_MSPI
      1. Analog Devices IP Core/Peripheral.
      2. What is in MPG’s HDL (I think this is what you call SDK, which is not technically correct).
      3. This is fully an ADI design and supports some specific things (e.g. frequency hopping and such).
      4. Drivers only in user space.
    2. AXI_QUAD_SPI:
      1. Xilinx IP Core/Peripheral (Soft)
      2. This is used in SDG’s HDL for non SoC devices.
      3. Drivers part of Xilinx’s Kernel/User space module.
    3. PS7/PSU SPI (Zynq SPI):
      1. Part of PS7/PSU (Synopsys or Cadence?) Hard IP Core.
      2. This is used in SDG’s HDL, SoC devices.
      3. Drivers part of Xilinx’s Kernel/User space module.

    The AXI SPI engine is different (though it could be used with some tweaks), it is meant for precision converters and such where ‘data’ is collected through the SPI interface (i.e. it serves as a both control + data port, (optional)).

    I hope this clarifies things for you. If not feel free to post another response here. Do also let me know about removing your duplicate question on the Design Support Forum!

    Best Regards,
    Oisín.

Reply
  • +1
    •  Analog Employees 
    on Apr 9, 2021 10:10 AM in reply to swie

    Hi Dan,

    Yes, just got a response late yesterday evening. Here is everything the SW engineer gave me:

    There is NO Xilinx peripherals or IP cores in MPG’s design (TES SD card image). That is only in SDG (IIO scope or No-OS)

    You don’t see any AXI_QUAD_SPI or you will not find any matching registers, because it is NOT there.

    As to what you should use, it is a decision only you can make.

    All of them work same, but have different features and implementation.

    If – and only If—you use our SPI core, will we support you.

    Here is a comparison of all options you mentioned:

    1. AXI_MSPI
      1. Analog Devices IP Core/Peripheral.
      2. What is in MPG’s HDL (I think this is what you call SDK, which is not technically correct).
      3. This is fully an ADI design and supports some specific things (e.g. frequency hopping and such).
      4. Drivers only in user space.
    2. AXI_QUAD_SPI:
      1. Xilinx IP Core/Peripheral (Soft)
      2. This is used in SDG’s HDL for non SoC devices.
      3. Drivers part of Xilinx’s Kernel/User space module.
    3. PS7/PSU SPI (Zynq SPI):
      1. Part of PS7/PSU (Synopsys or Cadence?) Hard IP Core.
      2. This is used in SDG’s HDL, SoC devices.
      3. Drivers part of Xilinx’s Kernel/User space module.

    The AXI SPI engine is different (though it could be used with some tweaks), it is meant for precision converters and such where ‘data’ is collected through the SPI interface (i.e. it serves as a both control + data port, (optional)).

    I hope this clarifies things for you. If not feel free to post another response here. Do also let me know about removing your duplicate question on the Design Support Forum!

    Best Regards,
    Oisín.

Children
No Data