- add optional --empty-on-error-non-ci to derive_docker_image_matrix.py
to downgrade derivation errors to warnings in non-strict builds
- handle partial DockerImageNames inputs by tolerating missing/empty
source matrices and returning {} when fallback mode is active
- refactor matrix unit tests to be artifact-driven and non-strict
outside CI (warn/skip instead of fail)
- keep strict failure behavior for CI reasons, while allowing fallback
in manual and PR runs
Adding the RFNoC DDC and DUC blocks to our shipping bitfiles.
The new wideband DxC implementation allow processing input/output
rates up to a maximum of 2000MSps.
This commit adds the DDC/DUC blocks to some of our shipping
bitfiles for all channels.
Co-authored-by: Niels Garibaldi <niels.steffen.garibaldi@emerson.com>
Co-authored-by: André Zoch <andre.zoch@emerson.com>
Co-authored-by: Meghana Halladamath <meghana.halladamath@emerson.com>
Co-authored-by: Wade Fife <wade.fife@ettus.com>
Co-authored-by: Max Köhler <max.koehler@emerson.com>
Updated the host related files to support wideband DxC block
variants.
The singlesample and multisample variants both have the same API,
but internally they are using different register address spaces to
interact with the FPGA implementation.
The host implementation checks which implementation a RFNoC DxC
block is using by checking the block version number and will then
automatically choose the correct register address scheme.
This is all transparent to the user, the Block API stays the same.
Co-authored-by: Niels Garibaldi <niels.steffen.garibaldi@emerson.com>
Co-authored-by: André Zoch <andre.zoch@emerson.com>
Co-authored-by: Meghana Halladamath <meghana.halladamath@emerson.com>
Co-authored-by: Wade Fife <wade.fife@ettus.com>
Co-authored-by: Max Köhler <max.koehler@emerson.com>
Added variants for the DDC/DUC blocks that can process multiple
samples per cycle and can be used for bandwidths higher than
200Mhz.
This new feature is integrated into the existing RFNoC DDC/DUC
blocks. Depending on the Radio bandwidth specified for the USRP
variant, the DxC blocks will instantiate the existing singlesample
implementation(for FPGA image variants <= 200MHz) or instantiate
the multisample implementation(for FPGA image variants > 200MHz).
Co-authored-by: Niels Garibaldi <niels.steffen.garibaldi@emerson.com>
Co-authored-by: André Zoch <andre.zoch@emerson.com>
Co-authored-by: Meghana Halladamath <meghana.halladamath@emerson.com>
Co-authored-by: Wade Fife <wade.fife@ettus.com>
Co-authored-by: Max Köhler <max.koehler@emerson.com>
- Includes all needed files from the ADI-provided software drop, intentionally only including the files needed for the ADRV9032.
- Adds a LICENSE.pdf file that points to ADIs Software License Agreement
- Includes CMakeLists.txt files for building and a .clang-format file to ignore changing format that were not provided by ADI.
These changes are required to build on Ubuntu 26.04 cleanly while still
maintaining backwards compatibility until Ubuntu 22.04.
- Set CMP0167 to NEW in UHD CMake paths that resolve Boost
- Scope policy changes with guard checks so older CMake versions remain
compatible
- Ensure dependency resolution order applies policy before Boost
discovery in package config
- Reduce CMake 3.30+ FindBoost policy warnings without breaking Ubuntu
22.04-era toolchains
Boost.System has been header-only since Boost 1.69, and as of Boost 1.89
its CMake package config was removed entirely.[1]
This makes the `find_dependency(Boost ... COMPONENTS ... system ...)`
call in the installed `UHDConfig.cmake` fail on any downstream project
that does `find_package(UHD)` while linked against `Boost >= 1.89`.
Timeline of how this happened, for reference:
- Up to and including v4.9.0.1, UHDConfig.cmake.in had no Boost
dependency check at all.
- ab724a30ec introduced the
`find_dependency(Boost ... COMPONENTS ... system ...)` call here, to
correctly declare Boost as a transitive dependency of the newly added
`UHD::uhd` imported target.
- c45c296d8f fixed UHD's own build to stop
requiring `Boost::system`, in response to it being dropped as of Boost
1.89. That commit did not touch `UHDConfig.cmake.in`, which had only
just gained its own separate `Boost::system` reference ten days
earlier via ab724a30ec, and so was
missed.
- `v4.10.0.0` ships with both commits, making it the first release where
`UHDConfig.cmake.in`'s Boost dependency check exists but still lists
`system`, breaking `find_package(UHD)` for any consumer linked against
Boost >= 1.89.
[1]: 7a495bb46d
This fixes the segfault when calling into set_*x_antenna() within the
example extension and updates the C++ version to UHD default (20 at the
moment) to be able to build again.
The segfault was caused by the extension example never initializing the
pointers to _*x_antenna. It still doesn't do that but refers to the
radio's setter and getter methods now.
This adds a unit test for the spi_core_4000 which checks for the
validation of configurations and arguments and verifies the correct
registers are written during a SPI transaction.
On modern compilers, this file could cause a warning such as:
warning: ‘void operator delete(void*, std::size_t)’ called on pointer
‘<unknown>’ with nonzero offset [8, 9223372036854775800]
[-Wfree-nonheap-object]
A minor refactoring avoids the warning, even though it was unlikely
a real issue in the first place.
Previously it would round up the requested size to the nearest power of
two. Now it will attempt to match the size of the buffer to the
requested size, allowing more control over how many FPGA RAM resources
get consumed.
This change updates the RFNoC specification to increase the SeqNum
field from 6 bits to 8 bits. This helps reduce control packet response
sequence number aliasing in cases where packets may be dropped or
reordered. To make this change while keeping the implementation
efficient, the control packet fields have been rearranged to place the
most critical information first and to avoid splitting fields across
word boundaries.
Additionally, compared to the previous version of the specification (as
of UHD 4.10), a new ReqSize field has been added. This field represents
the read request size.
The DataLength field that briefly existed in the change history has
been removed. In the new version, NumData represents the number of data
words present in the control packet (the same meaning as in the
original RFNoC specification), while ReqSize indicates the number of
words requested to be read. This means that a large read request can be
issued without including dummy data in the request (e.g., ReqSize = 15
while NumData = 0).
See separate commits for the corresponding FPGA and host code changes.
