See the CMake 3.8 documentation on these two variables:
https://cmake.org/cmake/help/v3.8/variable/PROJECT-NAME_SOURCE_DIR.htmlhttps://cmake.org/cmake/help/v3.8/variable/CMAKE_SOURCE_DIR.html
Under normal circumstances, these two are identical. For sub-projects
(i.e., when building UHD as part of something else that is also a CMake
project), only the former is useful. There is no discernible downside of
using UHD_SOURCE_DIR over CMAKE_SOURCE_DIR.
This was changed using sed:
$ sed -i "s/CMAKE_SOURCE_DIR/UHD_SOURCE_DIR/g" \
`ag -l CMAKE_SOURCE_DIR **/{CMakeLists.txt,*.cmake}`
$ sed -i "s/CMAKE_BINARY_DIR/UHD_BINARY_DIR/g" \
`ag -l CMAKE_BINARY_DIR **/{CMakeLists.txt,*.cmake}`
At the same time, we also replace the CMake variable UHD_HOST_ROOT (used
in MPM) with UHD_SOURCE_DIR. There's no reason to have two variables
with the same meaning and different names, but more importantly, this
means that UHD_SOURCE_DIR is defined even in those cases where MPM calls
into CMake files from UHD without any additional patches.
Shoutout to GitHub user marcobergamin for bringing this up.
Adds a --vivado-path option to rfnoc_image_builder that, if present,
gets passed to setupenv.sh for the target device. This can be used to
specify the location of Vivado if it is not installed in one of the
default search locations.
N320 doesn't have an automatic RX IQ balance correction, so that API is
removed.
The auto-DC offset correction was calling into the manual DC offset
correction code, which means auto-DC offset correction was never enabled
for N320.
This is more of an expressive change than a functional change; Python
seems to add this path to the PYTHONPATH anyway, at least for some
systems. We neverless make this change because:
- It's more explicit/expressive. When tests are run, the PYTHONPATH env
variable is printed, and it now contains this path where it should be,
right at the front. People reading the ctest/python.unittest output
now get told explicitly which path we mean.
- This guarantees that this path is added, even if Python/unittest
should behave differently on other systems or versions.
To clarify: When running unit tests, we want to run the Python code from
build/python, not the installed version. The latter may not yet exist,
and if it does, it's not the version we are editing.
This adds a Verilog definition named `UHD_FPGA_DIR that corresponds to
the location of the UHD "fpga" directory. This allows you to include
files in your out-of-tree modules relative to the FPGA directory. For
example, you could include the library header file rfnoc_chdr_utils.vh
using the following:
`include `"`UHD_FPGA_DIR/usrp3/lib/rfnoc/core/rfnoc_chdr_utils.vh`"
Some simulators may not support `" outside of the context of a `define,
in which case you can do the following:
`define RFNOC_CHDR_UTILS_PATH \
`"`UHD_FPGA_DIR/usrp3/lib/rfnoc/core/rfnoc_chdr_utils.vh`"
`include `RFNOC_CHDR_UTILS_PATH
Sometimes Vivado gets reopened too fast causing port in use errors.
This moves the device reboot wait into the redlock scope to give some
time for Vivado to close before the next agent tries to get the lock.
Signed-off-by: Steven Koo <steven.koo@ni.com>
The test_recv_get_release test should be checking received packets had
the same content as they did on send(), but was instead assigning to the
received buffer.
Shoutouts to GitHub user johnwstanford for pointing out the issue.
The previous commit fixed a bug in the DUC, where get_frequency_range()
reported incorrect values. The DDC did not have this bug, but we port
the updates to the unit tests and the documentation from the DUC to the
DDC for consistency's sake.
The tuning range of the DUC depends on the output sample rate (which is
larger), but it was using the input sample rate. This was causing a bug
where for Tx, the DSP tuning range was limited when using multi_usrp API,
and thus would not allow to DSP-tune beyond the current sampling rate.
In this patch, we also re-use the existing calculation of the sampling
rate, and harmonize that code between duc_block_control and
ddc_block_control.
Consider the following Python REPL code:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP('type=x300')
>>> U.set_rx_rate(10e6)
>>> U.set_tx_rate(10e6)
>>> # Creating a streaming is required, or the input rate will not be
>>> # set:
>>> S = U.get_tx_stream(uhd.usrp.StreamArgs("fc32", "sc16"))
>>> treq = uhd.types.TuneRequest(1e9)
>>> treq.rf_freq = 1e9
>>> treq.dsp_freq = 50e6
>>> treq.dsp_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> treq.rf_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> tres = U.set_rx_freq(treq, 0)
>>> print(str(tres))
Tune Result:
Target RF Freq: 1000.000000 (MHz)
Actual RF Freq: 1000.000000 (MHz)
Target DSP Freq: 50.000000 (MHz)
Actual DSP Freq: 5.000000 (MHz)
>>> # Note the last two lines: The *target* DSP freq was already clipped
>>> # to 5 MHz. These lines show 50.0 MHz when this patch is applied.
This bugfix is accompanied some related changes:
- The unit test is amended to verify the behaviour
- The API documentation is amended with details on its behaviour
This sets the ARCH and PART_ID environment variables so that the
selected part family is used for simulations by default. This can be
overridden by changing them in the Makefile for the testbench if a
testbench requires a specific part family. Prior to this change, the
default was always ARCH=kintex7, PART_ID=xc7k410t/ffg900/-2, which
required support for that part to be installed.
Some archs require linking against libatomic, others don't. We add some
CMake code that checks for libatomic.so requirement if:
- We are not on MSVC, AND
- Compiling std::atomics code would cause a linker error.
We then check for the existence of libatomic.so, and fail if we can't
find it.
The script was previously only Python 2 compatible.
Python 2 support is now removed, so we don't maintain backwards
compatibility with Python 2.
This also fixes all linter warnings.
In x300_eth_mgr.cpp the variable init is created but not initialized.
Only some of the variables within the struct are then set before init
is assigned to a different variable. Initialize the variable to
prevent unexpected values.
- Reduce PLL1 DLD lock count to 4,000 (0xFA0), or 100ms
- Change loop to check for lock every 10ms
Signed-off-by: michael-west <michael.west@ettus.com>
There currently isn't a way to access the motherboard register using MPM
(the ones defined in x4xx_global_regs). This commit adds a simple
interface to peek and poke them which is very similar to the current
interface for the daughter board registers.
Signed-off-by: Sam O'Brien <sam.obrien@ni.com>
Fix implicit typecasts that could potentially lose data. Doing this to
show that these typecasts are done on purpose (and to resolve warnings
from VS).
Fix the "Enum.3: Prefer class enums over "plain" enums" warning for the
node_type enum and update the calls to the enumerators as proposed by
the C++ Core Guidelines.
There were some rare corner cases where the EOB could get lost in the
DUC due to the dds_timed logic not always passing it through as it
should. This resulted in an underflow error message at the end of
transmission.
This commit also fixes an issue where part of the last packet
used a frequency shift of 0 instead of the requested frequency
shift, and an issue where the first few samples of a burst used the
wrong frequency shift value.
Part of the fix includes adding a TUSER port to dds_sin_cos_lut_only.
The TUSER port is built into the IP but was disabled. It is now
enabled and set to 1 bit wide. This has a very small effect on
resource usage and can be left unconnected when not needed.
The dds_freq_tune block was shared by the DUC and DDC. To avoid
affecting the DDC, a new version, dds_freq_tune_duc, is being
added for the DUC to use that has the necessary fixes.
The new dds_wrapper.v is a wrapper for the dds_sin_cos_lut_only IP.
This IP has the undesirable behavior that new inputs must be provided
to push previous outputs through the IP. This wrapper hides that
complexity by adding some logic to ensure all data gets pushed through
automatically. This logic uses the TUSER port on the IP.
Finally, a testbench for dds_timed was added.
PkgComplex adds functions for doing complex arithmetic in SystemVerilog
simulation.
PkgMath provides mathematical operations and constants that aren't
built into SystemVerilog, such as a constant for pi and the function
round().
PkgRandom adds randomization functions beyond what standard Verilog
supports but that don't require any special licenses or simulators.
This commit refactors the uhd pipeline to have a new installer stage.
This also adds Windows NSIS installers to pipelines.
Signed-off-by: Steven Koo <steven.koo@ni.com>
cmake has newer variables to identify specific Visual Studio version.
This change updates to use those. This also changes how images
files are globbed to be relative paths, which is useful if build files
are moved from machine to machine. This case is possible in Azure
Pipeline's CI.
Signed-off-by: Steven Koo <steven.koo@ni.com>
Fixed issue where variable tmp_file going out of scope could have
leaked the storage it points to. Replaced the declaration of tmp_file
by using a unique pointer with custom deleter that takes care of
closing the tmpfile when it is not needed anymore.
The calibration utilities attempt to bump the transmit thread priority to
realtime to prevent underruns. However, on platforms that use pthread,
`pthread_setschedparam()` typically requires elevated privileges. When
called without those privileges, the code path throws an exception that
is left unhandled, thus terminating the process with an unhelpful error
message.
This commit changes the thread priority function call to use a safe
version which catches any exceptions thrown by `pthread_setschedparam()`
and prints a much more instructive error message without terminating the
process. This gives the user a fighting chance to correct the issue and
successfully use the calibration utilities.
In days of yore, before we had evolved RFNoC to the UHD 4.0 state, only
one radio on N310 was able to drive the front-panel GPIOs. With the
introduction of the UHD 4.0 GPIO API, we have fine-grained control for
every pin who may drive it. This makes this constant obsolete, and we
remove it to avoid confusion. Besides, these two `constexpr` values
where being used nowhere.
White Rabbit is not supported in X410, however the register map included an
incorrect reference to this unsupported feature.
This commit removes the WR reference from both the source and html files.
By changing the type for accesses to noc_block_base calls in the Python
from sptr& to a simple reference (&), we fix the "holder type" issues
that crop up when trying to use radio_control from multi_usrp, which
returns access to the block as a reference rather than a `sptr`.
The error message seen without this fix always contains this string:
Unable to cast from non-held to held instance (T& to Holder<T>)
(The exact message depends on the API call made).
`std::abs` is only a templated function, when dealing with complex
numbers. For real values, it is an overload. There is no
documented standard way to use `std::abs<double>()` for real-valued
arguments. We therefore remove all usages of `std::abs<>()` and
replace them with `std::abs()` where they were taking a real-valued
argument.
This adds new variables which can be used to set a a URL to a custom
Boost archive. If provided, the pipeline will download the custom Boost
archive, unpack it, build it, and provide CMake flags for UHD before
starting the UHD build itself.
This allows semi-automatic testing of new Boost versions as they are
released.
This serves two purposes:
- This file no longer goes into the compiled DLL if B200 is disabled
- Discourage use of this file for new devices, making it clear that this
architecture is no longer used
The file itself is left untouched, only the class is renamed from
radio_ctrl_core_3000 to b200_radio_ctrl_core.
Note: In UHD 3, this file was also used by N230.
