IIO driver any plans for buffer sync and queuing.

Several people have asked the question regarding IIO devices and radar applications, I have also seen the same reply a couple of times 'limited by HDL'.

After some deep digging on the gnuradio site there is mention that the usrp uses the driver layer to buffer / queue / resync packets, ie if a bad sample is detected at tx it can be skipped and resynced at rx on the next good packet, it also has a time tagged stream based on '1 in N' samples is tagged.

In layman's terms, as simple as possible for someone to understand who's skill level lies in the usage not design of such devices, could an AD employee please explain what are the hard and software limitations of the iio devices and driver that prevent syncing rx/tx to get a reliable time measurement and secondly anyone had any bright ideas on how to do this, I have a wonderful GPR system 3 years in development that works like a dream on a USRP but my original project brief was to bring the hardware costs down by utilising an iio device.

Parents
  • 0
    •  Analog Employees 
    on Feb 22, 2021 7:36 PM 1 month ago

    This is really not that complex to understand. If you think about sending and receiving buffers or really doing any sequence of actions in software, you have no guarantee in time when these actions occur in relation to one another. You would have to go to a real-time OS where events are explicitly scheduled.

    However, inside the FPGA everything is based around clocks and clock cycles. So its easy to relate or even guarantee relations throughout.

    From the software perspective, you want to basically trigger both events (send+capture) in the same software call where the FPGA does both actions for you. USRPs and UHD do this by having specialized state machines inside the FPGA to allow for these operations.

    UHD can do this because it has tight integration between the HDL and software, which allows it to control those state machines. However, this really only applies to devices that have or run that HDL that is specific to UHD. UHD really only supports SDR devices as well, and to my knowledge does not work without devices without its specific firmware.

    IIO is much much more generic and supports thousands of devices. It does not have this hard dependency on HDL and will even work with boards not based on FPGAs. This does not mean you cannot create similar controls or state machines and control them with IIO, they just have not been implemented in those forms. However, there are examples that perform similar actions like:

    https://wiki.analog.com/resources/eval/user-guides/ad-pzsdr2400tdd-eb/reference_hdl

    https://wiki.analog.com/resources/eval/user-guides/adrv936x_rfsom/tutorials/frequency_hopping

    https://wiki.analog.com/resources/eval/user-guides/adrv936x_rfsom/tutorials/loopback_delay_estimation

    All of those examples have custom logic and IIO drivers.

    -Travis

  • +1
    •  Analog Employees 
    on Feb 23, 2021 8:20 AM 1 month ago in reply to travisfcollins

    In addition to What Travis pointed out - Let me provide an additional outlook for what is planned in the next 12 months.

    We’re planning to extend IIO to accommodate what we call buffer meta-data.

    Basically, a small reserved area at the bottom of each buffer that is not transferred via the digital interface.

     

    Meta data will include a timestamp (64-bit counter incremented by the sample clock), a sequence number and additional control information such as

    On RX - the state of the transceiver status pins (the current RF gain value, over-range conditions, FFH fast lock profile, etc.)

    On TX buffers we can include the control pin information, etc.

     

    This all will require some HDL core support. However, we can detect error conditions (DMA over/underrun, etc.) and notify upper layers with the type of condition occurred and when.

    Taking this further a queued TX buffer can be scheduled, e.g. it’s desired timestamp meets the time counter on the interface.

     

    It’s still too early to provide a reliable schedule for this development…

Reply
  • +1
    •  Analog Employees 
    on Feb 23, 2021 8:20 AM 1 month ago in reply to travisfcollins

    In addition to What Travis pointed out - Let me provide an additional outlook for what is planned in the next 12 months.

    We’re planning to extend IIO to accommodate what we call buffer meta-data.

    Basically, a small reserved area at the bottom of each buffer that is not transferred via the digital interface.

     

    Meta data will include a timestamp (64-bit counter incremented by the sample clock), a sequence number and additional control information such as

    On RX - the state of the transceiver status pins (the current RF gain value, over-range conditions, FFH fast lock profile, etc.)

    On TX buffers we can include the control pin information, etc.

     

    This all will require some HDL core support. However, we can detect error conditions (DMA over/underrun, etc.) and notify upper layers with the type of condition occurred and when.

    Taking this further a queued TX buffer can be scheduled, e.g. it’s desired timestamp meets the time counter on the interface.

     

    It’s still too early to provide a reliable schedule for this development…

Children
No Data