Post Go back to editing

differences between libiio and the TES software in terms of the adrv9001

Hi all,

we are using 7z035+adrv9001 sdr which for the moment we encounter many problems while using libiio scripting and a notion appeared before us.

1. what is the most support platform while using the adrv9001 ? the TES or the libiio?

2.is there any different in the performance between the two SW ?

3. what your preferable SW  if i plan to use a custom board (not evaluation board meaning that i need to learn how to create my own custom image and kernel if i intended to use the TES)

with best regards .

Dror  

Parents
  • I know and totally agree that this is confusing.

    I would start reading this:

    There are also some answers on this on the different forums:

    https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/f/q-a/553877/adrv9002-zcu102-workflow

    You can’t compare TES with libiio. Sine these are two totally different things.

    TES is the Transceiver Evaluation Software, while libiio is a generic library to ease interfacing with Linux IIO devices.

     

    TES includes a GUI, which communicates with a Linux system which runs the API driver in Linux user space.

    It has its own RPC client server which needs to update with every API/TES release.

    TES allows you to export configurations which can be consumed by the API. Or by the Linux IIO driver.

     

    On the prototype system libiio is this RPC mechanism, but libiio doesn’t need to update.

    Since the API driver (which is in both systems the same) runs in kernel mode.

    So, this means when you use the libiio system you communicate with a kernel device driver,

    and not with an executable which communicates with the underlaying HW via UIO, spidev and gpio sysfs.

      

     

    In most situations kernel mode drivers have lower overhead and latency, while on the other side you can’t call into the API directly, you’re limited to the functionality the IIO driver supports.

    Libiio allows low overhead fast continuous streaming of raw IQ data, while the other RPC mechanism is more for single burst captures.

     

    If you’re planning to use Linux just for evaluation and you move to a bare metal environment later -

    You can go either way.

    If you just want to evaluate ADRV9001-ADRV9007 use TES with either ZC706 or ZCU102.

     

    Generally speaking, we take API driver and firmware from the TES release and incorporate them into the Linux kernel driver.

    So there is always a bit of lag involved.

     

    If you want to integrate everything on your custom carrier and target Linux, I would go with the prototype system.

    But this involves some level of Linux background, such as compiling kernels or modifying device trees, etc.

     

    The HDL cores involved are supported for both Intel and Xilinx FPGAs. In fact, the cores are almost identical with the ones

    used for previous RF transceivers such as AD936x, AD9371/5, ADRV9009/8, etc.

    However the HDL source included with the TES package are different from the ones used in the prototype system.

     

    If you have questions related to the HDL design, you probably receive more support when using the prototype system.

    While the TES system is supported and maintained directly by the responsible business unit.

     

    It’s your choice, and having choice is never a bad thing.

    -Michael

Reply
  • I know and totally agree that this is confusing.

    I would start reading this:

    There are also some answers on this on the different forums:

    https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/f/q-a/553877/adrv9002-zcu102-workflow

    You can’t compare TES with libiio. Sine these are two totally different things.

    TES is the Transceiver Evaluation Software, while libiio is a generic library to ease interfacing with Linux IIO devices.

     

    TES includes a GUI, which communicates with a Linux system which runs the API driver in Linux user space.

    It has its own RPC client server which needs to update with every API/TES release.

    TES allows you to export configurations which can be consumed by the API. Or by the Linux IIO driver.

     

    On the prototype system libiio is this RPC mechanism, but libiio doesn’t need to update.

    Since the API driver (which is in both systems the same) runs in kernel mode.

    So, this means when you use the libiio system you communicate with a kernel device driver,

    and not with an executable which communicates with the underlaying HW via UIO, spidev and gpio sysfs.

      

     

    In most situations kernel mode drivers have lower overhead and latency, while on the other side you can’t call into the API directly, you’re limited to the functionality the IIO driver supports.

    Libiio allows low overhead fast continuous streaming of raw IQ data, while the other RPC mechanism is more for single burst captures.

     

    If you’re planning to use Linux just for evaluation and you move to a bare metal environment later -

    You can go either way.

    If you just want to evaluate ADRV9001-ADRV9007 use TES with either ZC706 or ZCU102.

     

    Generally speaking, we take API driver and firmware from the TES release and incorporate them into the Linux kernel driver.

    So there is always a bit of lag involved.

     

    If you want to integrate everything on your custom carrier and target Linux, I would go with the prototype system.

    But this involves some level of Linux background, such as compiling kernels or modifying device trees, etc.

     

    The HDL cores involved are supported for both Intel and Xilinx FPGAs. In fact, the cores are almost identical with the ones

    used for previous RF transceivers such as AD936x, AD9371/5, ADRV9009/8, etc.

    However the HDL source included with the TES package are different from the ones used in the prototype system.

     

    If you have questions related to the HDL design, you probably receive more support when using the prototype system.

    While the TES system is supported and maintained directly by the responsible business unit.

     

    It’s your choice, and having choice is never a bad thing.

    -Michael

Children
No Data