When instantiating an addsub block, the quotes would get munged,
rendering the parameter as such:
.USE_IMPL(Verilog)
The correct rendering should be:
.USE_IMPL("Verilog")
This leads to Vivado complaining about how the expression `Verilog` is
not known (it should be a string constant).
We fix this by using the recently introduced 'q' filter.
Discussed in https://github.com/EttusResearch/uhd/issues/809.
Starting with Boost 1.66 and the corresponding ASIO version, there were
some changes introduced based on the C++ Networking TS. This includes
changes like replacing io_service with io_context, deprecating some
functions, etc. Starting with Boost 1.87, the old style is no longer
supported.
This commit updates all usage of ASIO in a way that makes UHD compatible
with future versions of ASIO. However, this makes UHD no longer
compatible with Boost 1.65 and below.
Summary of changes:
- Replace asio::io_service with asio::io_context
- Replace asio::io_service::strand with
asio::strand<asio::io_context::executor_type>
- This implies using asio::post() instead of asio::strand::post()
- Replace asio::buffer_cast<T>(buf) with static_cast<T>(buf.data())
- Update resolve(query) with new API
- Replace references to endpoint_iterator with resolver::results_type
- Replace ip::address::from_string() with ip::make_address()
Co-authored-by: Jörg Hofrichter <joerg.hofrichter@emerson.com>
- Add a new public API call get_pkg_data_path() which returns the
location of the "share" data. On a Unix system, this will typically
return "/usr/share/uhd" when doing a regular system install.
- Purge all references to this path in UHD, and use the new API call
instead.
- Add --pkg-data-path as an option to uhd_config_info.
The IO port width of the radio ports is bitfile-dependent. We therefore
create a new device parameter for X440 called NUM_PORTS_PER_RADIO and
peg it to the RF_BW.
Implementing tune requests in rfnoc blocks using Action API.
Created new tune request action which contains the
tune_request, tune_result and ranges required for tuning.
The tune request can be issued using issue_tune_request() API from
RX/TX Streamers. The tune request action propagates through the
blocks in the rfnoc graph and does necessary frequency settings.
The output tune frequency can also be obtained from the RX/TX
streamers using get_rx_tune_frequency() or get_tx_tune_frequency()
respectively.
Co-authored-by: Riya Alias <riya.alias@ni.com>
This simplifies image core files by generating a RADIO_NIPC parameter
for the X410, X440 and E31x BSP files. The IO port widths for X410 are
now dynamically widened based on the NIPC value, which is a function of
the RF_BW parameter, and cannot be modified.
The radio block can now read the NIPC value from the BSP, and populate
its spc parameter dynamically. This avoids having to know the right spc
value when writing YAML image core files and reduces redundancy.
This also removes the RADIO_NIPC parameter entirely from all the image
core files. This parameter was fine, but it was a bit confusing because
it referenced a Verilog parameter, which you just had to know was there
in the generated Verilog. By referencing the BSP parameter instead, the
YAML files (BSP, radio.yml, and image core file) are now self-contained
regarding the RADIO_NIPC/spc information.
As a minor upside, the input wire widths for X410's and N310's
rfnoc_image_core.sv module are now generated with the correct widths,
and not, as before, with the worst-case width (and then we assume Vivado
will do the right thing).
There were a bunch of warnings about unused variables in UHD which were
handled in different manners:
- usrprio_rpc_common.hpp: Here a superfluous if statement was used to
avoid the "unused" warning. However, recent compilers can also detect
the superfluous if statement, so unused variable is now simply left
undeclared.
- radio_control_impl.cpp had an unused constant which is now removed,
and a conditionally used capture value which is now made "used" even
when TRACE-level logging is disabled.
- Responder.cpp had an unused variable which was required to be
specified as an output argument for a C-style function, so we declare
it unused to silence the warnings.
This is a combination of running include-what-you-need for clang14 on
the files in host/include with a manual vetting process.
As these are exposed header files, this seems like the most valuable are
to fix missing includes.
The manual vetting process consists of:
- Making sure iwyu uses <> includes consistently with our codebase (it
sometimes uses "" includes instead)
- For boost includes, do the "normal" inclusion (e.g., include
boost/optional.hpp instead of just all the individual sub-includes
that are required) for better cross-Boost-version compatibility
- Prefer cstddef over stddef.h
This adds some checks for:
- DRAM parameters
- Whether or not CHDR DMA and QSFP IO ports are connected
This will cause old image core files to fail with the new image builder,
unless --no-warnings is added, or the image core files are updated to
include these transport adapters.
Since X440 is special in terms of operation in different Nyquist zones
users may stumble upon unexpected RF performance compared to other
devices if frequencies are chosen close to a Nyquist boundary. The
guided mode provides more information about the Nyquist zone in which
the chosen frequency is located in the info log. For disabling the
guided mode, `guided_mode=false` can be added to the UHD config file
in the "Global" section.
- All RFNoC capable targets now require rfnoc_image_builder to be built
- `make help` is updated for all targets to provide more useful and
up-to-date information
- The FPGA manual is also updated
- All checked-in build artifacts are now removed from git
- axi_ram_fifo.yml is updated to provide include path information
(required for building N3xx BIST images, which use this)
This creates an IO port `pps` for X410, and two IO ports (`pps0`, `pps1`)
for X440 which allows modules inside the RFNoC image core to access the
FPGA. Note that accessing the PPS signal is generally not required for
RFNoC blocks which require access to timing.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Most important effect of this change: rfnoc_image_builder is now
required to build bitfiles, 'make' alone won't suffice any longer!
This is a huge changeset to the image builder that combines multiple new
features:
- There no longer is a separate edge file for the static router. The
static routes are generated as a Verilog parameter directly into the
rfnoc_core_kernel (which is also modified).
- image_builder.py is split up into several smaller files. Code is moved
into yaml_utils.py, and the new files grc.py, builder_config.py
- Generic module support is added. Aside from noc blocks and stream
endpoints, we can now instantiate arbitrary modules (they also require
a YAML description file).
- To enable such modules, resets are now also tracked the same way that
clock domains are.
- The ImageBuilderConfig config object now more closes matches the
original YAML file. The attributes 'clk_domain_con' and 'block_con' are
removed. Instead, the attributes 'connections' and 'clk_domains' are
sanitized and amended with extra annotations. The templates are
updated to reflect this change.
- IO ports can now carry parameters, e.g., to have variable wire widths
based on the configuration.
- Many Pylint warnings were resolved.
- Add inheritance support for image core YAML files.
This allows image core files to (recursively) inherit from other image
core files. To do so, simply put an 'inherit' entry at the top of the
file:
```yaml
inherit: 'x410_radio_base.yml'
```
- The inheritance feature is used as part of the image core files.
- Image core and DTS files are now generated as a build artefact into
the build directory. This requires the usage of rfnoc_image_builder to
build images. As a consequence, it is no longer required to check in
image core Verilog files.
- As another consequence, rfnoc_image_builder is required to build
bitfiles!
- Image flavours are no longer defined through Makefiles, but purely
from the image core YAML files.
- Remove all image core YAML files that do not generate a shipping
image. Because of the inheritance feature and the requirement to use
the image builder, it is trivial to add new YAML files.
- Add support for transport adapters through the YAML files. Before,
transport adapters were inferred from the make target (e.g.,
X410_X4_200 would have four 10GbE links based on the 'X4' substring).
Now, transport adapters are defined via the image core YAML.
- This feature is currently only used (or can be used) by the X4xx
series. Older devices may or may not be ported to allow custom
transport adapters in the future.
- Add parameters to the BSP YAMLs and the devices itself. This allows
setting global parameters in the image core files. For example, the
X4x0 devices use this to decide if they instantiate DRAM channels.
- DTS includes and constraint files can now be requested by
blocks/transport adapter through their YAML files. They do no longer
need to be listed in the Makefile.
- Support for secure image cores. These are image cores that allow
incorporating RFNoC blocks that require license keys and thus can't
live in an open-source environment. This solution adds the option for
secure image cores without touching the open source feature set.
- Add --reuse option to allow manual editing of generated artefacts
- Allow IO signatures from any module: until now IO signatures had to be
defined in a single file (io_signatures). This file will persist. In
addition each module can add its own IO signature as with the same
format the core IO signatures placed under the top level key
`io_signatures`. IO signatures are still maintained in a global
dictionary. The consequence is that they can be shared among
independent modules as well as they have to have a globally unique
name. The image builder will warn about detected name clashes for the
signatures.
- As a consequence, some less commonly used IO signatures were moved to
their corresponding module YAML files.
Co-authored-by: Wade Fife <wade.fife@ni.com>
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
NoC blocks have the ability to define_custom_register_space() for their register_iface, this adds the ability for the daughterboard to call this function on the radio block through the dboard_iface
The latest revision of the FIR filter block requires writing
coefficients in reverse order. Changes:
- The newer revision of the block uses a different NoC-ID. We therefore
register both the old and new NoC-ID to the same block controller.
- The new block includes a compat register, which we read out. For the
old revision, the compat number is hard coded to 1.0.
- On newer revisions, the direction of the coefficients is reversed when
programming them.
The documentation for the streamers was misleading as it said that there
can only be one TX streamer and one RX streamer while you can have many
of them as long as they don't try to share their channels. This commit
makes this clearer.
Current implementation only support dot representation of
the graph topology. This adds the ability to also query
the current graph layout. The method prints out connected
blocks (including streamers) and their port to port
connections. The graph has to be commited before calling to_dot.
Update host/lib/rfnoc/graph.cpp
Co-authored-by: Martin Braun <martin.braun@ettus.com>
When catching an exception in UHD_SAFE_CALL(), a log message is emitted.
This patch changes the log level from ERROR to WARNING. The rationale is
that when we are using UHD_SAFE_CALL, we must have already made the
decision that an exception is not fatal.
Note that UHD_SAFE_CALL() is most commonly used in destructors, where
throwing exceptions will cause crashes when the stack is already being
unrolled due to a previous exception, and therefore usage of
UHD_SAFE_CALL() is mandatory. However, even in those cases, logging
a WARNING rather than an ERROR is the better default. If an exception is
throw during a destructor that must truly be handled differently, more
sophisticated measures must be taken than using UHD_SAFE_CALL().
This updates the RFNoC image cores to separate the two DRAM banks on
X4xx by splitting them into "dram0" and "dram1". Previously, both DRAM
banks shared the same DRAM port, named "dram", which created some
confusion.
The Replay block has also been duplicated in the bitstreams that use
both banks, so we now have one Replay block per bank.
- Update X410 and X440 BSP YAML files to properly index clocks
- Update image core files to declare clock indices
- Update get_clocks() in MPM to return the correct values
This does not include changes to the x400_radio_control block registry.
This change by itself will thus not change behaviour.
During creation of the RFNoC graph, the block registry is queried to
identify the clocks used for timebase and control. This adds the option
to ask the FPGA instead (via backend interface).
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
- Image core files can now provide timebase_clock and ctrl_clock fields
to blocks, which will populate the backend interface accordingly.
- Clocks ports now have a direction associated (in, out).
Change the syrnchronization order to be following:
- Run the MTS (multi-tile sync) procedure
- Run the timekeeper alignment to next_pps edge
- Run the post timekeeper alignment steps (none for now)
This ensures that any effects caused due to delay adjustments which are
part of the MTS procedure do not affect timekeeper alignment.
Without this change timekeepers on two X4xx devices would be mis-aligned
slightly in a multi-device scenario.
Note that setting all timekeepers to a common time_spec on the next_pps
as a part of post-initialization application code will still align them perfectly.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
