This fixes the following warnings:
(...)/host/docs/install.dox:43: warning: Found unknown command '\VS20XX'
(...)/host/docs/install.dox:43: warning: Found unknown command '\MSYY'
(...)/host/docs/install.dox:43: warning: Found unknown command '\dll'
WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid language code. Falling back to 'en' (English).
WARNING: html_static_path entry '_static' does not exist
The RFNoC DDC/DUC block controllers had a bug, in which they would only
program the upper 24 bits of the 32-bit phase increment value for the
digital frequency shifter.
The DDC/DUC use a 24-bit DDS + multiplier to shift frequency digitally,
but the phase increment input to the DDS is a 32-bit value, which we
were (incorrectly) quantizing to a 24-bit value. This meant we were
artificially limiting the digital frequency accuracy, e.g., for a 200
MHz sample clock, to 200MHz / 2^{24} == (approx.) 12 Hz, which in turn
meant there was an unnecessary frequency error of up to 6 Hz (for lower
clock rates, the error would be smaller but still unnecessarily high).
This patch fixes the width of the phase increment value and allows for
sub-Hz accuracy (once again).
This bug was introduced in 699870d (first released with UHD 4.2).
When attempting to generate an image core file with no control SEPs
(which is illegal), the image builder would throw an exception while
trying to produce the proper error message. The exception would look
like this:
File "[...]/site-packages/uhd/rfnoc_utils/builder_config.py", \
line 330, in _check_configuration
failures += [
TypeError: can only concatenate str (not "list") to str
This fixes the error, such that a regular error messages is shown now in
case of missing control SEPs.
When using the following command syntax:
rfnoc_image_builder --fpga-dir=~/path/to/uhd/fpga \
--yaml-config=~/path/to/image_core.yml
The shell won't expand the ~ (shorthand for $HOME) and the image builder
needs to expand the path itself, which is fixed in this commit (for
--fpga-dir, --yaml-config, and --grc-config).
Note that this is not a problem when skipping the "=", i.e., the
following work without this fix, assuming a shell that auto-expands the
tilde symbol (e.g., bash, zsh):
rfnoc_image_builder --fpga-dir ~/path/to/uhd/fpga \
--yaml-config ~/path/to/image_core.yml
or
rfnoc_image_builder -F ~/path/to/uhd/fpga \
-y ~/path/to/image_core.yml
This adds support for generating RFNoC bitfiles from GNU Radio Companion
(.grc) files. Note that this requires changes to GNU Radio as well
(updated block definition files for the GRC bindings).
There is a new mini-feature in the image builder itself: The option to
dump the YAML file into the build directory. For the GRC import, this
makes sense, because it allows reading the UHD YAML represenation of a GRC
image core.
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.
Changed rfnoc_replay_samples_from_file and rfnoc_rx_to_file examples to
demonstrate the use of tune requests in RFNoC blocks.
Co-authored-by: Riya Alias <riya.alias@ni.com>
This adds tests for action forwarding in DDC and DUC block tests which
are required for Tune Requests in RFNoC.
Co-authored-by: Riya Alias <riya.alias@ni.com>
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 fixes an issue where default clocks would not get detected
properly when checking for correct clock domain connections (change
added in ce96d9bf). The following error message could be observed with
some image cores:
[error] Invalid clock domain connection: _device_:rfnoc_chdr → ddc0:ce
(rfnoc_chdr is not a clock output)
[error] Invalid clock domain connection: _device_:rfnoc_chdr → duc0:ce
(rfnoc_chdr is not a clock output)
Clearly, _device_.rfnoc_chdr is a valid clock output, but it was not
detected because default clocks are stored differently from non-default
clocks.
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).
- Default BSP parameters are now also resolved and can make use of
previously defined BSP parameters
- Regular block parameter resolution is simplified
This improves error checking and -messages for IO ports. In particular,
this will now be able to check wire widths for compatibility. Imagine
you have a BSP with a radio connection of 1 SPC, 64-bit CHDR width, and
attempt to instantiate a radio block with 2 SPC (and also 64-bit CHDR
width). Without this changeset, the misconnection would either be caught
by the bitfile generation process, or not at all (e.g., if we are
connecting a narrow bus to a wider one, we would simply connect the
least significant bits).
With this changeset, a clear error message is given immediately when the
YAML is parsed such as this:
Connection _device_:radio0 → radio0:radio has a wire width mismatch.
Source port radio_rx_data_radio0 has width 64, destination port
radio_rx_data has width 128.
Unused variables, constants, and functions cause compiler warnings on
recent compilers. We therefore remove those, or comment them out. The
heuristic for when to comment out and when to delete is as such: If
there is a list of constants or variables, where the unused constant
makes sense within a list, it is commented out. Otherwise, it is
deleted.
The class dpdk_frame_buff was referred to as a struct in the DPDK code,
which is valid, but can causes trouble. Recent compilers (e.g., clang
18) will produce a warning. We therefore fix the reference.
udp_dpdk_link did not have a virtual destructor, which it should have as
a virtual class (other classes inheriting from recv_link_if or
send_link_if do this correctly). This would produce compiler warnings on
more compilers (e.g., clang 18) like this:
warning: destructor called on non-final 'uhd::transport::udp_dpdk_link'
that has virtual functions but non-virtual destructor
[-Wdelete-non-abstract-non-virtual-dtor]
When using recent compilers (e.g. clang 18) and C++20 flags, the DPDK
headers that are included by UHD produce warnings because they are not
fully compliant.
Because those headers are external to UHD, we simply ignore the warnings
originating from DPDK.
This adds more checks for clock connections:
- When an input clock is not connected, a warning is now produced, like
this:
⚠ Unconnected clock input: gain0.ce
Previously, this would go without any warning.
- When source or destination block are incorrectly specified, the error
message is improved to give a much clearer indication which line of
the input file is wrong:
⛔ Invalid clock domain connection: _device_:ce → gaen0:ce
(destination block is not defined)
- When two input or output clocks are connected, this is now also
flagged as an error:
⛔ Invalid clock domain connection: radio0:radio → gain0:ce (radio
is not a clock output)
- When a block specifies a timebase or control clock (as the radio
blocks on X4x0 do, for example) we now check the validity of the
clocks. If an invalid or unknown clock is provided, there is now
a clear error message:
⛔ Invalid timebase_clock for block radio0: _device_.tb_clk
- Clock checking is now performed on all modules, transport adapters,
and blocks with the same rules applying to all of them.
- Because of all the new features, the clock management code was
simplified to recoup some complexity. The `self.clocks` object was
discarded, and all blocks, modules, and transport adapters now store
all clock information on themselves. For example,
`self.noc_blocks["radio0"].clocks` would provide all information on
the clocks for radio0. This change also makes the builder object more
similar to the YAML file (there is no "clocks" object in the YAML).
- As a result of the previous change, the template code for generating
clock indices for control and timebase clock was simplified, and the
logic for looking up the correct index was moved into
builder_config.py.
The method ImageBuilderConfig.get_module_list() can now take
a 'nodevice' argument, which is a wildcard argument for "return all
blocks and modules, but not the device".
The docstring is also updated.
Different compilers are not in agreement how to handle captures for
constexprs. On recent clang versions, a warning such as this is produced:
warning: lambda capture 'max_read_bytes' is not required to be captured
for this use [-Wunused-lambda-capture]
However, some versions of MSVC *require* the capture, so we have to
leave it in and live with the warnings. We therefore disable the
warnings as they have no value for us.
Different compilers are not in agreement how to handle captures for
constexprs. On recent clang versions, a warning such as this is produced:
warning: lambda capture 'max_read_bytes' is not required to be captured
for this use [-Wunused-lambda-capture]
However, some versions of MSVC *require* the capture, so we have to
leave it in and live with the warnings. We therefore disable the
warnings as they have no value for us.
Previously, we had lambdas that would capture 'this' and then not use
it. Because on modern compilers (e.g., clang 18) this produces
a compiler warning, we remove the unnecessary captures.
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.
Unused variables, constants, and functions cause compiler warnings on
recent compilers. We therefore remove those, or comment them out. The
heuristic for when to comment out and when to delete is as such: If
there is a list of constants or variables, where the unused constant
makes sense within a list, it is commented out. Otherwise, it is
deleted.
When find issues a broadcast to identify devices in the network
it might happen that it receives multiple answers from the same
device due to network topology.
This fix removes these duplicates by utilizing the hash method
of device.cpp.
This fixes https://github.com/EttusResearch/uhd/issues/729.
Users might build X400 bitfiles without RF blocks in it. In that
case the DSP info will report 0 for both the TX and RX.
MPM needs to handle that case correct an skip RF block initialization
an fall back to default values. This will allow bitfiles without
RF to load.
This adds code to check if sources or destinations are referenced
multiple times in the connection list of a YAML file, and provides more
useful error messages if that is the case.
This creates common.py and connections.py and moves code from
builder_config.py into those files. This is to facilitate future
modifications in the image builder.
In various points of UHD, we rely on implicit conversions of enum values
to double or other C++ types. In future versions of C++, those are
deprecated. In order to prepare for future versions, we fix those
implicit conversions by making them explicit.
In C++20, copy-capture of `this` must be made explicit, which we fix
with this commit. In C++17, auto_ptr is deprecated so we replace it with
unique_ptr.
