| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
The Windows UHD installer binary, generated by e.g. running the PACKAGE
project in the Visual Studio solution generated by CMake, creates two
shortcuts to utilities that are no longer included with the installer:
the USRP2 card burner and USRP-N2xx net burner. This commit removes
these defunct shortcuts.
|
|
|
|
|
|
|
|
|
| |
When creating RFNoC images at least one SEP needs to have ctrl enabled
otherwise one will end up with a non-functional image.
This commit adds a method to the image builder to do plausibility checks
on the configuration. The only check done for now is to verify that there
is at least one SEP with ctrl enabled.
|
|
|
|
|
|
|
|
|
|
| |
When a webpage is accessed via secure HTTP, and that webpage attempts to
address active content via a non-secure URI, most modern browsers will
block the loading of that content as a security precaution. In this
case, the URI to the MathJax JavaScript rendering library was specified
in the Doxygen configuration with an HTTP (i.e., non-encrypted) URI,
thus preventing the browser from loading it and rendering formulae
correctly.
|
|
|
|
|
| |
For RFNoC devices, it now displays "RFNoC capable: Yes", like it did in
UHD 3.
|
|
|
|
|
| |
The path it returned was only valid in UHD 3. Added unit test to
confirm.
|
|
|
|
| |
Add an additional paragraph on back-edges, and when *not* to declare them.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This example would not specify a channel when querying the actual
frequency/bandwidth/gain after setting it. When using the --channels
options like this:
tx_bursts --channels 1 --freq 1e9 [...]
...it would request the frequency of 1 GHz on channel 1, then query the
frequency on channel 0 when reporting the "actual" frequency.
Also removes some boost::format().
|
|
|
|
|
|
| |
Due to a change in Mender, bmaptool is no longer supported for writing filesystem images.
Currently, the only recommended method for writing a filesystem to an SD card is to use dd.
The filesystem can still be updated in place using mender.
|
|
|
|
|
|
|
| |
In C++, variables whose address are taken must be defined somewhere.
PERIPH_BASE had no such definition, so on some compilers/systems caused
a linker error. This commit switches to using enums to prevent this
happening again in the future.
|
|
|
|
|
|
|
|
|
| |
This tests the following graph: DDC -> Replay -> DDC, where the initial
and final blocks are the same (i.e., a loop). This could be useful for
generating and capturing data with the same replay block while testing
a block.
Note that this test will fail if the edge consistency checks are buggy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On back-edges, no properties are forwarded, but properties must be
consistent after property resolution. This breaks when the source edge
on a back-edge has an edge property which the destination block does
not. Consider the following graph:
DDC -> Replay -> DDC
where both instances of 'DDC' refer to the same block. Now, assume the
first edge is declared a back edge (in principle, it shouldn't matter).
The DDC block has an edge property `samp_rate` which the Replay block
does not. Therefore, it can't forward this edge property to the Replay
block's input edge property list.
In the consistency check code, we don't check for the existence of edge
nodes, because it is assumed edge properties where either forwarded, or
aligned through some other manner. This leads to a property lookup
failure.
With this fix, we skip the consistency check for edge properties which
don't exist on the destination node. This is safe because the
destination block can not have a property resolver defined for undefined
properties. This means the destination block can either:
- Drop the property. In this case, there is no value in checking
consistency. Even if we could forward edge properties on back-edges,
they would always have the same value.
- Forward the property. In that case, the consistency check would happen
elsewhere in the graph where there's no back-edge.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add data packet payload field
- Add metadata support
- Add missing management fields (OpsPending, ExtendedInfo).
- Add missing control fields (byte_enable, data, has_time)
- Update offsets for management OpPayload fields.
- Make the field names more consistent, readable, and consistent
with the RFNoC specification.
- Display value of fields in addition to name.
- Fix timestamp, eob, and eov offsets
|
|
|
|
|
|
| |
The ops pending for each operation was stored implicitly in the data
structure. This adds it explicitly, which is useful for debugging
and packet dissection.
|
|
|
|
|
| |
When using ENABLE_X400=OFF, we should also disable the corresponding
tests, or we get linker errors.
|
|
|
|
|
|
| |
The man pages for usrp_x3xx_fpga_burner and octoclock_firmware_burner
are obsolete; the corresponding utilities were replaced by
uhd_image_loader many UHD versions ago.
|
|
|
|
|
|
| |
Some comments describing data flow direction were wrong. This commit
updates the Mako files and updates the noc_shell modules with newly
generated versions.
|
| |
|
| |
|
| |
|
|
|
|
| |
Support DPDK versions 19.11 and 20.11
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class has a member _num_drops, which can be read out using the
get_num_drops() API call. However, when dropping packets, this counter
was not incremented, which is fixed now.
This also includes a very minor optimization from 2 map<> lookups to
1 lookup (they are in O(log N)). Since there are usually a small
two-digit number of endpoints connected to the async message receiver,
this change is not expected to yield major improvements, but the lookup
*is* in a hot loop.
|
| |
|
|
|
|
|
|
| |
The keys for the table of frequency ranges for each VCO value counts up
consecutively but key "1" was there twice while "2" was missing. This
is fixed here.
|
|
|
|
|
| |
On newer versions of Boost, they show deprecation notes. However,
they're not actually used any more so they can go.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default block controller is used whenever no other block controller
is used. It currently defaults to dropping both property propagation and
actions.
When a custom block is injected into a graph like this for example:
Radio -> DDC -> Custom Block -> Rx Streamer
This default behaviour causes the Rx Streamer to not be able to send
actions (like stream commands) nor does it allow MTU propagation (or any
other property's propagation).
The default block behaviour is ONE_TO_ONE, meaning that actions and
properties on input channel N will get forwarded to output channel N. In
absence of an actual block controller, this is more useful default than
setting the propagation to DROP for both actions and properties. Most
blocks that pass through data, or do some simple processing, will now
work in the absence of a block controller.
The new disadvantage is that blocks which would modify properties such as
sampling rate, scaling, or MTU will no longer work properly in the
absence of a block controller.
However, the recommended behaviour is anyway not to operate without a
block controller. For the cases where no block controller is present,
ONE_TO_ONE is considered the generally more useful default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have noticed that on 1 GbE connections, MTU discovery can become
unreliable. Since we now use the MTU directly for deriving spp and other
values, a correct MTU is important.
Because we don't have a way of knowing if MTU discovery worked or not,
we add some heuristics in form of a plausibility check. For now, the
only rule in this check is if that the detected MTU is a bit larger than
1472 bytes, we coerce down to 1472, because this is such a standard
value (most 1 GbE interfaces default to an IPv4 MTU of 1500 bytes).
For the cases where the interface MTU is set to be between 1500 and 1528
bytes, this would cause a very minor performance loss. We accept this
performance loss as it is small, and those cases are very rare. MTUs are
usually 1500 bytes, or >= 8000 bytes for high-speed links using jumbo
frames.
|
|
|
|
|
|
|
| |
This constant was generally harmful, since it was only correct under
certain circumstances (64 bit CHDR with timestamps). The X3x0 code was
the last place it was being used, and we remove it without substitute
because it was not doing anything useful here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two values where being mixed up in the code. To summarize:
- The MTU is the max CHDR packet size, including header & timestamp.
- The max payload is the total number of bytes regular payload plus
metadata that can be fit into into a CHDR packet. It is strictly
smaller than the MTU. For example, for 64-bit CHDR widths, if
a timestamp is desired, the max payload is 16 bytes smaller than
the MTU.
The other issue was that we were using a magic constant (DEFAULT_SPP)
which was causing conflicts with MTUs and max payloads.
This constant was harmful in multiple ways:
- The explanatory comment was incorrect (it stated it would cap packets
to 1500 bytes, which it didn't)
- It imposed random, hardcoded values that interfered with an 'spp
discovery', i.e., the ability to derive a good spp value from MTUs
- The current value capped packet sizes to 8000 bytes CHDR packets, even
when we wanted to use bigger ones
This patch changes the following:
- noc_block_base now has improved docs for MTU, and additional APIs
(get_max_payload_size(), get_chdr_hdr_len()) which return the
current payload size given MTU and CHDR width, and the CHDR header
length.
- The internally used graph nodes for TX and RX streamers also get
equipped with the same new two API calls.
- The radio, siggen, and replay block all where doing different
calculations for their spp/ipp values. Now, they all use the max
payload value to calculate spp/ipp. Unit tests where adapted
accordingly. Usage of DEFAULT_SPP was removed.
- The replay block used a hardcoded 16 bytes for header lengths, which
was replaced by get_chdr_hdr_len()
- The TX and RX streamers where discarding the MTU value and using the
max payload size as the MTU, which then propagated throughout the
graph. Now, both values are stored and can be used where appropriate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The replay block is more like the radio block than like a FIFO. In
particular, consider this flow graph:
Replay -> DDC -> Replay
Imagine you're using the replay block to test the DDC block with
prerecorded data. If we treated the Replay Block like a FIFO, then we'd
have a loop in the graph (which is already wrong). If we used the DDC to
resample, then the input- and output sample rate of the Replay mismatch,
which is a legal way to use the Replay block, but not possible if we
treat the graph like a loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This example had some major issues since UHD 4, which are now fixed.
Mainly, the option to include a custom RFNoC block was not working.
The example was rehauled severely:
- Custom blocks are now usable again.
- UHD/RFNoC code is used for the connections, rather than a custom
kludge.
- Sample rate is set via property propagation
- boost::format() was not helpful in this example, and was removed.
- A list of active connections is now printed
- The --block-args argument is dropped in favour of --block-props. The
former never did anything useful, and "block args" are a UHD 3 thing.
|
|
|
|
|
| |
This adds some more explanatory comments around active and static
connections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When connect_through_blocks() was called on blocks within a single
chain, there was a bug where the chain was incorrectly cropped. In
a standard FPGA image, say one was to use this API call to connect the
radio to the DDC. It would generate a chain of blocks hanging off the
radio as such:
Radio -> DDC -> SEP
What the code should do, and what this fix provides, is that the chain
gets cropped after the DDC, to look like this:
Radio -> DDC
With the current bug, it would assume the chain has a dangling edge, and
incorrectly throw an exception.
Note that this bug would not appear when source and destination block
are on separate chains (i.e., both have an SEP in their chain).
This patch includes minor logging and comment improvements around the
offending lines of code.
|
| |
|
|
|
|
|
|
|
|
|
| |
This script is intended to be run before streaming.
- Manages network interfaces, memory buffers, and other
aspects of the system configuration to give the host machine
ideal performance during streaming.
- Installs/updates dpdk/util dependencies for the script
- Generates and writes uhd config files for dpdk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The async message handler and the async message validator would
erroneously compare channel numbers for RX async messages with the
number of valid TX channels. On TwinRX, where there are zero TX
channels, this would always fail. Elsewhere in the code, the comparisons
for TX and RX channels mixed up input and output ports.
The second issue is that the comparison made was a "greater than" rather
than "greater or equal".
The effect of these two bugs was that potentially, we could have
accepted async messages for an invalid port N, where N is the number of
valid ports of this block, and that for TwinRX/X300 users, async
messages on channel 1 would not get accepted (they would, however, get
accepted for channel 0 because of the second issue). This includes
overrun handling, which was broken for channel 1 and 3 on an X300.
Another effect of the bug was that EPIDs for async messages weren't
always programmed correctly.
|
|
|
|
|
|
|
| |
Getting the time from the mb_controller is slow, so try to get the time
from the Radio on the fast path first.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
| |
Add API calls to Radio control to get ticks and time.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
| |
- Remove documentation of skip_dram, skip_ddc, skip_duc, which are all
obsolete since UHD 4
- Properly document serialize_init
- Add a table of valid args for X310 as with other devices
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The order must:
- Check transaction has the right number of hops, then read hop
- Check hop has the right number of operations (at least 2), then read
those ops
- Check the ops have the correct opcodes
The code was doing checks in the wrong order. Thanks to Github user
johnwstanford for pointing this out.
|
|
|
|
|
|
|
| |
This provides every block controller with a copy of its CHDR width.
Note: mock blocks always get configured with a 64-bit CHDR width, to
retain API compatibility.
|
|
|
|
|
|
|
| |
This allows consumers of UHD compiling with C++11 to include this file
(which is now included via noc_block_base) by turning a switch statement
into a functionally equivalent (albeit less readable) nested ternary
statement.
|
|
|
|
| |
Thanks to Github user johnwstanford for pointing this out.
|
|
|
|
|
|
|
|
|
|
| |
The times on the device can glitch if either the tick rate changes or
the number of active chains changes. This throws off the time if the
user gets streamers, changes the sample rate, or changes the tick rate
after synchronizing the time. This change re-synchronizes the times
automatically in those cases.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
| |
|