This device argument can be used where the automatic MTU discovery fails,
e.g., because of a particularly restrictive network configuration. Note
that it should be used with care, because UHD will use this value for
Ethernet frame sizes, even if the underlying network connection does not
support them.
Also, for 1 GbE connections, the default MTU is always 1500 bytes,
regardless of the detected maximum MTU. This means that when attempting
to increase the MTU over a 1 GbE link, the recv_frame_size stream (or
device) argument also needs to be provided.
See the corresponding x300 commit for additional for information. This
enables the same feature for all MPM devices (X4xx, E3xx, N3xx).
Manual pages were also updated in this commit.
This device argument can be used where the automatic MTU discovery fails,
e.g., because of a particularly restrictive network configuration. Note
that it should be used with care, because UHD will use this value for
Ethernet frame sizes, even if the underlying network connection does not
support them.
If the desired goal is to override the MTU for a particular link, then
it may be more sensible to provide an `mtu` stream argument, or,
depending on the situation, a `recv_frame_size` or `send_frame_size`
stream argument instead. The main purpose of the `force_mtu` device
argument is to disable the automatic MTU discovery, and provide UHD with
a substitute value instead.
It may be used as follows:
```cpp
auto my_usrp =
uhd::usrp::multi_usrp("type=x300,addr=192.168.30.2,force_mtu=8000");
// UHD will now assume that 8000 is a valid MTU, without further checks
```
Note that it remains possible to configure the Ethernet frame sizes
using the `recv_frame_size` or `send_frame_size` arguments, but those
will not disable the MTU discovery:
```cpp
auto my_usrp =
uhd::usrp::multi_usrp(
"type=x300,addr=192.168.30.2,recv_frame_size=8000");
// Path MTU may be smaller than 8000 if the USRP is not able to handle
// this MTU size
```
When creating an RFNoC streamer (using rfnoc_graph::create_?x_stream(),
or when calling multi_usrp::get_?x_stream() on an RFNoC device), the
argument `mtu` is now interpreted by the RFNoC infrastructure. It allows
overriding the MTU for a given connection, regardless of what the
underlying link is using.
A good reason to use this is when doing remote streaming, and the path
MTU differs between the USRP and the UHD host computer, and the USRP and
the remote destination. UHD will default to the path MTU between the
host computer and the USRP, but that may be too small (e.g., when
controlling a USRP X410 over its RJ45 port, which typically has an MTU
of 1500, but doing remote streaming over 100 GbE, which typically has an
MTU of 8000 or above).
Depending on the link type used, it may be useful to use
`recv_frame_size` instead (or `send_frame_size`). However, `mtu` is
a true override that will ignore any link settings, whereas
`recv_frame_size`/`send_frame_size` are hints for the underlying link
setup, and may not be honoured.
Use this like any other stream argument:
```cpp
uhd::stream_args_t s_args("sc16", "sc16");
s_args.args = uhd::device_addr_t("mtu=8000");
auto streamer = my_rfnoc_graph->create_rx_streamer(1, s_args);
```
The relevant manual pages are also updated.
Add a new section to the changelog regarding changed bitfile
behavior, specifically regarding the crossbar changes between
radio and replay block connections of the x440_X4_400 bitfile.
Change the standard bitfile description in manual to reflect
changes in x440_X4_400 bitfile behaviour changes. Add comment
to x440_X4_400 config regarding how to revert changes.
rfnoc: add test_radio_control_complex_gain.py
rfnoc: block tests: test_timed_complex_gain function
- The time corresponding to a random sample is computed and
passed as the timestamp to the set_gain_coeff method
rfnoc: Documentation for timed operation of set_gain_coeff
lib: cores: Add complex_gain_3000 core
- This core can control complex gain settings.
rfnoc: Add discoverable feature - complex gain
- New discoverable feature for RX and TX complex gain. Allows
configuring phase and amplitude of any radio channel.
python: Add tx_/rx_complex_gain functions to radio_control
Co-authored-by: Meghana Halladamath <meghana.halladamath@emerson.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Jörg Hofrichter <joerg.hofrichter@emerson.com>
Add TX/RX timed complex gain to radio core.
Update testbench for complex gain functionality.
In order to make room for the new complex gain registers,
the radio core register address space was extended.
The address space has changed in the following way:
- per port address space extended from 7bit(128 bytes) to
10bit(1024 bytes) port register address space.
- split the new port register address space in the following
subsections into the following subsections:
- 0x000 - 0x0FF General Radio Registers
- 0x100 - 0x1FF RX Core Control Registers
- 0x200 - 0x2FF TX Core Control Registers
- 0x300 - 0x3FF Feature Control registers
The existing registers have been moved to their corresponding locations
within the new register space.
Within the newly added feature register space,
the new complex gain registers were added.
- In most cases, the replacements are straightforward:
boost::filesystem::* can be often simply replaced by
std::filesystem::*, and the include path is changed from
<boost/filesystem.hpp> to <filesystem>
- boost::filesystem::system_complete() is replaced with
std::filesystem::absolute().
- Note: For users including uhd/utils/paths.hpp, this is an API change
because the return value of get_module_paths() is now a vector of
std::filesystem::path.
- In rx_samples_to_file and fx2_init_eeprom, we keep Boost.Filesystem
for now because there is no direct equivalent to
boost::filesystem::unique_path(), but the main goal is to remove
libboost_filesystem as a link dependency from libuhd.
When creating a UDP link, the function calculate_udp_link_params()
merges stream args, device args, and default values to create a sensible
stream configuration object, which describes the size of send/recv
frames, their number, and some other values.
This function also takes in a send and recv MTU as a cap. However, it
was possible to override the MTU values with stream arguments. It was
not possible to override the MTU values with device arguments, however.
This commit makes the handling of device arguments and stream arguments
consistent. Consider the following snippets:
```cpp
// auto-detects MTU of 1500:
auto my_usrp = uhd::usrp::multi_usrp("recv_frame_size=8000");
uhd::stream_args_t s_args("sc16", "sc16");
auto streamer = my_usrp->get_rx_stream();
// streamer now has frame size of 1500, because the autodetected MTU
// overrides the device argument frame size
```
```cpp
// auto-detects MTU of 1500:
auto my_usrp = uhd::usrp::multi_usrp("");
uhd::stream_args_t s_args("sc16", "sc16");
s_args.args["recv_frame_size"] = "8000";
auto streamer = my_usrp->get_rx_stream();
// Previously, streamer would have a frame size of 8000, because the
// stream args override the autodetected MTU. With this patch, it has
// a frame size of 1500.
```
This allows the following:
```py
my_usrp.set_rx_subdev_spec("A:0 B:0")
```
Without this change, only the following was possible:
```py
my_usrp.set_rx_subdev_spec(uhd.usrp.SubdevSpec("A:0 B:0"))
```
Because the implicit-from-string version is possible in C++, we now also
enable it in Python.
- Move content from:
https://files.ettus.com/app_notes/RFNoC_Specification.pdf
into the RFNoC chapter in the UHD manual.
- Merge the "RFNoC Block Properties" section into the new
"RFNoC Software Specification" section.
- Replace the RFNoC software API documentation copy with links to
autogenerated API documentation in the UHD manual.
- Added program documentation string.
- Marked required options as required().
- Added short option strings for required options.
- Made individual option descriptions more descriptive.
- Harmonized naming of options where appropriate.
Introduced alias options for renamed options to keep
backward compatibility.
- Added program documentation string.
- Marked required options as required().
- Made individual option descriptions more descriptive.
- Harmonized naming of options: renamed ampl into wave-ampl.
- Added program documentation string.
- Marked required options as required().
- Added short option strings for required options.
- Made individual option descriptions more descriptive.
- Harmonized naming of options where appropriate.
Kept old option names as alias options not getting printed by --help.
This takes issue_stream_cmd() apart in a way that it can be used to
arm the trigger that waits for the TX, then return, so that the TX can
be issued. Afterwards the received data needs to be collected with the
wait_for_buffer_full() method. The default behavior when not using the
new trigger is unchanged.
Fixes an issue that was recently introduced with commit 2a77ec9,
which fixed the per attempt timeout of FPGA builds. Some of the
x440 FPGA builds can take longer than the default 6h timeout to
successfully compile. After the per attempt timeout bug was fixed
some of our most crowded FPGA targets were prematurely terminated,
significantly reducing compile success rate. This commit increases
the per attempt timeout from 6h to 9h.
While the Ctrl-only BFM doesn't necessarily have CHDR data, it can
still use the CHDR clock. This means we need to be able to control the
reset for that clock. Without this, blocks that use the rfnoc_chdr_clk
will hang in simulation.
The version check causes an error in Vivado that prevents the use of
JTAG/debug when users have a patch installed. This disables the error,
but it will still give a warning in case they really do have a
legitimate mismatch. This change fixes the issue when users use our
tooling to launch a build in the GUI then launch the hardware manager,
but it may still occur if they launch the GUI themselves outside of our
tooling.
- Added program documentation string.
- Marked required options as required().
- Added short option strings for required options.
- Made individual option descriptions more descriptive.
- Harmonized naming of options where appropriate.
