From: Brian Padalino bpadalino@gmail.com
Date: March 27, 2020 at 11:54:02 AM EDT
To: discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] AD9361 LVDS Interface Delays

In the ad9361_data_sub HDL worker, there are the following LVDS interface
delays listed:

• DATA_CLK_Delay
• RX_Data_Delay
• FB_CLK_Delay
• TX_Data_Delay

Under the build XML file, it seems that these values need to be built for
every variant that could possibly come up.  This seems problematic since
the values may be suboptimal for different sampling frequencies.

I also see in the ad9361_config_proxy-spec.xml file, that for the
ad9361_init struct, the same delays live there.

When I've worked with these devices under linux in the past, ADI had a
dynamic way they found/configured these values:

https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/interface_timing_validation

So, now to my questions:

• Is there a program somewhere, using OpenCPI, that performs the same
  dynamic eye checking to find optimal delays for the AD9361?
• Is there a reason that the ad9361_data_sub is built multiple times with
  different default delays when it can be set dynamically for each radio?

Thanks,
Brian

Brian - please take a look at
https://gitlab.com/opencpi/opencpi/-/wikis/AD9361-Integration-Guide and
then let us know any remaining questions. This will give us an opportunity
to improve that wiki page. Thanks!

Brian - please take a look at https://gitlab.com/opencpi/opencpi/-/wikis/AD9361-Integration-Guide and then let us know any remaining questions. This will give us an opportunity to improve that wiki page. Thanks!

No apology necessary. Hopefully we can clear this all up.

The hardware delay values are read by software and then used to
populate the initialization struct.

For some new FPGA/card scenario, one has to pick a delay value to
start with, and there's no way of knowing whether this value will work
until you build the first bitstream and observe its timing report.
After that initial "guess", totally agreed that guess and check is not
ideal.

There are indeed 64k theoretical configurations, but in practice, only
on the order of 10-100 will ever be needed. For a new platform or a
new card, it's at most 1 additional combo. Once you find the combo of
values that works for you, please submit a merge request for any
additions to ad9361_data_sub-build.xml.

So one creates/selects values in ad9361_data_sub-build.xml, enforce
use of those values in  platform config/container XML and in the
constraints file. The paradigm we chose was build-time customization
instead of run-time.

No apology necessary. Hopefully we can clear this all up.

The hardware delay values are read by software and then used to
populate the initialization struct.

For some new FPGA/card scenario, one has to pick a delay value to
start with, and there's no way of knowing whether this value will work
until you build the first bitstream and observe its timing report.
After that initial "guess", totally agreed that guess and check is not
ideal.

There are indeed 64k theoretical configurations, but in practice, only
on the order of 10-100 will ever be needed. For a new platform or a
new card, it's at most 1 additional combo. Once you find the combo of
values that works for you, please submit a merge request for any
additions to ad9361_data_sub-build.xml.

So one creates/selects values in ad9361_data_sub-build.xml, enforce
use of those values in  platform config/container XML and in the
constraints file. The paradigm we chose was build-time customization
instead of run-time.

You could copy the data_sub worker into your own project and do it that
way. This may bring up other project namespacing issues, e.g. you might
have to name the copy uniquely.

IMO, the right suite of feature enhancements here would be:

• add a mechanism for restricting possible parameter values in worker build
  configurations (the data_sub wouldn't have any restrictions, so its build
  XML would be empty and would never need to be modified by anyone),
• assembly/container builds would automatically infer and build dependent
  workers
• worker configurations would be built on-demand based on values inferred
  from component/build/worker/assembly/pfconfig/container XML

Re: runtime modification of delays, it is important to clarify: we have
ad9361_config_proxy.rcc, which is a dumb, low-level device proxy which has
a property ad9361_init which sets the delay values. If this proxy is used
alone, you will need to set the property values appropriately for your
platform. Then there are smarter, higher-level proxies, e.g.
fmcomms_2_3_rx.rcc, fmcomms_2_3_tx.rcc, and the newer-generation
dig_radio_ctrlr_fmcomms_2_3.rcc, which have the smarts inside them to read
the delays from the FPGA and assign them without the need to set any
property.

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Wed, Apr 1, 2020 at 12:41 PM
Subject: Re: [Discuss OpenCPI] Fwd: AD9361 LVDS Interface Delays
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org

On Wed, Apr 1, 2020 at 12:19 PM Davis Hoover dhoover@geontech.com wrote:

No apology necessary. Hopefully we can clear this all up.

The hardware delay values are read by software and then used to
populate the initialization struct.

For some new FPGA/card scenario, one has to pick a delay value to
start with, and there's no way of knowing whether this value will work
until you build the first bitstream and observe its timing report.
After that initial "guess", totally agreed that guess and check is not
ideal.

