- Verify signature in case the device does not support customizable
FPGA (just as sanity check before actual loading the bitstream).
- Extract the bitstream from the bootgen generated .bin file
otherwise.
Provide the following two functions by wrapping the "bootgen"
command line tool:
verify: verify the validity of the signature of the .bin file.
extract_bitstream: extract the FPGA bitstream from the .bin file.
This works if the .bin file includes the FPGA bitstream as a
single partition.
- 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.
