| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This constant was generally harmful, since it was only correct under
certain circumstances (64 bit CHDR with timestamps). The X3x0 code was
the last place it was being used, and we remove it without substitute
because it was not doing anything useful here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The replay block is more like the radio block than like a FIFO. In
particular, consider this flow graph:
Replay -> DDC -> Replay
Imagine you're using the replay block to test the DDC block with
prerecorded data. If we treated the Replay Block like a FIFO, then we'd
have a loop in the graph (which is already wrong). If we used the DDC to
resample, then the input- and output sample rate of the Replay mismatch,
which is a legal way to use the Replay block, but not possible if we
treat the graph like a loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This example had some major issues since UHD 4, which are now fixed.
Mainly, the option to include a custom RFNoC block was not working.
The example was rehauled severely:
- Custom blocks are now usable again.
- UHD/RFNoC code is used for the connections, rather than a custom
kludge.
- Sample rate is set via property propagation
- boost::format() was not helpful in this example, and was removed.
- A list of active connections is now printed
- The --block-args argument is dropped in favour of --block-props. The
former never did anything useful, and "block args" are a UHD 3 thing.
|
|
|
|
|
| |
This adds some more explanatory comments around active and static
connections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When connect_through_blocks() was called on blocks within a single
chain, there was a bug where the chain was incorrectly cropped. In
a standard FPGA image, say one was to use this API call to connect the
radio to the DDC. It would generate a chain of blocks hanging off the
radio as such:
Radio -> DDC -> SEP
What the code should do, and what this fix provides, is that the chain
gets cropped after the DDC, to look like this:
Radio -> DDC
With the current bug, it would assume the chain has a dangling edge, and
incorrectly throw an exception.
Note that this bug would not appear when source and destination block
are on separate chains (i.e., both have an SEP in their chain).
This patch includes minor logging and comment improvements around the
offending lines of code.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The async message handler and the async message validator would
erroneously compare channel numbers for RX async messages with the
number of valid TX channels. On TwinRX, where there are zero TX
channels, this would always fail. Elsewhere in the code, the comparisons
for TX and RX channels mixed up input and output ports.
The second issue is that the comparison made was a "greater than" rather
than "greater or equal".
The effect of these two bugs was that potentially, we could have
accepted async messages for an invalid port N, where N is the number of
valid ports of this block, and that for TwinRX/X300 users, async
messages on channel 1 would not get accepted (they would, however, get
accepted for channel 0 because of the second issue). This includes
overrun handling, which was broken for channel 1 and 3 on an X300.
Another effect of the bug was that EPIDs for async messages weren't
always programmed correctly.
|
|
|
|
|
|
|
| |
Getting the time from the mb_controller is slow, so try to get the time
from the Radio on the fast path first.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
| |
Add API calls to Radio control to get ticks and time.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
| |
- Remove documentation of skip_dram, skip_ddc, skip_duc, which are all
obsolete since UHD 4
- Properly document serialize_init
- Add a table of valid args for X310 as with other devices
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The order must:
- Check transaction has the right number of hops, then read hop
- Check hop has the right number of operations (at least 2), then read
those ops
- Check the ops have the correct opcodes
The code was doing checks in the wrong order. Thanks to Github user
johnwstanford for pointing this out.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
This allows consumers of UHD compiling with C++11 to include this file
(which is now included via noc_block_base) by turning a switch statement
into a functionally equivalent (albeit less readable) nested ternary
statement.
|
|
|
|
| |
Thanks to Github user johnwstanford for pointing this out.
|
|
|
|
|
|
|
|
|
|
| |
The times on the device can glitch if either the tick rate changes or
the number of active chains changes. This throws off the time if the
user gets streamers, changes the sample rate, or changes the tick rate
after synchronizing the time. This change re-synchronizes the times
automatically in those cases.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This gets closer to what our hardware can actually support. See the
comments for further explanations.
This has the side-effect of patching an issue on X410 (using 200 MHz
images) where garbage samples would get injected (one per packet). It
is not, however, the final fix for that problem.
|
| |
|
|
|
|
|
|
| |
This lets Doxygen create a page in the UHD manual that lists all RFNoC
block controllers. It will be accessible under Manual -> Modules ->
RFNoC -> RFNoC Blocks shipped with UHD.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
"bank" refers to what the radio control sees, and "port" refers to what
the user looking at the physical device sees. For example, on X410 each
radio control only has a single (24-bit) output, which can be routed
to either of two ports.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes some constants from UHD that were left over from RFNoC/UHD
3.x. They are unused.
rfnoc_rx_to_file had a commented-out section that was also UHD-3 only.
Note that rfnoc/constants.hpp is pretty bare now, and could be removed.
However, it is in the public header section, so we shall leave the used
constants where they are.
This requires fixing includes in mgmt_portal.cpp.
|
|
|
|
|
|
| |
Aligning dependencies between KB entries and documentation for
Ubuntu 20.04 and bumping version numbers in the installation
documentation to latest available versions in Ubuntu and PPA.
|
| |
|
|
|
|
|
|
|
| |
Refactors register addresses into a gpio_atr_offsets structure which
contains the various register addresses. This allows creating other
devices with different GPIO register layouts with greater ease, and
eliminates the use of macros (yay!)
|
|
|
|
|
|
|
|
|
| |
The I and Q were swapped in sine_tone, which caused confusion and made
the rotation of REG_CARTESIAN clockwise by default. This effectively
made the resulting frequency negative. This PR makes the I and Q order
consistent with RFNoC and fixes the direction of rotation so that a
positive value for REG_PHASE_INC (phase increment) results in a
counter-clockwise rotation, which yields a positive frequency.
|
|
|
|
| |
Thanks to mait for the fix!
|
|
|
|
|
|
|
| |
This is necessary when compiling with -Werror=format-security as Debian
package builds do.
Thanks to mait for the fix!
|
|
|
|
|
|
|
| |
C++ syntax cleanup. g++ 11 is now more picky about syntax, and flags
errors rather than ignores use of template-id for a destructor.
Thanks to mait for these fixes!
|
|
|
|
| |
Thanks to Mait for pointing these out!
|
|
|
|
|
|
| |
This adds a section on GPIO bank names to multi_usrp.hpp, and clarifies
the difference between the multi_usrp and RFNoC APIs regarding GPIO
control.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Replaced by std::numeric_limits<>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very mechanical task that could almost have been done with
sed. Boost versions of mutexes and locks were removed, and replaced with
std:: versions. The replacement tables are as follows:
== Mutexes ==
- boost::mutex -> std::mutex
- boost::recursive_mutex -> std::recursive_mutex
Mutexes behave identically between Boost and std:: and have the same
API.
== Locks ==
C++11 has only two types of lock that we use/need in UHD:
- std::lock_guard: Identical to boost::lock_guard
- std::unique_lock: Identical to boost::unique_lock
Boost also has boost::mutex::scoped_lock, which is a typedef for
boost::unique_lock<>. However, we often have used scoped_lock where we
meant to use lock_guard<>. The name is a bit misleading, "scoped lock"
sounding a bit like an RAII mechanism. Therefore, some previous
boost::mutex::scoped_lock are now std::lock_guard<>.
std::unique_lock is required when doing more than RAII locking (i.e.,
unlocking, relocking, usage with condition variables, etc.).
== Condition Variables ==
Condition variables were out of the scope of this lock/mutex change, but
in UHD, we inconsistently use boost::condition vs.
boost::condition_variable. The former is a templated version of the
latter, and thus works fine with std::mutex'es. Therefore, some
boost::condition_variable where changed to boost::condition.
All locks and mutexes use `#include <mutex>`. The corresponding Boost
includes were removed. In some cases, this exposed issues with implicit
Boost includes elsewhere. The missing explicit includes were added.
|