When using the multi_streamer option, the streams would start at
different times, which can cause problems if IP processes multiple
channels in parallel. This change ensures that the all channels start
at the same time, even if they're in different threads.
This adds support to the FFT block controller for the NIPC parameter.
Changing the NIPC parameter in the FPGA build allows the resulting
FFT block to process multiple items/samples per clock cycle, which
leads to higher throughput. As of compat version 3.1, the NIPC value
may be greater than 1 and must be a power of 2. The packet size and
cyclic prefix lengths used must also be a multiple of this NIPC
value.
Adds support to the FFT block for configuring the following at
compile time:
NIPC - Number of items/samples per clock cycle
EN_CP_INSERTION - Enable/disable cyclic prefix insertion support
EN_CP_REMOVAL - Enable/disable cyclic prefix removal support
This adds the NIPC parameter, which configures support for processing
multiple items or samples per clock cycle. With this enabled, the FFT
block can process at rates higher than 250 MSPS, such as 500 MSPS and
beyond.
Packages may use the build type to decide whether to look for
release or debug binaries. It is therefore cruicial to set the
build type before searching any package.
Install the toml file for Windows only, otherwise pip installs into
venv with Python versions between min (3.7) and 3.10 (what the toml
requests), which will fail.
doc: Update usrp_x4xx.dox with table for supported sample rate examples and links to KB and X440 Spec.
Co-Authored-By: Aki Tomita <121511582+atomita-ni@users.noreply.github.com>
The Python examples are only included in the installer, if Python
is enabled during build. Therefore use the NSIS installer from the
Python enabled build. This makes it unnecessary to distinguish
Python/non-Python pipeline build which speeds up pipeline runs.
On the downside Python examples are installed no matter whether
they are needed or not.
... in case the configuration ENABLE_PYMOD_UTILS was not set.
This corrects the default images directory for
uhd_images_downloader on the embedded filesystem.
This warning turned out to be scientifically inaccurate. The actual
auto-coercion of the spp value to the CHDR width is left in place, as it
improves streaming under certain conditions, but we no longer warn if
a user-selected spp value is not aligned with the CHDR width.
Unless the user specifies an spp value in a Tx streamer by means of
a stream argument, the Tx streamer now holds additional logic that
aligns the spp value with the CHDR width. For example, in an X410 100
GbE image, the CHDR width is typically 512 bits, which corresponds to 16
samples (sc16), so spp will default to value that's a multiple of 16.
Previously, the default was to simply use the maximum MTU. However,
there have been circumstances observed where using a non-aligned spp
value causes suboptimal behaviour.
For example, when the CHDR width is 512 bits, and the discovered MTU is
8016 bytes, the default spp value would be 1988 samples per packet.
However, a value of 1984 samples per packet causes the CHDR packet to be
of a length that is a multiple of 64 bytes (== 512 bits) which can
improve performance.
This change does not affect applications where the spp size is already
manually configured, and has almost no influence on use cases where the
CHDR width is 64, because that just means the optimal number of samples
per packet should be even.
Under the hood, the following changes were made:
- The CHDR width is passed into the streamer as a reserved key
(__chdr_width) from the infrastructure.
- After connecting the Tx streamer to the graph, when the MTU is known,
we add a check for the spp value to make it an integer multiple of the
CHDR width if not specifically given (like a "soft atomic item size").
Co-authored-by: Jörg Hofrichter <joerg.hofrichter@emerson.com>
This allows querying the CHDR width for a given device in an RFNoC
graph. The mb_index parameter is mostly for future proofing, given that
the CHDR width must be constant between devices.
Previously, the value from --tx_spp was only used if --tx_spb was not
also provided (basically, it was a default for --tx_spb).
Now, the value from --tx_spp is used as a stream argument for the Tx
streamer. If both --tx_spp and --tx_spb are provided, then
benchmark_rate will split the full burst size (--tx_spb) into packets of
size --tx_spp. Previously, if both parameters were given, and --tx_spb
was bigger than --tx_spp, the actual packet size was determined by the
maximum packet size available at the interface or the --tx_spb value,
whichever was smaller.
This commit also aligns the usage of --tx_sample_align. Previously, it
was only implemented for the multi-streamer use case. Now it works the
same between the multi- and single-streamer use cases, and the
diagnostic output now shows SPP and SPB values for both. If both
--tx_spb and --tx_sample_align are given, we potentially have a conflict,
which the tool now warns about.
When using --random, --tx_sample_align now also applies to all burst
sizes.
