`skip_property_propagation` was always a bad choice for a name, but
since 3930a615, it is completely wrong.
In the C++ API, there is no change in API or ABI, because the argument
name is not part of API/ABI, although the documentation strings were
modified.
In the Python API, the argument name and default value are also modified
to match the C++ API. Scripts using named arguments may have to be
modified to track this change.
When resolving properties, it is important to retain the order of
properties. In this patch, this is achieved by changing prop_ptrs_t from
being an unordered_set into a vector.
The biggest effect is that node_t::filter_props() now returns filtered
properties in the order they were added.
Resolving properties in the order they were added, and not in any random
order, is very helpful when designing property resolvers. For the MTU
property, however, it is almost always a requirement. That's because the
the MTU property is added first (via noc_block_base), but also, its
resolution already assumes execution of resolvers in a certain order
(see the long comment towards the end of
noc_block_base::noc_block_base()). Execution of resolvers in a certain
order can only be guaranteed if properties are also in a certain order.
A particular issue this resolves is the ability to have properties that
both depend on atomic_item_size and the MTU. Because blocks have no way
of reading the current MTU other than calling
`noc_block_base::get_mtu()`, resolvers requiring access to the MTU
assume that the MTU properties are always resolved first.
The majority of this patch revolves around syntactical differences
between std::vector and std::unordered_set, like using `push_back()`
instead of `insert()` for adding to `prop_ptrs_t`.
0cf8a60 introduces Python binding for the digital filter
classes. This does not compile under Windows because the
digital filter classes are header only classes but are
declared as UHD_API. They must be declared as UHD_API_HEADER.
See also 1b3ed20.
C++20 no longer allows redundant template parameter lists. The
template parameter list must be removed from the property_impl
constructor to allow C++20 projects to include UHD.
Signed-off-by: Clayton Smith <argilo@gmail.com>
- Add ability to get current record position.
- Add ability to get current play position.
- Track space in play command FIFO and throw uhd::op_failed error when
command requested would overflow the command FIFO.
Signed-off-by: michael-west <michael.west@ettus.com>
Clang provides the same macros as GCC, so if we're differentiating between these compilers then we need to get the compiler checking macros in the correct order
The block descriptions radio_1x64.yml and radio_2x64.yml are subsets
of radio.yml. Similarly, axi_ram_fifo_2x64.yml and
axi_ram_fifo_4x64.yml are subsets of axi_ram_fifo.yml. This commit
removes the redundant YAML descriptions in favor of the
parameterizable versions.
Update all USRPs to use the same names for the same port types.
For example, instead of "ctrl_port" and "ctrlport" use "ctrlport".
Instead "timekeeper" and "time_keeper", use "timekeeper". Etc.
- Add action handlers to the replay block to store TX and RX events.
- Adds two new APIs: get_{record,play}_async_metadata() to read back
async info.
- Add unit tests.
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.
- rfnoc_replay_samples_from_file still had UHD3-vestiges for selecting
block port and ID
- The documentation for stream_args_t also included block port and ID
examples
In the HDL, the parameter named 'MTU' is clog2 of the size of the
desired MTU. For example, when the 'MTU' parameter is 10, that means
the actual MTU setting is 2**MTU or 1024. So we need to set our
buffers to 2**MTU if we want them to be one MTU in size.
rfnoc::connect_through_blocks(), unlike rfnoc_graph::connect(), did not
have an argument to declare a back-edge. This patch remedies this
situation by adding a skip_property_propagation argument that works
exactly as with rfnoc_graph::connect().
This adds DRAM support to E31x devices. Due to the size of the DDR3
memory controller, it is not enabled by default. You can include the
memory controller IP in the build by adding the DRAM environment
variable to your build. For example:
DRAM=1 make E310_SG3
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 changes the return value of connect_through_blocks() from void to
a list of edges. If the connection can be made, then it will now return
the list of connections between the source block and port.
Previously, the default was DROP. For almost all RFNoC blocks, this is
not a good default. It is very easy to crash USRPs by not properly
propagating the MTU. For example, the following flow graph:
Radio -> DDC -> FIR -> Streamer
would crash an X310 when not manually setting an spp value. The reason
is: The Radio block has an output buffer of 8192 bytes, capable of
handling 2044 samples per packet. However, that's too big for the
Ethernet portion of the X310, which would cause the X310 to lose
connection between UHD and firmware. If the FIR were configured to
propagate MTU, the Host->USRP connection (which has an MTU of <= 8000)
would limit the MTU on all links, and the spp value would automatically
be reduced to 1996 (or less).
This commit uses the post_init() feature to check the user set an MTU in
the constructor, and sets it to the default if that didn't happen. This
doesn't solve all problems (the new default of ONE_TO_ONE) could also be
incorrect, but is a much more suitable default.
As a consequence, this has a minor change in how
set_mtu_forwarding_policy() can be used: It now must be called during
the constructor. Before, the rule was that it may only be called once,
but that could also have happened, e.g., during the first property
resolution. Now, the constructor is the last time block authors can
choose an MTU forwarding policy.
This method allows running a fixed set of rules to check the internal
consistency of a block. This may be necessary, because blocks authors
may incorrectly implement a certain design rule, and we want the ability
to not start an RFNoC graph with blocks that have rule violations which
we can write checks for.
uhd::dict gets typedefed into board_eeprom_t, which is used by applications
like uhd_usrp_probe, so this should be considered as part of the API.
fs_path is also an API, but because of MSVC build issues it
was not marked as so. Instead mark with UHD_API_HEADER.
Signed-off-by: Steven Koo <steven.koo@ni.com>
UHD_API sets the visibility for the symbols. Adding UHD_API fixes
casting issues seen on macOS. However this breaks Windows because
UHD_API sets __declspec(dllexport) and __declspec(dllimport) which
doesn't make sense for header/inline only definitions. This change
adds UHD_API_HEADER to denote entrypoints for this case. It sets
the visibility flags for Linux/Mac but does not set the
__declspec on Windows.
Signed-off-by: Steven Koo <steven.koo@ni.com>
Throughout UHD, we are using a random mix of __FUNCTION__, __func__,
__PRETTY_FUNCTION__, and BOOST_CURRENT_FUNCTION. Note that the first two
macros are non-standard (although many compilers understand them), and
the last requires Boost. __func__ is available since C++11, but is not
the best choice because the C++ standard doesn't require it to be of any
specific value.
We thus define UHD_FUNCTION and UHD_PRETTY_FUNCTION as portable macros.
The former simply contains the undecorated function name, the latter the
expanded function with full signature.
As it happens, our currently supported compilers didn't have any issues
using non-standard macros, so the main fix here is the removal of the
Boost macros and the harmonization of the other macros.
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.
