Packages may use the build type to decide whether to look for
release or debug binaries. It is therefore cruicial to set the
build type before searching any package.
Install the toml file for Windows only, otherwise pip installs into
venv with Python versions between min (3.7) and 3.10 (what the toml
requests), which will fail.
doc: Update usrp_x4xx.dox with table for supported sample rate examples and links to KB and X440 Spec.
Co-Authored-By: Aki Tomita <121511582+atomita-ni@users.noreply.github.com>
The Python examples are only included in the installer, if Python
is enabled during build. Therefore use the NSIS installer from the
Python enabled build. This makes it unnecessary to distinguish
Python/non-Python pipeline build which speeds up pipeline runs.
On the downside Python examples are installed no matter whether
they are needed or not.
... in case the configuration ENABLE_PYMOD_UTILS was not set.
This corrects the default images directory for
uhd_images_downloader on the embedded filesystem.
This warning turned out to be scientifically inaccurate. The actual
auto-coercion of the spp value to the CHDR width is left in place, as it
improves streaming under certain conditions, but we no longer warn if
a user-selected spp value is not aligned with the CHDR width.
Unless the user specifies an spp value in a Tx streamer by means of
a stream argument, the Tx streamer now holds additional logic that
aligns the spp value with the CHDR width. For example, in an X410 100
GbE image, the CHDR width is typically 512 bits, which corresponds to 16
samples (sc16), so spp will default to value that's a multiple of 16.
Previously, the default was to simply use the maximum MTU. However,
there have been circumstances observed where using a non-aligned spp
value causes suboptimal behaviour.
For example, when the CHDR width is 512 bits, and the discovered MTU is
8016 bytes, the default spp value would be 1988 samples per packet.
However, a value of 1984 samples per packet causes the CHDR packet to be
of a length that is a multiple of 64 bytes (== 512 bits) which can
improve performance.
This change does not affect applications where the spp size is already
manually configured, and has almost no influence on use cases where the
CHDR width is 64, because that just means the optimal number of samples
per packet should be even.
Under the hood, the following changes were made:
- The CHDR width is passed into the streamer as a reserved key
(__chdr_width) from the infrastructure.
- After connecting the Tx streamer to the graph, when the MTU is known,
we add a check for the spp value to make it an integer multiple of the
CHDR width if not specifically given (like a "soft atomic item size").
Co-authored-by: Jörg Hofrichter <joerg.hofrichter@emerson.com>
This allows querying the CHDR width for a given device in an RFNoC
graph. The mb_index parameter is mostly for future proofing, given that
the CHDR width must be constant between devices.
Previously, the value from --tx_spp was only used if --tx_spb was not
also provided (basically, it was a default for --tx_spb).
Now, the value from --tx_spp is used as a stream argument for the Tx
streamer. If both --tx_spp and --tx_spb are provided, then
benchmark_rate will split the full burst size (--tx_spb) into packets of
size --tx_spp. Previously, if both parameters were given, and --tx_spb
was bigger than --tx_spp, the actual packet size was determined by the
maximum packet size available at the interface or the --tx_spb value,
whichever was smaller.
This commit also aligns the usage of --tx_sample_align. Previously, it
was only implemented for the multi-streamer use case. Now it works the
same between the multi- and single-streamer use cases, and the
diagnostic output now shows SPP and SPB values for both. If both
--tx_spb and --tx_sample_align are given, we potentially have a conflict,
which the tool now warns about.
When using --random, --tx_sample_align now also applies to all burst
sizes.
Add the patch version number to poetry version. Because UHD uses
the patch number for adding branch information on development branches
we need to save the patch number in some different variable for later
access.
Depending on the build folder poetry build might use build.py
instead of the intended build package which leads to an import error
for "BuildBackendException". To prevent confusion rename the script
to something UHD specific.
This moves the calibration Python utilities into the
uhd Python module (because they have dependencies to
uhd). Also the poetry script adds them as scripts to
the uhd module.
The install Python module is not executed on Windows
systems.
usrpctl, rfnoc image builder and rfnoc modtool are
not affected.
The existing regex that filters the required HDL sources from
Makefile.srcs had an issue where it would identify VHDL files as Verilog
files (because the string 'file.v' is a substring of 'file.vhdl').
The CMake regex engine does not have support for word boundaries, so we
use the greediness of the regex algorithm and search for .vhd(l) first.
Introduce a new parameter --base-dir BASE_DIR.
If the parameters --build-dir BUILD_DIR / --build-ip-dir BUILD_IP_DIR
/ --build-ouput-dir BUILD_OUTPUT_DIR are not set explicitly, they will
be set to these values per default:
- BUILD_DIR=<BASE_DIR>/build-<IMAGE_CORE_NAME>
- BUILD_IP_DIR=<BASE_DIR>/build-ip
- BUILD_OUTPUT_DIR=<BASE_DIR>/build
BASE_DIR defaults to the current directory if the parameter --base-dir
is not set. This means that per default, the build(...) directories
are generated in the current directory.
The directories which are used for the build are printed before
executing the build. However, the build generates hundrets of
lines of output which typically exceeds the scrollback length
of the terminal. Hence, print the directories again after the
build finished.
This example demonstates the cyclic prefix (CP) insertion and removal
capability of the new FFT block. It is intended to be used in cabled
RF loopback. Multiple OFDM symbols with configurable CP length are
transmitted and received. Each OFDM symbols contains a single tone
so that transmitted and received signal can be compared.
The interface of the FFT block controller was extended to include functions for
querying the capabilities and setting cyclic prefix insertion / removal values.
-> Extend the existing fft_block_test (for FFT_BLOCK, RFNoC ID 0xFF700000)
to cover the additional functions.
Also add a new test fft_block_test_v2 which tests the interface of the new
FFT block (FFT_BLOCK_V2, RFNoC ID 0xFF700002).
This replaces the legacy RFNoC FFT block with a new one of the same
name that includes a superset of the original features. New features
include cyclic prefix insertion or removal and FFT sizes up to 64k.
