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.
---------- Forwarded message ---------
From: Brian Padalino <bpadalino_at_gmail.com>
Date: Wed, Apr 1, 2020 at 11:20 AM
Subject: Re: [Discuss OpenCPI] AD9361 LVDS Interface Delays
To: Davis Hoover <dhoover_at_geontech.com>
Cc: <discuss_at_lists.opencpi.org>
On Fri, Mar 27, 2020 at 1:47 PM Davis Hoover <dhoover_at_geontech.com> wrote:
>
> 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!
Thanks for the link. Reading through, I still have a question as to
the runtime programability of the values.
The delay values are built into the HDL, but also provided at runtime
to the RCC initialization struct. Which takes precedence? Or is it
always the hardware one is read and populates the initialization
struct?
I am not a fan of the guess-and-check methodology. If things get
unwieldy, with each register being 4 bits, isn't that 65536 potential
cores that need to be generated? I don't want to copy the code around
everywhere to modify the build parameters of a core piece of OpenCPI.
I think this mainly comes back to the question of on-demand
customization and not utilizing NGC/EDIF netlists and just stitching
things together using source code and references?
What is the best methodology going forward?
Sorry for all the questions and confusion.
Brian
Received on Wed Apr 01 2020 - 16:18:18 CDT