| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Add support for the new "priority" and "multi_streamer" benchmark_rate
args to run_benchmark_rate.py to enable batch runs of benchmark_rate
using those arguments.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
| |
|
|
|
|
|
|
|
|
| |
In order to perform certain operations (start/stop/step), meta_range_t
objects must be "monotonic", meaning that the subranges composing it
are sorted and non-overlapping. This commit creates a method which
takes a non-monotonic meta_range_t containing no non-continuous
subranges and converts it into a monotonic meta_range_t.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Boost versions prior to 1.68 appear to have a bug where a decorator to
denote a test as disabled is not honored when affixed to a data-driven
test case, which is how the benchmarks in convert_test are skipped when
the unit test is run. (The tests take some time to complete and we don't
want them running with every CI pass.)
This commit adds an alternative benchmark skipping mechanism when Boost
<1.68 is used. The benchmark test cases perform a runtime check for the
user-provided `--benchmark` command-line option. If not found, the test
case returns prematurely. If found, the test case will execute. Note
that because `--benchmark` is a command-line option specific to this
test, and not to Boost, the options must follow `--` in the command
line in order to take effect: `convert_test -- --benchmark`.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is useful for unit testing certain code which operates the DDR
registers, in particular code which performs a read-modify-write
operation on that register.
Conceivably we could add more registers here, but I'm just doing one
at a time.
|
|
|
|
|
| |
This commit adds test cases to convert_test to specifically test the
saturating behavior of the fc32/fc64-to-sc16 conversions.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds Boost test cases for benchmarking each of the existing
conversions that are tested in convert_test. The benchmarks do take some
time, and we do not want to run they as part of every CI run, so they
are marked with a test decorator that disables the benchmark by default.
To run the benchmarks, invoke convert_test with `--run-test=+benchmark*`
to explicitly enable all disabled tests that begin with the word
'benchmark'. Individual benchmark test cases can be enabled by
specifying the full name of the benchmark test or by crafting a wildcard
that includes all benchmark test cases of interest.
|
|
|
|
|
| |
This commit adds code to the convert tests to support the ability to
benchmark individual conversion test cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements some minor cleanup of various converter- and
convert test-related code:
* Improves the log messages regarding which converter was returned for a
request.
* Modifies the result checking code in the converter tests to only
report an out-of-range sample error once, rather than reporting every
out-of-range sample encountered during the test. This vastly cuts down
on the output when a conversion has failed.
* Adds a function `reverse_converter()` which, given a
`convert::id_type` describing a conversion from C1 to C2, returns a
`convert::id_type` describing the reverse conversion (C2 to C1).
* Removes two redundant test cases from the converter test.
|
|
|
|
|
| |
* A uhd_test.so lacks the necessary symbols for testing
due to default visibility set to hidden.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throughout UHD, we often do floating-point comparisons for frequency
ranges that require resilience to floating point rounding errors. Most
of the time the checks look like this:
```cpp
if (fp_compare_epsilon<double>(freq) > boundary) {
// ...
}
```
The exception is the N320 daughterboard control, which uses a custom
epsilon:
```cpp
if (fp_compare_epsilon<double>(freq,
RHODIUM_FREQ_COMPARE_EPSILON) > boundary) {
// ...
}
```
This was, for the most part, not by design, but because authors simply
didn't think about which epsilon value was appropriate for the frequency
comparison. This was complicated by the fact that fp_compare_epsilon
previously had some issues.
This patch introduces FREQ_COMPARE_EPSILON, which is a sensible default
value for fp_compare_epsilon when doing frequency comparisons (note that
fp_compare_delta already had such a value).
Also, it introduces freq_compare_epsilon(x), which is a shorthand for
fp_compare_epsilon<double>(x, FREQ_COMPARE_EPSILON).
We then replace all occurrences of fp_compare_epsilon<double> which are
specific to frequency checks with freq_compare_epsilon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UHD had an issue where the design of fp_compare_epsilon and its usage
differed. In fact, the *only* usage of fp_compare_epsilon outside of
unit tests was to do a fuzzy frequency comparison, and it always took
a form like this:
```cpp
// The argument EPSILON may be implied, i.e., using the default
if (fp_compare_epsilon<double>(test_freq, EPSILON) < boundary_freq) {
// ...
}
```
However, the API of fp_compare_epsilon was such that it would apply
DOUBLE_PRECISION_EPSILON to part of the frequency comparison, thus
rendering the argument EPSILON obsolete. When the default EPSILON was
used, this was OK, but only when the floating point type of
fp_compare_epsilon<> was `double`, and not `float`.
As an example, consider the following:
```
if (fp_compare_epsilon<double>(1e9 + x, LITTLE_EPSILON) == 1e9) {
// ....
}
double BIG_EPSILON = x * 10;
if (fp_compare_epsilon<double>(1e9 + x, BIG_EPSILON) == 1e9) {
// ....
}
```
If you expect the second comparison to pass even if the first failed,
then you are not alone. However, that's not what UHD would do. Because
of the aforementioned behaviour, it would use DOUBLE_PRECISION_EPSILON
for the right hand comparison, which would fail again.
Instead of fixing the instances of fp_compare_epsilon throughout UHD,
this patch changes the comparison algorithm from "very close with
tolerance epsilon" to "close enough with tolerance epsilon". This
requires only one side to be close to the other, using its own epsilon,
so the aforementioned example would always pass on the second check.
However, this exposed a second bug in fp_compare_epsilon. For
greater-/less-than comparisons, it would use epsilon like a delta value,
i.e., it would check if
a + epsilon < b - epsilon
That means that if a < b, but (b-a) < 2*epsilon, this check would return
"false", i.e., it would report that a >= b, which is incorrect. These
operators are now changed such that they first check equality of a and
b using the algorithm described in the code, and then compare the values
of a and b (ignoring epsilon) directly. A unit test for this case was
added.
|
|
|
|
|
| |
This allows viewing or, conceivably, customizing the tuning table that
ZBX uses, depending on the particular needs of the end user.
|
|
|
|
|
| |
Move x4xx_radio_mock_reg_iface_t and x400_radio_fixture from radio
block test into own file to reuse it more easily in the future.
|
| |
|
|
|
|
|
|
|
|
| |
This commit disables x4xx_radio_block_test on macOS
because the platform has stricter casting and symbol
export rules, which causes this test to fail.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
| |
Add SPI Core host implementation for x410 and a discoverable
feature to make it accessible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An RFNoC block (like the radio) might require a minimal number of
items in each clock cycle, e.g. the radio has to process
SPC (samples per cycle). Because data in RFNoC is transmitted and
processed in packets, we have to make sure the items inside these
packets are a multiple of the items processed in each cycle.
This commit adds an atomic item size properties which is set by
the radio and adapted by the streamers. The streamers adapt the
SPP property of the radio block controller depending on the MTU
value. This might lead to an SPP value which does not align with
the SPC value of the radio block, hence we add a property resolver
for the atomic item size.
|
| |
|
| |
|
|
|
|
|
| |
The path it returned was only valid in UHD 3. Added unit test to
confirm.
|
|
|
|
|
|
|
|
|
| |
This tests the following graph: DDC -> Replay -> DDC, where the initial
and final blocks are the same (i.e., a loop). This could be useful for
generating and capturing data with the same replay block while testing
a block.
Note that this test will fail if the edge consistency checks are buggy.
|
|
|
|
|
| |
When using ENABLE_X400=OFF, we should also disable the corresponding
tests, or we get linker errors.
|
| |
|
|
|
|
| |
Support DPDK versions 19.11 and 20.11
|
|
|
|
|
| |
On newer versions of Boost, they show deprecation notes. However,
they're not actually used any more so they can go.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two values where being mixed up in the code. To summarize:
- The MTU is the max CHDR packet size, including header & timestamp.
- The max payload is the total number of bytes regular payload plus
metadata that can be fit into into a CHDR packet. It is strictly
smaller than the MTU. For example, for 64-bit CHDR widths, if
a timestamp is desired, the max payload is 16 bytes smaller than
the MTU.
The other issue was that we were using a magic constant (DEFAULT_SPP)
which was causing conflicts with MTUs and max payloads.
This constant was harmful in multiple ways:
- The explanatory comment was incorrect (it stated it would cap packets
to 1500 bytes, which it didn't)
- It imposed random, hardcoded values that interfered with an 'spp
discovery', i.e., the ability to derive a good spp value from MTUs
- The current value capped packet sizes to 8000 bytes CHDR packets, even
when we wanted to use bigger ones
This patch changes the following:
- noc_block_base now has improved docs for MTU, and additional APIs
(get_max_payload_size(), get_chdr_hdr_len()) which return the
current payload size given MTU and CHDR width, and the CHDR header
length.
- The internally used graph nodes for TX and RX streamers also get
equipped with the same new two API calls.
- The radio, siggen, and replay block all where doing different
calculations for their spp/ipp values. Now, they all use the max
payload value to calculate spp/ipp. Unit tests where adapted
accordingly. Usage of DEFAULT_SPP was removed.
- The replay block used a hardcoded 16 bytes for header lengths, which
was replaced by get_chdr_hdr_len()
- The TX and RX streamers where discarding the MTU value and using the
max payload size as the MTU, which then propagated throughout the
graph. Now, both values are stored and can be used where appropriate.
|
| |
|
|
|
|
|
|
|
|
|
| |
This script is intended to be run before streaming.
- Manages network interfaces, memory buffers, and other
aspects of the system configuration to give the host machine
ideal performance during streaming.
- Installs/updates dpdk/util dependencies for the script
- Generates and writes uhd config files for dpdk
|
| |
|
|
|
|
|
|
|
| |
This provides every block controller with a copy of its CHDR width.
Note: mock blocks always get configured with a 64-bit CHDR width, to
retain API compatibility.
|
|
|
|
| |
Thanks to Github user johnwstanford for pointing this out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the GPIO API for X410 through get_gpio_attr and
set_gpio_attr. In ATR mode, which channel's ATR state is chosen by the
set_gpio_src call, setting e.g. DB0_RF0 for channel 0 or DB0_RF1 for
channel 1. In manual mode, all 24 bits (for both ports) are set in
a single register write.
Although the front panel of the device has two ports, labelled GPIO0 and
GPIO1, this API exposes them as though they were a single 24-bit GPIO
port.
|
| |
|
|
|
|
| |
Thanks to mait for the fix!
|
|
|
|
|
|
|
|
|
| |
In multiple places in the UHD code, we were doing the same calculation
for a wrapped frequency (wrap it into the first Nyquist zone). This math
was using boost::math, too. Instead of editing every instance, we create
a new function, uhd::math::wrap_frequency(), and replace all of its
separate implementations with this function. The new function also no
longer relies on boost::math::sign.
|
|
|
|
|
| |
We've been having issues with moving locations of Boost headers for this
function, and it's simple enough to implement ourselves.
|
| |
|
| |
|
|
|
|
|
|
|
| |
At this point, this test chokes an RX streamer to force an overrun. It
then confirms that the overrun message is returned to the call site, and
that the streamer returns to continuous streaming after the overrun
handling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, both the set_tx_antenna_switches and set_rx_antenna_switches functions
configure the TX0_ANT_11 register (which controls the final switch before
the TX/RX port, switching it between the three TX paths and the RX path).
The RX antenna configuration code will, if the RX antenna is set to TX/RX,
configure that switch to the TX/RX->RX path when the ATR is set to RX.
However, the TX antenna config code will always configure that switch to
the "bypass" path, for both the 0X and RX ATR modes, regardless of whether
the RX side actually needs that path.
Ergo, this change makes set_tx_antenna_switches only configure that
switch when it is configuring the XX or TX modes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the CMake 3.8 documentation on these two variables:
https://cmake.org/cmake/help/v3.8/variable/PROJECT-NAME_SOURCE_DIR.html
https://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.
|
|
|
|
|
|
|
|
| |
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.
|