| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the property propagation algorithm would first forward and
resolve properties only along forward edges. Then, we would check that
properties also align across back-edges. The assumption is that graphs
are always structured in a way such that back-edges would align when the
resolution is done.
However, for the following graph, this would fail:
Radio ---> Replay
^ |
+---------+
The reason is that the radio block and the replay block both have an
"atomic_item_size" property, which needs to be resolved both ways. If
the default atomic_item_size is 4 for the radio, and 8 for the replay
block, then the input atomic_item_size on the radio will never be
aligned with the output atomic_item_size of the replay block, and there
is no other mechanism to align those.
The solution is to run the edge property propagation and resolution
twice, first for the forward edges, then for the back-edges. For graphs
that would previously work, this makes no difference: The additional
step of propagation properties across the back-edges will not dirty any
properties. However, for graphs like the one above, it will provide an
additional resolution path for properties that are otherwise not
connected.
|
|
|
|
|
|
| |
The internal helper function graph_t::_forward_edge_props() receives
another argument, which decides if properties are forwarded on forward-
or back-edges. Previously, only forward-edges were possible.
|
|
|
|
|
|
|
|
|
|
|
| |
Enabled with the "tx_replay_buffer" device argument. Buffers TX data in
DRAM using the Replay block (version 1.1 or higher required), allowing
more buffering of data on the device. May reduce underruns for certain
applications. The Replay block is currently limited to 32 play
commands, so fewer calls to send() with larger buffers will perform
better than more calls with smaller buffers.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
| |
- Note on drawing power from the 3.3V rail
- Clarified purpose of Pins 2 and 4 (peripheral I2C bus)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Update dependencies
- Add python3-uhd package
- Add uhd-doc package
In part, this changeset is to further align with the official Debian
upstream at https://salsa.debian.org/bottoms/pkg-uhd.git, which is
maintained by Maitland Bottoms.
|
|
|
|
|
|
|
| |
Add auto DUT bitfile configuration.
Add special network configuration commands for X410.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
| |
|
|
|
|
|
|
|
| |
- Added command time to readback of time from Radio block.
- Added wait for time to readback of shared registers in Radio block.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
| |
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extends timed command support to all endpoints
addressable by the radio ctrlport interface.
Previously supported endpoints:
- Daughterboard GPIO interface
- RFDC timing control
Newly supported endpoints:
- DIO ATR control
- DIO SPI control
- DIO Source control
|
|
|
|
|
|
| |
Add support for reading the number of supported SPI slaves from
the device. This has become necessary because we may have bitfiles
with different capabilities and we want to report this back correctly.
|
|
|
|
|
| |
When running MPM as a simulator, none of the board-specific tools like
the BISTs, or usrp_update_fs need be installed.
|
|
|
|
|
|
|
|
|
| |
- Add ability to get current record position.
- Add ability to get current play position.
- Track space in play command FIFO and throw uhd::op_failed error when
command requested would overflow the command FIFO.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add registers to read current record and play positions.
- Add register to read current space in play command FIFO to allow
software to avoid overflowing the FIFO.
- Cache base address and size with play command in command FIFO.
- Fix timestamp logic. Timestamp is only for the first packet of a
burst. The increment of 1 for each sample is not accurate because
it assumed the Replay block was playing at the same rate as the
Radio, which cannot be assumed.
Maintained backwards compatibility with older API.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
For certain frequencies, the LMX2592 will sporadically fail to lock upon
the very first tune. When this happens, subsequent tunes (even to the same
frequency) do lock. This issue seems to be resolved by programming the FCAL
adjustment register fields (FCAL_LPFD_ADJ/FCAL_HPFD_ADJ) as described in
the LMX2592 datasheet. These fields adjust the FCAL calibration speed to
better accomodate PFD frequencies below 20MHz or above 100MHz.
This patch also fixes a few name typos in the register map that were
directly in the scope of this change.
|
|
|
|
|
|
| |
Log installed DPDK version on boot.
Signed-off-by: mattprost <matt.prost@ni.com>
|
|
|
|
|
|
|
|
| |
Substituting old values to restore API breakage from DPDK 18.11 to DPDK 19.
It is recommended at this point that users upgrade to more recent DPDK LTS
versions, but the DPDK 18.11 API is functional with UHD.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
| |
Clang provides the same macros as GCC, so if we're differentiating between these compilers then we need to get the compiler checking macros in the correct order
|
|
|
|
|
| |
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Wade Fife <wade.fife@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because this script deletes the entire contents of --buildpath, we no
longer provide '..' as the default. First, it is not a suitable default,
because it will contain the directory from which this script is called.
Second, if someone runs this script from a source repo for UHD, and this
repo is checked out into a non-empty directory, the script will still,
by default, delete all the contents from that directory.
Now, the script fails when not providing --buildpath. Note that CI code
is already using this command line argument.
|
| |
|
|
|
|
|
|
|
|
| |
The block descriptions radio_1x64.yml and radio_2x64.yml are subsets
of radio.yml. Similarly, axi_ram_fifo_2x64.yml and
axi_ram_fifo_4x64.yml are subsets of axi_ram_fifo.yml. This commit
removes the redundant YAML descriptions in favor of the
parameterizable versions.
|
|
|
|
|
|
| |
Update USRP RFNoC iamge core YAML files to use the more consistent
device port names. Clean up the formatting and make the files more
consistent.
|
| |
|
|
|
|
|
|
| |
Update all USRPs to use the same names for the same port types.
For example, instead of "ctrl_port" and "ctrlport" use "ctrlport".
Instead "timekeeper" and "time_keeper", use "timekeeper". Etc.
|
|
|
|
|
| |
This is an example that allows capturing RF data into DRAM, and then
stream it back to host, using the Python API.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable automated streaming tests to run on X410.
Disable tests on non-X410 devices for now.
Run only DPDK tests since the setup can not withstand
4Rx 4Tx and 4FDx in non-DPDK mode in manual testing.
And we need to enable running these tests for 100GbE testing.
Adjust streaming test thresholds to new values which seemed to work fine
in manual testing. Might make them tighter in future based on more data.
|
|
|
|
|
|
|
|
| |
Disable non 100GbE X410 tests for now since the test framework currently
assumes that the required bitfile(personality) is already loaded onto
the device. Re-enable these tests when the above support is added.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API calls get_{record,play}_async_metadata() calls are now
available in Python. To look more Pythonic, we change the call signature
and return value to either return `None` or the value (if available).
For comparison, this is the C++ code:
```cpp
uhd::rx_metadata_t md;
if (replay_ctrl->get_record_async_metadata(md, 0.1)) {
cout << "Received metadata! Error code: " << md.strerror() << endl;
} else {
cout << "No metadata received!" << endl;
}
```
In Python, this has the more Pythonic form:
```python
md = replay_ctrl.get_record_async_metadata(0.1);
if md is not None:
print("Received metadata! Error code: ", md.strerror())
else:
print("No metadata received!")
```
|
|
|
|
|
|
|
| |
- Add action handlers to the replay block to store TX and RX events.
- Adds two new APIs: get_{record,play}_async_metadata() to read back
async info.
- Add unit tests.
|
|
|
|
|
|
| |
- Allow mock radios to generate mock overruns/underruns
- Allow terminator blocks to inject arbitrary actions for testing
purposes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In f73e327, we modified PeriphManagerBase to explicitly list all
required methods as per the MPM/UHD API. This had an unintended side
effect: Because the clocking methods on x4xx are imported from
X4xxClockMgr, and not defined on x4xx itself, the method used to import
methods from X4xxClockMgr onto x4xx would refuse to re-define API calls
such as set_clock_source(), get_clock_source(), and so on.
The solution is to allow _add_public_methods() to overwrite existing
methods, which means we can overwrite abstract methods from
PeriphManagerBase in this fashion.
Without this patch, UHD sessions could fail in the following manner:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=x4xx")
>>> U.get_clock_source(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_clock_source(0)
RuntimeError: RuntimeError: Error during RPC call to `get_clock_source'.
Error message: get_clock_source() not available on this device!
|
| |
|
|
|
|
|
|
| |
This updates all RFNoC devices so that they get the RFNoC protocol
version and CHDR width in the same way, from the output generated by
the RFNoC image builder.
|
|
|
|
| |
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
| |
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
| |
- Clarify purpose of 'enclosure' flag
- Add section on clock and time sync, which the E31x section already has
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_sync_sources() was not implemented for E31x and E320. Because UHD
assumes this exists, calling this would cause an error like this:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=e3xx")
>>> U.get_sync_sources(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_sync_sources(0)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
'get_sync_sources'
|
|
|
|
|
|
|
|
|
|
| |
All PeriphManagerBase childs need to implement
- get_{clock,time,sync}_source()
- get_{clock,time,sync}_sources()
- set_{clock,time,sync}_source()
So we populate PeriphManagerBase with defaults for all of those.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the default clock/time source is whatever the user configured
in the last session.
This fixes the scenario were you have any MPM device and do this:
$ benchmark_rate --args $args,clock_source=external
But whoops! You forgot to attach an external 10 MHz. PLL lock fails,
nothing works. No worries, you run it again:
$ benchmark_rate --args $args
With the previous behaviour, this would retain the setting to
'external', because there's nothing to overwrite it. You would need to
append `clock_source=internal` to get a working device again. Calling
multi_usrp::set_clock_source("internal"), or a similar API call, might
not be sufficient because the PLL lock failure might crash the program
before updating the clock source is possible.
The problem with this is twofold:
- All non-MPM devices behave differently, i.e., they have a fixed
default ('internal') which is always applied if no other option is
given. This is an internal inconsistency.
- Some applications (like gr-uhd's GRC bindings) simply don't set
a clock/time source when selecting a "default", or they try and update
the clock/time source using the API calls.
Therefore, we align the behaviour of MPM devices with the other devices,
and fall back to an internal source if nothing else is provided.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The E31x and E320 devices have one virtual daughterboard, and it is
always present. This is different from N3xx, which is where the MPM code
for these devices is based upon.
During the E3xx initialization, we make sure that our single
"daughterboard" exists and is responsive. That means we can remove some
code that tests for the availability and number of daughterboards, which
we need on N3xx (which works with zero, one, or two daughterboards).
This also allows us some minor deduplication of code.
|
| |
|
|
|
|
|
|
|
|
| |
Use new benchmark_rate args "--multi_streamer" and
"--priority" for X410 streaming tests.
This gets the best performance from the streaming host machine.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
| |
|
| |
|