There are indeed 64k theoretical configurations, but in practice, only
on the order of 10-100 will ever be needed. For a new platform or a
new card, it's at most 1 additional combo. Once you find the combo of
values that works for you, please submit a merge request for any
additions to ad9361_data_sub-build.xml.

Is it possible to reference the ad9361_data_sub component out of tree and
build that component just for me, or do I need to modify OpenCPI itself?

If not, could this be a feature enhancement where I define new build
configurations I need of core components without having to touch OpenCPI
itself?

So one creates/selects values in ad9361_data_sub-build.xml, enforce
use of those values in  platform config/container XML and in the
constraints file. The paradigm we chose was build-time customization
instead of run-time.

Roger that.  I found this script in the ad9361_adc_test and I am wondering
if this does a runtime modification, or if it thinks it does but really
doesn't?

https://gitlab.com/opencpi/opencpi/-/blob/b3ce4a1390f3c81579e1b16746a5b9ad0c199639/projects/assets/applications/ad9361_adc_test/scripts/AD9361_BIST_PRBS_delays.sh

Thanks,
Brian

I have to revisit this whole thing because I have tried many different
configurations and I always get 30% BER, but when the TX is supplying the
data, I get 0% BER.  So something seems strange.

Can someone verify that this test still works:

https://gitlab.com/opencpi/opencpi/-/tree/v1.7.0/projects/assets/applications/ad9361_adc_test

Thanks,
Brian

On Fri, Apr 3, 2020 at 1:27 PM Davis Hoover dhoover@geontech.com wrote:

You could copy the data_sub worker into your own project and do it that
way. This may bring up other project namespacing issues, e.g. you might
have to name the copy uniquely.

IMO, the right suite of feature enhancements here would be:

• add a mechanism for restricting possible parameter values in worker
  build
  configurations (the data_sub wouldn't have any restrictions, so its build
  XML would be empty and would never need to be modified by anyone),
• assembly/container builds would automatically infer and build dependent
  workers
• worker configurations would be built on-demand based on values inferred
  from component/build/worker/assembly/pfconfig/container XML

Re: runtime modification of delays, it is important to clarify: we have
ad9361_config_proxy.rcc, which is a dumb, low-level device proxy which
has
a property ad9361_init which sets the delay values. If this proxy is used
alone, you will need to set the property values appropriately for your
platform. Then there are smarter, higher-level proxies, e.g.
fmcomms_2_3_rx.rcc, fmcomms_2_3_tx.rcc, and the newer-generation
dig_radio_ctrlr_fmcomms_2_3.rcc, which have the smarts inside them to
read
the delays from the FPGA and assign them without the need to set any
property.

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Wed, Apr 1, 2020 at 12:41 PM
Subject: Re: [Discuss OpenCPI] Fwd: AD9361 LVDS Interface Delays
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org

On Wed, Apr 1, 2020 at 12:19 PM Davis Hoover dhoover@geontech.com
wrote:

No apology necessary. Hopefully we can clear this all up.

The hardware delay values are read by software and then used to
populate the initialization struct.

For some new FPGA/card scenario, one has to pick a delay value to
start with, and there's no way of knowing whether this value will work
until you build the first bitstream and observe its timing report.
After that initial "guess", totally agreed that guess and check is not
ideal.

There are indeed 64k theoretical configurations, but in practice, only
on the order of 10-100 will ever be needed. For a new platform or a
new card, it's at most 1 additional combo. Once you find the combo of
values that works for you, please submit a merge request for any
additions to ad9361_data_sub-build.xml.

Is it possible to reference the ad9361_data_sub component out of tree and
build that component just for me, or do I need to modify OpenCPI itself?

If not, could this be a feature enhancement where I define new build
configurations I need of core components without having to touch OpenCPI
itself?

So one creates/selects values in ad9361_data_sub-build.xml, enforce
use of those values in  platform config/container XML and in the
constraints file. The paradigm we chose was build-time customization
instead of run-time.

Roger that.  I found this script in the ad9361_adc_test and I am
wondering
if this does a runtime modification, or if it thinks it does but really
doesn't?

https://gitlab.com/opencpi/opencpi/-/blob/b3ce4a1390f3c81579e1b16746a5b9ad0c199639/projects/assets/applications/ad9361_adc_test/scripts/AD9361_BIST_PRBS_delays.sh

Thanks,
Brian

Brian,

I just tested the ad9361_adc_test application on Zedboard/FMCOMMS2 platform
and it reported 0% BER.

Since version 1.7.0 we're moving away from these tests and have added newer
tests called: data_src_qadc_test and data_sink_qdac_tests that utilize the
new split clocking ADC/DAC paradigm for AD9361 transceiver. We have
examples available for the following platforms: Zedboard/FMCOMM2/3, E310,
and ZCU104.