| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The builder has two major jobs:
* generate an image core file which reflects the FPGA image
configuration given by the user
* invoke Xilinx toolchain to actually build the FPGA image
For this purpose it needs to know where to find the FPGA source tree.
This tree can be give by the -F option.
The code that represents the user configurable part of the image is
written to a file called <device>_rfnoc_sandbox.v. To generate the file
these configuration files are needed:
* io_signatures.yml: A file describing the known IO signatures. This file
is global for all devices and contains the superset
of all signatures (not all signatures are used by all
devices). It resides in usrp3/top/ of the tree given
by -F.
* bsp.yml: A file describing interfaces of a specific device such as AXIS
transport interfaces or IO ports as well as device specific
settings. It resides in usrp3/top/<device> of the tree given by -F.
* <image>.yml: a file provided by the user with freely chosen name.
It describes which elements the image should contain
(RFNoC blocks, streaming endpoints, IO ports) and how
to connect them. The file also contains image setting
such as the CHDR width to be used.
The script uses mako templates to generate the sandbox file. Before the
template engine is invoked sanity checks are executed to ensure the
configuration is synthactic correct. The script also build up structures
to ease Verilog code generation in the template engine. The engine should
not invoke more Python than echoing variables or iterating of lists or
dictionaries. This eases debugging as errors in the template engine are
hard to track and difficult to read for the user.
All Python code is placed in a package called rfnoc. The templates used
by the builder are also part of this package. image_builder.py contains
a method called build_image which is the main entry point for the builder.
It can also be utilized by other Python programs. To align with the
existing uhd_image_builder there is also a wrapper in bin called
rfnoc_image_builder which expects similar commands as the uhd_image_builder.
For debugging purpuse the script can be invoked from host/utils using
$ PYTHONPATH=. python bin/rfnoc_image_builder <options>
When installed using cmake/make/make install the builder installs to
${CMAKE_INSTALL_PREFIX}bin and can be invoked without specifying a
PYTHONPATH.
One can also install the package using pip from host/utils
$ pip install .
Image config generation can also be done from GNU Radio Companion
files. The required GRC files are merged into gr-ettus.
Example usage:
$ rfnoc_image_builder -F ~/src/fpgadev -d x310 \
-r path/to/x310_rfnoc_image_core.grc \
-b path/to/gr-ettus/grc
Co-Authored-By: Alex Williams <alex.williams@ni.com>
Co-Authored-By: Sugandha Gupta <sugandha.gupta@ettus.com>
Co-Authored-By: Martin Braun <martin.braun@ettus.com>
|
|
|
|
| |
These are no longer used.
|
|
|
|
|
|
|
|
|
| |
Async messages (like, e.g., overrun messages) can include a timestamp.
This change enables access to the timestamp in the async message
handler. It is up to the FPGA block implementation to include the
timestamp, if desired/necessary. The definition of the timestamp may
also depend on the block, for example, the overrun async message will
include the time when the overrun occurred.
|
|
|
|
|
|
|
| |
This will receive async messages from the radio, and print OUL
characters where appropriate.
When an overrun message is received, it will send an action upstream to
initiate overrun handling.
|
| |
|
|
|
|
|
| |
The existing implementation would lock judiciously, causing a deadlock
when the async message handler would try and call poke32().
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
- Combine scaling and samp_rate resolvers
- Prioritize decim when user has set it for DDC:
When samp_rate_in changes, either the samp_rate_out or the decim
values may change to accommodate it. If decim has been set by the
user (which can be determined by the valid flag), prefer changing
samp_rate_out over decim.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
The valid bit helps prevent placeholder defaults from being
propagated through the graph. Values that are not valid will
not be forwarded.
|
|
|
|
| |
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.
|
|
|
|
|
| |
An immutable clock means it has a locked frequency, and attempts to
change the frequency will cause an exception to be thrown.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This lets child classes of register_iface_holder change the register
interface, or even invalidate it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These changes add APIs to instantiate the new transports. However,
only the control/management transport is currently implemented. It
uses the chdr_ctrl_xport.
Also update the mgmt_portal to use an ephemeral reference to the
shared transport, to indicate that it has no ownership of the
transport's memory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chdr_ctrl_xport is a dumb-pipe transport for RFNoC control transactions
and management frames.
Also remove the I/O service's check on num_recv_frames and num_send_frames.
The transports may request additional virtual channels, so the send_io_if
and recv_io_if may not reserve additional frames, as they are shared with
a previously-allocated instance.
Note: this uses a mutex to force sequentual access to the
chdr_ctrl_xport. This is supposed to go away when the multi threaded
xport is done.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Applying clang format for upcoming changes.
clang-format -i --style=file host/lib/usrp/cores/gpio_atr_3000.cpp
clang-format -i --style=file \
host/lib/include/uhdlib/usrp/cores/gpio_atr_3000.hpp
|
|
|
|
|
|
| |
The existing implementation assumes registers are spaced 4 bytes apart.
In the current radio block design, all backward compatible registers are
spaced 8 bytes apart. This adds a feature to configure that offset.
|
|
|
|
|
|
| |
This is a single atomic allocator in the global uhd::rfnoc namespace, so
that devices can allocate themselves device IDs without having to confer
with the rest of the RFNoC infrastructure.
|
|
|
|
|
| |
This converts from register_iface& to wb_iface::sptr. Useful for
connecting new block controllers with older interfaces.
|
|
|
|
|
|
| |
Following the changes in RX frontend controls, TX frontend register
offsets are now arguments to the factory function. They default to 4,
which is what the register offset was in the file before these changes.
|
|
|
|
|
|
|
|
| |
Changing how we calculate RX frontend register addresses to allow for
different register offsets. The register addresses are now calculated
in a manor similar to how gpio_atr_300_impl does register address
calculations, which is to allow a reg_offset to be passes in at
construction. The current default is reg_offset=4.
|
|
|
|
|
| |
Removes the requirement for a wb_iface, and also the requirement for
regs to be 4 addresses apart.
|
|
|
|
|
|
| |
The lock acquired by send_fn does not need to share the same mutex
as the rest of the class. It only needs to serialize between multiple
calls to send_fn. Gave send_fn it's own mutex for that reason
|
|
|
|
|
| |
This API lets blocks decide if their current topology is OK for them,
and make decisions based on their topology.
|
| |
|
|
|
|
|
| |
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.
|