| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Clarify that invalid RFNoC graph topology failures are due to an attempt
to access input or output ports that are not connected to anything in
the FPGA.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
When a node has an action callback assigned this must be cleared
along with the block removal. Otherwise a post action callback
might try to modify node that are already removed which results
in an undefined behavior.
In particular this one fixes the
Unexpected error [ERROR] [CTRLEP] Caught exception during async message handling: map::at
when running the multi_usrp_test.py
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit adds another resolve_all_properties method to use the
node instead of the vertex descriptor. The vertex descriptor could be
removed. This could cause the lambda capture to have an outdated
vertex descriptor, which would result in a hang when looking for it.
This resolves the issue by capturing the node and looking for the vertex
descriptor.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default resolve callback behavior for a newly-instantiated `node_t`
object resolves all dirty properties associated with the node, then
marks the properties as clean. When the node is added to a graph, its
resolver callback is updated to use the graph property propagation
algorithm in `graph_t::resolve_all_properties()`, which is considerably
more sophisticated and relies on the graph topology to do its work.
When a connection between two nodes is broken via the
`graph::disconnect()` method, nodes which no longer have incoming or
outgoing edges (connections) are removed from the graph. Prior to this
change, the removed node's resolver callback was left pointing at the
graph property propagation algorithm. In certain use cases, this could
result in unexpected client-facing behavior. Consider, for example, this
code (incomplete and for illustrative purposes only) which creates a
streamer on one transmit chain of a multi-channel device, destroys that
streamer, then creates a stream on the other transmit chain. Attempting
to set the TX rate on the first chain after destroying the streamer does
not result in the expected rate change, despite the same code working
correctly before creating the streamer:
constexpr size_t CH0 = ..., CH1 = ...;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(...);
// Set a TX rate on both chains; this succeeds
usrp->set_tx_rate(initial_rate, CH0);
usrp->set_tx_rate(initial_rate, CH1);
assert(initial_rate == usrp->get_tx_rate(CH0));
assert(initial_rate == usrp->get_tx_rate(CH1));
// Create a TX streamer for channel 0
std::vector<size_t> chain0_chans{CH0};
stream_args_t sa;
sa.channels = chain0_chans;
sa.otw_format = ...;
sa.cpu_format = ...;
uhd::tx_streamer::sptr txs = usrp->get_tx_stream(sa);
// Destroy the first streamer (disconnecting the graph) and
// create a streamer for channel 1
txs.reset();
std::vector<size_t> chain1_chans{CH1};
sa.channels = chain1_chans;
txs = usrp->get_tx_stream(sa);
// Now try to set a new TX rate on both chains
usrp->set_tx_rate(updated_rate, CH0);
usrp->set_tx_rate(updated_rate, CH1);
assert(updated_rate == usrp->get_tx_rate(CH0)); // <--- FAILS
assert(updated_rate == usrp->get_tx_rate(CH1));
The reason this fails is because the second call to `set_tx_rate()` on
channel 0 internally sets the 'interp' (interpolation ratio) property on
the DUC node via the call to the DUC block controller's
`set_input_rate()` function. As the DUC node is no longer part of the
graph, having been removed from it when the first streamer instance was
destroyed, the graph property propagation algorithm doesn't 'see' the
node with the dirty property, and the 'interp' property resolver
callback is never invoked. As a result, the DUC's input rate property,
which depends on the interpolation ratio value, is never updated, and
thus calling the `get_tx_rate()` function to query the new rate of the
TX chain results in an unexpected value. In fact, in this particular
case, `set_tx_rate()` actually raises a warning that the TX rate
couldn't be set, and a message is printed to the console.
This commit remedies the situation by restoring the default resolve
callback behavior for a node when it is removed from the graph. This
allows the framework to be able to invoke the property resolver callback
on that node when a property is updated, the expected behavior of a
newly instantiated node.
|
| |
|
|
|
|
|
|
| |
This commit expands the scope of the former _release_mutex, renaming it
_graph_mutex and ensuring that all graph modification functions are
serialized against each other. This ensures that callers to graph_t's
public functions are always operating on a coherent view of the
underlying BGL graph object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The graph_t::disconnect(src_node, dst_node) function removes connections
(edges) from src_node to dst_node in the graph, and then removes the
nodes (vertices) if their degree is zero after removing the connections.
Because removing a vertex from the graph invalidates vertex descriptors,
the graph_t::_remove_node() function resynchronizes the node-to-vertex
descriptor map after removing the vertex.
However, in graph_t::disconnect(), the vertex descriptor corresponding
to dst_node was not being refetched after the potential removal of
src_node, which results in the incorrect removal of innocent nodes under
certain circumstances. This commit ensures that the node-to-vertex
descriptor is reconsulted for the vertex descriptor corresponding to
dst_node before removing it from the tree.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
- Added method to disconnect an edge
- Added method to remove a node
- Fixed algorithm to check edges during connect. Previous code was
checking some edges twice and allowing duplicate edges to be created
for existing edges.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
| |
Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of
files that clang-format gets applied against.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the existing graph, when the shutdown was simply a release. However,
any outstanding actions would trigger warnings (because released graphs
aren't supposed to still have actions being passed around), which would
sometimes be visible at the end of an application.
This is a safer solution than simply releasing, because it explicitly
sets a shutdown flag that all graph-affecting functions (property
propagation and action handling) respect. Once the flag is set, the
graph can no longer be booted up again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the concept of a resolution context, because the
property propagation algorithm needs to behave differently when called
during an initialization step (e.g. when the graph is committed), or
when the user changes a property on one of the nodes after it was
committed.
The algorithm is modified as follows:
- When called during an initialization step, then all nodes get resolved
at least once. If nodes added new properties, then all nodes get
touched again until the max number of iterations is reached.
- When called because a node modified one of its properties, then that
node is always resolved first. From there, all other nodes are
resolved in topological order. However, the algorithm immediately
terminates as soon as there are no more dirty nodes.
- When called because a node modified one of its properties, but the
graph is currently not in a committed state, then that node will do
a local property resolution.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Property propagation and action handling depend on the release state,
but they are lengthy operations. It is therefore imperative to not
change the release/commit state during those methods.
This commit changes the following:
- Change the release state counter from an atomic to a non-atomic
variable
- Instead, use a mutex to lock the release state counter, and use the
same mutex for locking access to the property propagation and action
handling
The rfnoc_graph now tries to release the graph before shutting down
blocks to make sure they don't get destroyed while those algorithms are
still running.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to enable overrun handling through the action API, a few new
features are implemented:
- The RX streamer can now accept stream command actions. The streamer
will interpret stream command actions as a request to send stream
commands upstream to all producers.
- A new action type is defined ('restart request') which is understood
by the radio and streamer, and is a handshake between producers and
consumers. In this case, it will ask the radio to send a stream
command itself.
When an RX streamer receives an overrun, it will now run the following
algorithm:
1. Stop all upstream producers (this was already in the code before this
commit).
2. If no restart is required, Wait for the radios to have space in the
downstream blocks.
The radio, if it was in continuous streaming mode before the overrun,
includes a flag in its initial action whether or not to restart the
streaming. Also, it will wait for the stop stream command from the
streamer. When it receives that, it will initiate a restart request
handshake.
3. The streamer submits a restart request action upstream. This action
will be received by the radio.
The radio will then check the current time, and send a stream command
action back downstream.
4. The RX streamer receives the stream command action, and uses it to
send another stream command to all upstream producers. This way, all
upstream producers receive a start command for the same time.
|
| |
|
|
|
|
|
|
| |
Sending actions to self is useful because calling post_action() from
within an action handler will not actually trigger the action. Instead,
it will defer delivery of the action. Allowing sending actions to self
will allow to add another action, in deterministic order, and the
execution of another action handler.
|
| |
|
|
| |
Implement uhd::rfnoc::rfnoc_graph::enumerate_*_connections()
|
| |
|
|
|
| |
This API lets blocks decide if their current topology is OK for them,
and make decisions based on their topology.
|
| | |
|
| |
|
|
|
|
|
|
| |
- Added action_info class
- Allow to send actions from node to node
- Allow to post actions into nodes
- Allow to set default forwarding policies
- Added unit tests
|
|
|
- Adds a detail::graph_t class, which handles the propagation
- Adds methods to node_t to aid with propagation
- Adds unit tests
- Adds dynamic property forwarding:
Nodes are now able to forward properties they don't know about by
providing a forwarding policy. A good example is the FIFO block which
simply forwards most properties verbatim.
- node: Temporarily disabling consistency check at init
|
