| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
This adds a doxygen tag for the `chan` parameter in
fir_filter_block_control::set_coefficients().
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Over the years the UHD code base got a whole bunch of tools to
control and configure devices. This is an attempt to unify these
tools into one.
Co-authored-by: Alexander Weber <alexander.weber@ni.com>
|
| |
|
|
|
|
|
|
|
|
| |
Add support for the new "priority" and "multi_streamer" benchmark_rate
args to run_benchmark_rate.py to enable batch runs of benchmark_rate
using those arguments.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
| |
|
|
|
|
|
|
| |
This fixes an issue with setting the active channel source in MPM, and
additionally allows opening up the more flexible API in the future without
requiring a filesystem update.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The power that corresponds to a certain gain values depends on the
frequency band we are in. At the edges of these bands discontinuities
can occur (the gain necessary to achieve the same power value changes
non-continuously). The power calibration does a linear interpolation
between two neighbor points in the calibration data set to find at
best fitting value. We therefore have to make sure that this interpolation
does not cross discontinuities.
This is a minimal invasive approach. It adds values at discontinuities
for the lower and the upper band. The power calibration format uses
the frequency for a power to gain mapping as a map key. Therefore two
gain to power mappings cannot be stored for the same frequency as it
would be needed for the discontinuity. Instead the mapping for the
lower band is stored at the discontinuity frequency itself. The mapping
for the upper band is stored at the frequency + 1Hz. The calibration
will therefore still fail to yield proper results within this
sub-Hertz range. The frequency lookup in the power calibration manager
now uses round instead of truncation to find the best mapping frequency
in the calibration table.
With this, searching for neighbor data points now ensures that the data
points used belong to the same band (except for the range of
(f_discontinuity, f_discontinuity + 1Hz) ).
This commit does not solve the issue for calibration data generated
with usrp_power_cal.py because the Python interface has no means to
detect band edges for the USRP it is calibrating.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- Removed variables that have been deprecated in newer Doxygen versions
- Replaced <speedgrade> with $speedgrade in E310 manual; Doxygen thinks
it's an HTML tag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, the following code fails:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=x4xx")
>>> M = U.get_mpm_client()
Traceback (most recent call last):
File "<input>", line 1, in <module>
M = U.get_mpm_client()
File ".../uhd/usrp/multi_usrp.py", line 37, in <lambda>
setattr(self,
'get_mpm_client', lambda: _get_mpm_client(token, mb_args))
File ".../uhd/usrp/multi_usrp.py", line 19, in _get_mpm_client
from uhd.utils import mpmtools
ModuleNotFoundError: No module named 'uhd.utils'
|
|
|
|
|
|
|
|
| |
In order to perform certain operations (start/stop/step), meta_range_t
objects must be "monotonic", meaning that the subranges composing it
are sorted and non-overlapping. This commit creates a method which
takes a non-monotonic meta_range_t containing no non-continuous
subranges and converts it into a monotonic meta_range_t.
|
|
|
|
| |
This fixes links to RFNoC docs in the "Coding to the API" section.
|
|
|
|
|
| |
Removes an invalid rate configuration for N310 functional FPGA
verification tests.
|
| |
|
|
|
|
|
| |
This vector is no longer used with RFNoC devices. We remove references
to X300 from the example, and instead use B210 as an example.
|
|
|
|
|
|
|
| |
- rfnoc_replay_samples_from_file still had UHD3-vestiges for selecting
block port and ID
- The documentation for stream_args_t also included block port and ID
examples
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to 930fa39, where we set the MTU property explicitly
for several blocks. The radio block should also receive this treatment,
as the IQ data going into its inputs is not forwarded to its outputs.
This patch will remove spurious log messages like these:
[INFO] [0/Radio#0] Setting default MTU forward policy.
[INFO] [0/Radio#1] Setting default MTU forward policy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Boost versions prior to 1.68 appear to have a bug where a decorator to
denote a test as disabled is not honored when affixed to a data-driven
test case, which is how the benchmarks in convert_test are skipped when
the unit test is run. (The tests take some time to complete and we don't
want them running with every CI pass.)
This commit adds an alternative benchmark skipping mechanism when Boost
<1.68 is used. The benchmark test cases perform a runtime check for the
user-provided `--benchmark` command-line option. If not found, the test
case returns prematurely. If found, the test case will execute. Note
that because `--benchmark` is a command-line option specific to this
test, and not to Boost, the options must follow `--` in the command
line in order to take effect: `convert_test -- --benchmark`.
|
|
|
|
|
|
|
|
| |
The counters that keep track of overruns, underruns, number of samples
transferred, etc., were not atomic. Thus, running benchmark_rate with
multiple threads would result in inaccurate statistics being reported at
the end of the run. This commit makes those counters atomic variables so
that they are updated properly.
|
| |
|
| |
|
|
|
|
|
|
|
| |
In the HDL, the parameter named 'MTU' is clog2 of the size of the
desired MTU. For example, when the 'MTU' parameter is 10, that means
the actual MTU setting is 2**MTU or 1024. So we need to set our
buffers to 2**MTU if we want them to be one MTU in size.
|
| |
|
|
|
|
|
|
|
| |
- Added support for tx_spb and rx_spb arguments
- Fixed TX thread timestamp for single channel
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit refactors ctrlport_endpoint and fixes several issues related
to multiple threads sending and receiving control transfers.
First, it refactors the change that Martin Braun implemented in
0caed5529 by adding a tracking mechanism for control requests where
clients have explicitly asked to receive an ACK when the corresponding
control response is received.
When a client wants to wait for an ACK associated with a control
request, a combination of that request's opcode, address, and sequence
number is added to a set when the request is sent. When a control
response is received, the set is consulted to see if the corresponding
request is there by matching the packet field data listed above. If so,
the control response is added to the response queue, thus notifying all
threads waiting in `wait_for_ack()` that there is a response that the
thread may be waiting on. If the request is not in the set, the request
is never added to the response queue. This prevents the initial problem
that 0caed5529 was addressing of the response queue growing infinitely
large with control responses that would never be popped from the queue.
Secondly, it addresses issues when multiple threads have sent a request
packet and are waiting in `wait_for_ack()` on the corresponding
response.
Originally, the function contained a loop which would sleep the calling
thread until the control response queue had at least one element in it.
When awakened, the thread would pop the frontmost control response off
the queue to see if it matches the corresponding control request (i.e.,
has the same sequence number, opcode, and address elements). If so, the
response would be handled appropriately, which may include signalling an
error if the response indicates an exceptional status, and the function
would return. If the response is not a matching one, the function would
return to the top of the loop. If the corresponding response is not
found within a specified period, the function would throw an op_timeout
exception.
However, there is a subtle issue with this algorithm when two different
calling threads submit control requests and end up calling
`wait_for_ack()` nearly simultaneously. Consider two threads issuing a
control request. Thread T1 issues a request with sequence number 1 and
thread T2 issues a request with sequence number 2. The two threads then
call `wait_for_ack()`. Let's assume that neither of the control reponses
have arrived yet. Both threads sleep, waiting to be notified of a
response. Now the response for sequence number 1 arrives and is pushed
to the front the response queue. This generates a signal that awakes one
of the waiting threads, but which one is awakened is completely at the
mercy of the scheduler. If T1 is awakened first, it pops the response
from the queue, finds that it matches the request, and handles it as
expected. Later, when the reponse for sequence number 2 is pushed onto
the queue, the still-sleeping T2 will be awakened. It pops the response,
finds it to be matching, and all is well.
But if the scheduler decides to wake T2 first, T2 ends up popping the
response with sequence number 1 off the front of the queue, but it
doesn't match the request that T2 sent with sequence number 2, so T2
goes back to the top of the loop. At this point, it doesn't matter if T2
or T1 is awakened next; because the control response for sequence number
1 was already popped off the queue, T1 never sees the control response
it expects, and will throw uhd::op_timeout back up the stack.
This commit modifies the `wait_for_ack()` algorithm to search the queue
for a matching response rather than indiscriminately popping the
frontmost element from the queue and throwing it away if it doesn't
match. That way, the order in which threads are awakened no longer
matters as they will be able to find the corresponding response
regardless. Furthermore, when a response is pushed onto the response
queue, all waiting threads are notified of the condition via
`notify_all()`, rather than just waking one thread at random
(`notify_one()`). This gives all waiting threads the opportunity to
check the queue for a response.
Finally, the `wait_for_ack()` loop has been modified such that the
thread waits to be signalled regardless of whether the queue has
elements in it or not. (Prior to this change, the thread would only wait
to be signalled if the queue was empty.) This effectively implements the
behavior that all threads are awakened when a new control response is
pushed into the queue, and combined with the changes above, ensures that
all threads get a chance to react and check the queue when the queue is
modified.
|