This fixes the behavior that a non-valid dual-rate config could fall
back to a single-rate configuration with two different converter rates.
With this it also fixes the behavior that with those same master clock
rates we wouldn't run mult-tile sync (as this depends on the converter
rate).
Added 'module_serial' field to retured value of
multi_usrp::get_usrp_rx_info() and multi_usrp::get_usrp_tx_info() API
calls that provides the module serial number.
Signed-off-by: michael-west <michael.west@ettus.com>
Only the make_x4xx target existed and did not actually run any tests.
Added correct mapping for make_x410 and make_x440 devtest targets.
Removed make_x4xx target.
Signed-off-by: michael-west <michael.west@ettus.com>
This example demonstrates the simultaneous capture of the entire L-band
which extends from 1 GHz to 2.4 GHz using one channel on each of the two
radios using the dual rate feature. This is supported ionly on the X440 device.
Read the comments in the example for details.
Does the following:
- Sets up connections in rfnoc graph
- Configures radios and dual replay blocks
- Synchronously captures data and streams to replay block
- Fetches data to host and plots a windowed FFT.
- Repeat.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Martin Anderseck <martin.anderseck@ni.com>
This updates the block registry for x400_radio_control to query the
clock information from the FPGA/MPM. This will require an up-to-date
bitfile and MPM.
If the bitfile is not up-to-date, there will be an error message asking
the user to update the bitfile. If MPM is not up to date, it will fail
to detect clock indices '4' and '5'.
Since in dual rate we cannot use multi-tile sync over all tiles we
disable it completely for all tiles. For 1600 MHz bitfiles this isn't an
issue at all because the two remaining channels have different converter
rates anyway. For 400 MHz bitfiles the channels with the same rate will
not be synced, either, but will most probably have a fixed phase
difference.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
This updates the RFNoC image cores to separate the two DRAM banks on
X4xx by splitting them into "dram0" and "dram1". Previously, both DRAM
banks shared the same DRAM port, named "dram", which created some
confusion.
The Replay block has also been duplicated in the bitstreams that use
both banks, so we now have one Replay block per bank.
- Update X410 and X440 BSP YAML files to properly index clocks
- Update image core files to declare clock indices
- Update get_clocks() in MPM to return the correct values
This does not include changes to the x400_radio_control block registry.
This change by itself will thus not change behaviour.
This change adds a lookup table for the default master clock rate based
on the DSP bandwidth of the FPGA image for X440. Since the default
master clock rate currently is 368.64 MHz and we don't want to change
this for backwards compatibility, we need to have a way to handle lower
bandwidth FPGA images. This is what the LUT provides.
During creation of the RFNoC graph, the block registry is queried to
identify the clocks used for timebase and control. This adds the option
to ask the FPGA instead (via backend interface).
This adds support for the X440_X4_200 variant which supports up to
200 MHz bandwidth (250 Msps), has a DDC and DUC on each channel,
4 x 10 GbE interfaces, and no DRAM.
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
- Image core files can now provide timebase_clock and ctrl_clock fields
to blocks, which will populate the backend interface accordingly.
- Clocks ports now have a direction associated (in, out).
When query_gpsdo_sensors creates a multi_usrp object with no additional device args,
it initializes the device using clock_source and time_source values of 'internal'.
Later, it sets them to 'gpsdo'. Since the x4xx devices put the GPSDO module in
reset when not being used, it takes several minutes to re-establish a GPS lock
after selecting the 'gpsdo' clock/time sources. By creating the multi_usrp object
using clock/time source values of 'gpsdo', the GPSDO isn't disabled and re-enabled
each run and the GPSDO is able to get a lock after enough time passes.
