| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of
files that clang-format gets applied against.
|
| |
|
|
|
| |
Keep a reference to the graph object so that when a new multi_usrp is
opened to the same device, the same graph is also used.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Implement I/O service detach link methods
- The I/O service manager instantiates new I/O services or connects
links to existing I/O services based on options provided by the user
in stream_args.
- Add a streamer ID parameter to methods to create transports so that
the I/O service manager can group transports appropriately when using
offload threads.
- Change X300 and MPMD to use I/O service manager to connect links to
I/O services.
- There is now a single I/O service manager per rfnoc_graph (and it is
also stored in the graph)
- The I/O service manager now also knows the device args for the
rfnoc_graph it was created with, and can make decisions based upon
those (e.g, use a specific I/O service for DPDK, share cores between
streamers, etc.)
- The I/O Service Manager does not get any decision logic with this
commit, though
- The MB ifaces for mpmd and x300 now access this global I/O service
manager
- Add configuration of link parameters with overrides
Co-Authored-By: Martin Braun <martin.braun@ettus.com>
Co-Authored-By: Aaron Rossetto <aaron.rossetto@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the following Boost constructs:
- boost::shared_ptr, boost::weak_ptr
- boost::enable_shared_from_this
- boost::static_pointer_cast, boost::dynamic_pointer_cast
The appropriate includes were also removed. All C++11 versions of these
require #include <memory>.
Note that the stdlib and Boost versions have the exact same syntax, they
only differ in the namespace (boost vs. std). The modifications were all
done using sed, with the exception of boost::scoped_ptr, which was
replaced by std::unique_ptr.
References to boost::smart_ptr were also removed.
boost::intrusive_ptr is not removed in this commit, since it does not
have a 1:1 mapping to a C++11 construct.
|
| |
|
|
|
|
|
| |
In the rfnoc_graph, we init blocks, GSM, motherboard controllers, and
other things. Since any of these can potentially throw exceptions, we
make sure to deinit those components that have already initialized
properly before exiting.
|
| |
|
|
|
|
|
| |
Add a shared pointer to the streamers to the rfnoc_graph, so that the
streamers are not deallocated before the graph. Nodes in the graph,
including the streamers, must remain in memory until the graph is no
longer needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows mb_controller childs to implement an init() call which
rfnoc_graph will call after the block initialization is complete.
rfnoc: graph/mb_controller: Add synchronization routine
This adds two new API calls:
* rfnoc_graph::synchronize_devices() and
* mb_controller::synchronize().
The purpose is to synchronize devices in time and/or phase, depending on
device capabilities. mb_controller childs can override or extend the
default implementation, which is to simply set time next PPS and verify
(similar to the set_time_unknown_pps() call in multi_usrp).
rfnoc: mb_controller: Add gpio_src API
Adds new API calls (get_gpio_src, get_gpio_srcs, set_gpio_src,
get_gpio_banks) to mb_controllers
|
| |
|
|
|
|
|
| |
Since the mb_iface allocates local device IDs, also have it track
the associated adapter IDs and provide a facility to retrieve them.
Incorporate the adapter IDs in the user API to select the adapter
for streamers.
|
| |
|
|
| |
Now the user can choose which transport is used in connect() calls.
|
| | |
|
| |
|
|
|
| |
The convenience call that flushed all the blocks would throw during
timeout. Now, it returns a bool whether or not the flush was successful.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Formatting in prep for changes
|
| |
|
|
|
|
| |
rfnoc_graph::is_connectable() allows to check if is possible to call
connect() on blocks. If blocks are attached to other blocks statically,
or if they are on unconnected devices, they are not connectable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MTUs are now tracked through the framework for all childs of
noc_block_base. Every edge gets an 'mtu' property. MTU can be set and
get either through the prop API, or through new API calls (get_mtu(),
set_mtu()). It is also possible to create custom properties that depend
on the MTU by asking for a reference to the MTU property, and then
adding that to the input list of a property resolver.
The radio_control_impl includes a change in this commit where it sets
the spp based on the MTU.
Blocks can also set an MTU forwarding policy. The DDC block includes a
change in this commit that sets a forwarding policy of ONE_TO_ONE,
meaning that the MTU on an input edge is forwarded to the corresponding
output edge (but not the other edges, as with the tick rate).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Add device ID constants (e.g., E310 == 0xE310, X300 == 0xA300). These
are stored in the device FPGA, and can be used for decisions later
- Blocks can be specific to a device. For example, x300_radio_control
can only work on an X300 series device.
- Because blocks can be device-specific, all radio blocks can now share
a common Noc-ID (0x12AD1000).
- The registry and factory functions are modified to acommodate for
this.
- The motherboard access is now also factored into the same registry
macro.
|
| |
|
|
|
|
| |
Previously, the code was using a hard-coded local device ID. Now, the
GSM initialization code will read CHDR width and all local device IDs
from the mb_iface to correctly dynamically initialize the GSM.
|
| |
|
|
|
|
|
| |
- Remove duplicate calls to uhd::device::make
- Do a try/catch on full class initialization
- Separate setup_graph() into multiple sub-functions
- Improve const-correctness
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transports:
Transports build on I/O service and implements flow control and
sequence number checking.
The rx streamer subclass extends the streamer implementation to connect
it to the rfnoc graph. It receives configuration values from property
propagation and configures the streamer accordingly. It also implements
the issue_stream_cmd rx_streamer API method.
Add implementation of rx streamer creation and method to connect it to
an rfnoc block.
rfnoc_graph: Cache more connection info, clarify contract
Summary of changes:
- rfnoc_graph stores more information about static connections at the
beginning. Some search algorithms are replaced by simpler lookups.
- The contract for connect() was clarified. It is required to call
connect, even for static connections.
|
| |
|
|
| |
Implement uhd::rfnoc::rfnoc_graph::enumerate_*_connections()
|
| | |
|
| |
|
|
|
| |
This will call init_props() on every block after the device
initialization is complete, but before control returns to the user.
|
| |
|
|
|
|
| |
During construction of the rfnoc_graph, flush and reset each block in
each motherboard we need to enumerate. This will ensure that each
block is in a clean state when we construct it's block controller.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During registration, blocks must now specify which clock they are using
for the timebase (i.e., for timed commands) and for the ctrlport (this
is used to determine the length of sleeps and polls). For example, the
X300 provides bus_clk and radio_clk; typically, the former is used for
the control port, and the latter for the timebase clock.
Another virtual clock is called "__graph__", and it means the clock is
derived from property propagation via the graph.
The actual clocks are provided by the mb_iface. It has two new API
calls: get_timebase_clock() and get_ctrlport_clock(), which take an
argument as to which clock exactly is requested. On block
initialization, those clock_iface objects are copied into the block
controller.
The get_tick_rate() API call for blocks now exclusively checks the
timebase clock_iface, and will no longer cache the current tick rate in
a separate _tick_rate member variable. Block controllers can't manually
modify the clock_iface, unless they also have access to the
mb_controller (like the radio block), and that mb_controller has
provided said access.
This commit also adds the clock selection API changes to the DDC block,
the Null block, and the default block.
|
| |
|
|
|
|
|
|
| |
On destruction, the rfnoc_graph will call shutdown() on all blocks. This
allows a safe de-initialization of blocks independent of the lifetime of
the noc_block_base::sptr.
Also adds the shutdown feature to null_block_control.
|
| | |
|
| | |
|
| |
|
|
|
| |
During construction of the rfnoc_graph, enumerate all of the connected
blocks, construct their controllers, and store them in the graph.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The mb_controller is an interface to hardware-specific functions of the
motherboard. The API works in two ways:
- The user can request access to it, and thus interact directly with the
motherboard
- RFNoC blocks can request access to it, if they need to interact with
the motherboard themselves.
|
|
|
This replaces device3() for RFNoC applications.
|
