| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
| |
During construction of the rfnoc_graph, enumerate all of the connected
blocks, construct their controllers, and store them in the graph.
|
| |
|
|
|
|
|
| |
These args come from the framework, e.g., because the UHD session was
launched with them.
|
| |
|
|
|
|
| |
This allows blocks to reduce the number of actual, available ports.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The management looks at the transport endianness from the packet
factory to determine if the byte_swapper in the FPGA needs to be enabled
|
| |
|
|
|
|
| |
- Add peek64() and poke64() convenience calls
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
All noc_block_base derivatives are now plugged into the tick rate
system. Connected nodes can only have one tick rate among them. This
implies there is also only ever one tick rate per block.
set_tick_rate() is a protected API call which can be called by blocks
such as radio blocks to actually set a tick rate. Other blocks would
only ever read the tick rate, which is handled by the get_tick_rate()
API call.
|
| |
|
|
|
|
|
|
|
| |
When a node has multiple properties that depend on each other (and
possible have circular dependencies), the previous version of property
propagation would not correctly resolve properties that got flagged
dirty during the execution of other resolvers.
|
| |
|
|
|
|
|
| |
- Fleshed out mb_iface
- Managers currently only export ctrl APIs. Data APIs TBD
|
|
|
|
|
|
| |
- chdr_ctrl_endpoint can manage multiple dest EPIDs
- Moved from both_xports_t to a special defs in rfnoc_common
- Changed data-structures where appropriate
|
|
|
|
|
|
| |
- Moved chdr_packet and chdr_types from rfnoc/chdr to rfnoc and updated
all references
- Moved non-CHDR definitions to rfnoc_common.hpp
|
| |
|
|
|
|
| |
This contains both_links_t
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inline_io_service connects transports to links without any
worker threads. Send operations go directly to the link, and recv
will perform the I/O as part of the get_recv_buffer() call.
The inline_io_service also supports muxed links natively. The receive
mux is entirely inline. There is no separate thread for the
inline_io_service, and that continues here. A queue is created for
each client of the mux, and packets are processed as they come in. If
a packet is to go up to a different client, the packet is queued up
for later. When that client attempts to recv(), the queue is checked
first, and the attempts to receive from the link happen ONLY if no
packet was found.
Also add mock transport to test I/O service APIs. Tests I/O service
construction and some basic packet transmision. One case will also
uses a single link that is shared between the send and recv transports.
That link is muxed between two compatible but different transports.
|
|
|
|
|
|
|
|
|
|
|
| |
Split the transport into three layers to allow for greater flexibility
in scheduling algorithms. The io_service will make queues on behalf of
the transport and take responsibility for scheduling data transfers
through the links.
The transport layer is the explicit handler for flow control. This
enables the possibility of a scheduling layer in between, so flow
control may be offloaded on the same thread as the link.
|
|
|
|
| |
Add test for transports using mock transports
|
|
|
|
|
|
|
|
|
|
| |
New interface aimed to replace zero_copy_if for new code, including new
RFNoC development and redesign of streamer objects.
Generic implementation of send and receive transport interfaces to allow
reuse by various transport types. Derived classes implement
transport-specific functions that are invoked by the base classes
through CRTP.
|
|
|
|
|
| |
The default block controller should get instantiated when no other
suitable block controller can be found.
|
| |
|
|
|
|
|
| |
The inteface provides a mechanism for users of clocks to query
information such as the running status or rate
|
|
|
|
|
|
|
|
| |
A small modification to rfnoc::action_info makes it polymorphic, and
instead of serializing data structures into a string, this allows
creating custom action objects and identifying them via RTTI. The stream
command action object is a good example for how to use this, so all the
usages of stream command action objects were converted to this scheme.
|
| |
|
|
|
|
|
|
| |
- Add support for new backend iface with max_async_msgs and mtu
moved to after the noc ID
- Fixed offsets for block info registers
|
|
|
|
| |
This replaces device3() for RFNoC applications.
|
|
|
|
|
|
|
|
| |
This structure represents information about a graph edge. Required by
detail::graph and rfnoc_graph.
graph_edge_t::to_string() will now provide a textual representation of
the edge.
|
|
|
|
|
| |
All USRP device impls that are RFNoC devices will need to derive from
this (instead of device3).
|
|
|
|
|
|
|
| |
Previously, it was 0/FFT_1. The counter was separated by an underscore.
Now, we separate by a # symbol to allow for underscores in block names.
This means 'FIR_Filter' is now a valid blockname.
|
|
|
|
|
|
| |
- noc_block_base now has a ctor defined
- The registry stores factory functions to the individual Noc-Block
implementations
|
|
|
|
|
| |
The async message callback now has a vector of data words instead
of a single one
|
|
|
|
|
|
|
|
|
|
| |
- Adding client_zero class, which gathers information about our device
form the global registers on port 0 of the RFNoC backend registers.
- adding unit tests to exercise client_zero
- mock_reg_iface class: adding fake register_iface so we can run
unit tests in software only
Co-authored-by: Martin Braun <martin.braun@ettus.com>
|
|
|
|
|
|
|
|
|
| |
Adding mixin class that manages holding onto a register_iface.
Deriving from this new class in noc_block_base, as it needs access to
a register_iface.
Co-authored-by: Brent Stapleton <brent.stapleton@ettus.com>
|
|
|
|
| |
This is a continuation of a76ce96c.
|
|
|
|
|
|
|
|
| |
- Added new register_iface class that translates high-level
peek/poke calls into CHDR control payloads
- Added new chdr_ctrl_endpoint class that emulates a control
stream endpoint in SW. It can create and handle multiple
register interfaces
|
| |
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
- The management portal is the interface for the framework
to allow discovering the data topology, setup routes between
stream endpoints and configure streamers
- Use a zero_copy_if and the mgmt_paylod to send/recv packets
|
|
|
|
|
|
|
| |
- Moved packet interface code from public to private include
- Split packet interface into two files: payload paring and packet iface
- Added support for all CHDR packet types
- Added more test cases to unit test
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
| |
This is a storage for the noc_block_base derivatives. It supports
finding blocks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an initial generator for eRFNoC block.
The script generates the top level block, the shell module, a testbench, and a
Makefile as well as a Makefile.srcs.
To build a block from a yml file one has to invoke
python -c <config> -d <destination folder>
destination folder should be an in tree module folder located in
uhd-fpga/usrp3/lib/erfnoc/blocks
The build tool supports all interface types for control as well as data.
For each interface type there are three templates to generate the variable
block in the top level block and the shell
* declare the wires
* connect the wires
* instantiate the modules
The first two are used in the shell module as well as in the top level block.
The last is for the shell only.
|
|
|
|
|
| |
Its purpose is to provide a device-agnostic back-channel interface into
the device guts for all rfnoc_graph devices.
|
|
|
|
| |
This is a parent class for all block controllers.
|
|
|
|
| |
This is a generic CHDR interface that abstracts out the bus width.
|