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_at_gmail.com>
Date: Wed, Apr 1, 2020 at 12:41 PM
Subject: Re: [Discuss OpenCPI] Fwd: AD9361 LVDS Interface Delays
To: Davis Hoover <dhoover_at_geontech.com>
Cc: <discuss_at_lists.opencpi.org>
On Wed, Apr 1, 2020 at 12:19 PM Davis Hoover <dhoover_at_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
Received on Fri Apr 03 2020 - 17:26:39 CDT