Note: template_lvbitx.{cpp,hpp} need to be excluded from the
list of files that clang-format gets applied against.
host/lib/dep is also excluded from this change.
This requires noc_shell compat number 6.0. It will allow sending as many
command packets, but no more, than there is space.
Updated FPGA images for devices:
- X310/X300
- N300/N310/N320
- E310/E320
We need to properly contraint the send/recv_frame_size based on the
minimum MTU of all the down/upstream blocks. This fixes the issue with
E310 tx/rx streaming as it has smaller MTU sizes than the other usrps.
- Store number of input and ouptput ports from block definition.
- Use number of input and ouptut ports for graph traversal rather
than number of connected blocks.
- Fixes DAC synchronization failure errors when using only one TX
channel on X300.
Signed-off-by: michael-west <michael.west@ettus.com>
- Factor out the _start_drain helper function, which starts flushing
data out of the block. We should always be disabling flow control after
we write to the flushing registers.
- Always attempt to flush when calling the _flush function. Previously,
we would check if data appeared to be moving when _flush was called,
and only write to the flush registers if data was moving. However, if
data is stuck for some reason (for example, the block ran out of flow
control credits), this check will give us a false positive, and we
won't flush. Instead, we need to always begin the flushing process,
then check those counters, and return once the counters stop changing.
Note: we need to start flushing before disabling flow control so that
the flushed data isn't flooded onto the crossbar.
Co-authored-by: michael-west <michael.west@ettus.com>
Co-authored-by: Sugandha Gupta <sugandha.gupta@ettus.com>
In the block controllers, set the default response SIDs for input and
output ports. If we don't do this, the blocks may send their responses
to other blocks' responses ports.
For example, without this change, the DDC may send an error packet to
port 0x0000, which is assigned to the DmaFIFO. With this change, the
DDC would send that packet to 0xFFFF, which isn't assigned to any other
block.
- UHD will now "disconnect" the noc_block data-path from
the crossbar when the block's dtor is invoked. This allows
long running or slow blocks to empty out rapidly during
teardown.
- UHD will also attempt to flush at init time in case a block
is destroyed abnormally. The goal of the flush mechanism is
to not lock up the FPGA
- noc_shell compat number is now 3
Updated the following blocks and components: Radio, DmaFIFO,
block_ctrl_base and node_ctrl_base, blockdef_xml_impl, device3_impl.
No functional changes.
- Demoted some log messages
- Consistent log style (use unique_id())
- Some adaptation of coding style where close to log statements
- ctrl_iface is now longer a wb_iface. All it can do now is send command
packets, and receive responses to those.
- ctrl_iface does not store command time or tick rate
- wb_iface_adapter is no longer a set of functors, but a wrapper around
ctrl_iface. Command times are stored once, in the block.
- DMA FIFO and radio block controllers have an easier time getting
access to a timed_wb_iface
To avoid the proliferation of additional include directories and
multiple ways of including project-local headers, we now default to
moving all headers that are used across UHD into the uhdlib/
subdirectory.
Some #include statements were also reordered as they were modified for
closer compliance with the coding guidelines.
Internal cpp source files should now include files like this:
#include <uhdlib/rfnoc/ctrl_iface.hpp>
Reviewed-by: Ashish Chaudhari <ashish.chaudhari@ettus.com>
This is only confusing, since the blocks do not have to care about
endianness. The control interface needs to know (and takes care of it
internally), and the streaming transport does the same (and does not
directly connect to blocks).
Reviewed-By: Michael West <michael.west@ettus.com>
- Also removes all references to boost/cstdint.hpp and replaces it with
stdint.h (The 'correct' replacement would be <cstdint>, but not all of our
compilers support that).
