aboutsummaryrefslogtreecommitdiffstats
path: root/host/lib/rfnoc
Commit message (Collapse)AuthorAgeFilesLines
* rfnoc: Change default block behaviourMartin Braun2021-12-021-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* rfnoc: Clarify usage of MTU vs. max payload size, remove DEFAULT_SPPMartin Braun2021-12-028-56/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* rfnoc: replay block: Disable prop and action propagationMartin Braun2021-12-011-1/+10
| | | | | | | | | | | | | | 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.
* rfnoc: radio: Fix async message handling channel checksMartin Braun2021-11-301-8/+8
| | | | | | | | | | | | | | | | | | | | | 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.
* multi_usrp_rfnoc: Reduce latency of get_time_now()michael-west2021-11-171-1/+1
| | | | | | | 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>
* host: Add ability to get time from Radio blockmichael-west2021-11-171-1/+19
| | | | | | Add API calls to Radio control to get ticks and time. Signed-off-by: michael-west <michael.west@ettus.com>
* rfnoc: mgmt_portal: Fix order of validity checksMartin Braun2021-11-151-2/+6
| | | | | | | | | | | 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.
* rfnoc: Add CHDR width to make argsMartin Braun2021-11-123-0/+4
| | | | | | | 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.
* host: python: Add gpio_voltage python APILane Kolbly2021-11-051-1/+11
|
* rfnoc: Remove cruft from UHD 3 (constants)Martin Braun2021-11-021-1/+5
| | | | | | | | | | | | | This removes some constants from UHD that were left over from RFNoC/UHD 3.x. They are unused. rfnoc_rx_to_file had a commented-out section that was also UHD-3 only. Note that rfnoc/constants.hpp is pretty bare now, and could be removed. However, it is in the public header section, so we shall leave the used constants where they are. This requires fixing includes in mgmt_portal.cpp.
* siggen: Fix direction of rotationWade Fife2021-10-271-9/+9
| | | | | | | | | The I and Q were swapped in sine_tone, which caused confusion and made the rotation of REG_CARTESIAN clockwise by default. This effectively made the resulting frequency negative. This PR makes the I and Q order consistent with RFNoC and fixes the direction of rotation so that a positive value for REG_PHASE_INC (phase increment) results in a counter-clockwise rotation, which yields a positive frequency.
* rfnoc: mgmt_portal: Remove two unused variablesMartin Braun2021-10-111-4/+6
| | | | Thanks for github user johnwstanford for pointing those out.
* chdr: Rename var max_size_bytes to avoid confusionMartin Anderseck2021-09-281-9/+9
| | | | | | | | | The variable max_size_bytes has a different name in the source than in the header and is not self-explanatory in both. Therefore when comparing against it in the assertion in line 142 one could assume that a number of bytes needs to be compared with a byte value. Change variable to `buff_size` in source and header file to avoid confusion and add documentation.
* radio: Improve log messages for non-implemented correctionsMartin Braun2021-09-081-3/+4
| | | | | This modifies some log messages or exception strings when using auto-correction APIs that are not supported by the underlying device.
* rfnoc: duc: Fix frequency range for DUC blockMartin Braun2021-08-302-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tuning range of the DUC depends on the output sample rate (which is larger), but it was using the input sample rate. This was causing a bug where for Tx, the DSP tuning range was limited when using multi_usrp API, and thus would not allow to DSP-tune beyond the current sampling rate. In this patch, we also re-use the existing calculation of the sampling rate, and harmonize that code between duc_block_control and ddc_block_control. Consider the following Python REPL code: >>> import uhd >>> U = uhd.usrp.MultiUSRP('type=x300') >>> U.set_rx_rate(10e6) >>> U.set_tx_rate(10e6) >>> # Creating a streaming is required, or the input rate will not be >>> # set: >>> S = U.get_tx_stream(uhd.usrp.StreamArgs("fc32", "sc16")) >>> treq = uhd.types.TuneRequest(1e9) >>> treq.rf_freq = 1e9 >>> treq.dsp_freq = 50e6 >>> treq.dsp_freq_policy = uhd.types.TuneRequestPolicy.manual >>> treq.rf_freq_policy = uhd.types.TuneRequestPolicy.manual >>> tres = U.set_rx_freq(treq, 0) >>> print(str(tres)) Tune Result: Target RF Freq: 1000.000000 (MHz) Actual RF Freq: 1000.000000 (MHz) Target DSP Freq: 50.000000 (MHz) Actual DSP Freq: 5.000000 (MHz) >>> # Note the last two lines: The *target* DSP freq was already clipped >>> # to 5 MHz. These lines show 50.0 MHz when this patch is applied. This bugfix is accompanied some related changes: - The unit test is amended to verify the behaviour - The API documentation is amended with details on its behaviour
* python: Add new method bindings to noc_block_baseAaron Rossetto2021-08-301-0/+8
| | | | | This commit adds `get_src_epid()` and `get_port_num()` method bindings to the Python bindings for `noc_block_base`.
* lib: rfnoc: Make implicit typecasts explicitMartin Anderseck2021-08-101-4/+5
| | | | | | Fix implicit typecasts that could potentially lose data. Doing this to show that these typecasts are done on purpose (and to resolve warnings from VS).
* lib: rfnoc: Change enum node_type to enum classMartin Anderseck2021-08-101-23/+25
| | | | | | Fix the "Enum.3: Prefer class enums over "plain" enums" warning for the node_type enum and update the calls to the enumerators as proposed by the C++ Core Guidelines.
* python: rfnoc: Change reference type for noc_block_base exportMartin Braun2021-07-231-54/+64
| | | | | | | | | | | | | By changing the type for accesses to noc_block_base calls in the Python from sptr& to a simple reference (&), we fix the "holder type" issues that crop up when trying to use radio_control from multi_usrp, which returns access to the block as a reference rather than a `sptr`. The error message seen without this fix always contains this string: Unable to cast from non-held to held instance (T& to Holder<T>) (The exact message depends on the API call made).
* rfnoc: allow find_blocks to search by device number or block count.Lars Amsel2021-07-201-3/+3
| | | | | | | | | | | | | In current implementation it is not possible to find all blocks of a device by calling find_blocks("0/"). The same is true for the block count. This is caused by the valid block id regex which requires a block name. This regex is used to validate the block name as well as to match block ids in search. This fix looses the requirement for the block name to allow searches by device number and block count and also extends the is_valid_block_id method to require the block name match to be non empty (which restores the previous behaviour at this point).
* host: Add static_assert to prevent meta_range_t(0,0)Lane Kolbly2021-07-141-2/+2
| | | | | | | meta_range_t(0,0) actually calls the iterator-based constructor for meta_range_t, which is almost certainly not the intended constructor for that call syntax. Therefore, we add a static_assert to prevent such usage, and fix all failing instances.
* uhd: Replace boost::thread::id with std::thread::idMartin Braun2021-07-141-0/+1
| | | | | | | | The Boost version is identical to the std:: version (which is available since C++11) and thus is no longer needed. Because of implicit includes, this breaks compilation in other parts. Appropriate includes were added there also.
* uhd: Remove all occurences of boost::math::*round()Martin Braun2021-06-242-4/+4
| | | | | | | Its behaviour is almost identical to std::lround, which we use instead. The only downside of std::lround is that it always returns a long, which we don't always need. We thus add some casts for those cases to make the compiler happy.
* uhd: Add callback for setting sync_sourcesGrant Meyerhoff2021-06-171-0/+6
|
* uhd: Add support for the USRP X410Lars Amsel2021-06-101-1/+18
| | | | | | | | | | | | | | | | Co-authored-by: Lars Amsel <lars.amsel@ni.com> Co-authored-by: Michael Auchter <michael.auchter@ni.com> Co-authored-by: Martin Braun <martin.braun@ettus.com> Co-authored-by: Paul Butler <paul.butler@ni.com> Co-authored-by: Cristina Fuentes <cristina.fuentes-curiel@ni.com> Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com> Co-authored-by: Virendra Kakade <virendra.kakade@ni.com> Co-authored-by: Lane Kolbly <lane.kolbly@ni.com> Co-authored-by: Max Köhler <max.koehler@ni.com> Co-authored-by: Andrew Lynch <andrew.lynch@ni.com> Co-authored-by: Grant Meyerhoff <grant.meyerhoff@ni.com> Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com> Co-authored-by: Thomas Vogel <thomas.vogel@ni.com>
* rfnoc: Fix post action behavior of nodesLars Amsel2021-06-031-0/+4
| | | | | | | | | | | 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
* rfnoc: Fix MTU prop resolver refactoringAaron Rossetto2021-06-011-8/+70
| | | | | | | | | | | | | | | | | | | | | | | | In 073574e24, the MTU property resolver in `noc_block_base` was refactored to make the resolver's output sensitivity list less broad. The broadness was intentional as a consequence of allowing the MTU forwarding policy to be changed at will, but had the unintended side effect of being incompatible with certain RFNoC graph use cases. The refactoring solved the issues, but added a new restriction that the MTU forwarding policy could only be called once per instance of a NoC block. Unfortunately, that refactoring introduced a bug. By moving the registration of MTU resolvers to `set_mtu_forwarding_policy()`, no resolvers would be added if the MTU forwarding policy was never changed from the default of `DROP` (which is the case for the vast majority of NoC blocks). However, the resolver had code that would run in the `DROP` case to coerce the incoming MTU edge property to be the smaller of the new value or the existing MTU value on that edge. With the resolvers only getting added when the MTU forwarding policy is changed, this coercion behavior would never execute, thus breaking a number of devtests. This commit ensures that the default coercion behavior is always present regardless of whether the MTU forwarding policy is changed or not.
* rfnoc: noc_block_base: Throw if set_mtu_forwarding_policy() called multiplyAaron Rossetto2021-05-181-0/+9
|
* rfnoc: noc_block_base: Refactor MTU prop resolverAaron Rossetto2021-05-181-46/+58
| | | | | | | | | | | | | | | | | | | | | | Prior to this commit, the MTU property resolver in noc_block_base had an issue: for every MTU edge property (both input and output on each port) on the block, the property resolver listed every other MTU edge property in its output sensitivity list, regardless of whether or not the output edge properties would ever be affected by the current MTU forwarding policy. This breaks an inherent (and up until now, unwritten) contract between a property resolver and UHD that only properties that can be affected by the resolver should be included in the output sensitivity list. The result of breaking the contract leads to errors being thrown when committing an RFNoC graph in certain multi-channel use cases. This commit refactors the MTU property resolver to use the MTU forwarding policy to determine the correct set of edge properties to include in the output sensitivity list. The change also introduces a new restriction--the MTU forwarding policy may only be set once per instance of a noc_block_base. Typically, a subclass implementing an RFNoC block will call `set_mtu_forwarding_policy()` in its constructor to set a custom MTU forwarding policy (if desired) and leave it untouched for the lifetime of the block.
* RFNoc: Fix graph connect timeout errorMichael West2021-05-101-2/+3
| | | | | | | | | A loop in mgmt_portal::_validate_stream_setup() was missing a sleep, which was causing it to return long before the timeout with a timeout error. This change adds that sleep and reduces the duration of the sleep so it responds faster. Signed-off-by: Michael West <michael.west@ettus.com>
* rfnoc: Add option to disable flow control on rx streamingmattprost2021-04-292-8/+15
| | | | | | | | | | | Disabling this feature will allow the USRP to send a continuous stream of Rx data to a host machine without throttling due to lack of flow control credits. This is unnecessary overhead on lossless transports such as pcie or aurora. Usage: add 'enable_fc=false' to stream_args.args Signed-off-by: mattprost <matt.prost@ni.com>
* rfnoc: radio: Add getter for SPC valueMartin Braun2021-03-192-0/+6
| | | | | | This adds uhd::rfnoc::radio_control::get_spc(). It can be overridden by radio implementations, but radio_control_impl has a sensible default implementation, return the value that is in the SPC radio register.
* uhd: Fix radio_control-related method constnessMartin Braun2021-03-171-2/+2
| | | | | | | | | | | | | | | | | The const-ness of some radio_control differed between base class and implementation. This fixes the consistency, but also makes sure these methods follow the rules for when to make methods 'const'. The following rules apply: - Methods that query static capabilities are const. Here, we made get_tx_lo_sources() const (the RX version was already const). - Getters that may have to interact with the device (e.g., peek a register) are not const, because the act of peeking is usually also non-const. Here, we changed get_rx_lo_export_enabled() to non-const. - All base classes are fixed such that the derived classes and the base classes have the same const-ness. Clang was warning about differences. This can cause very tricky bugs, where the radio_control_impl version can get called instead of the intended child class.
* host: Update code base using clang-tidyMartin Braun2021-03-171-2/+2
| | | | | | | | | | | | The checks from the new clang-tidy file are applied to the source tree using: $ find . -name "*.cpp" | sort -u | xargs \ --max-procs 8 --max-args 1 clang-tidy --format-style=file \ --fix -p /path/to/compile_commands.json Note: This is the same procedure as 107a49c0, but applied to all the new code since then.
* lib: Remove move-on-return for chdr_packet_writerMartin Braun2021-03-113-5/+5
| | | | This is a pessimizing move, and clang warns about it.
* lib: Fix warnings related to unnecessary lambda capturesMartin Braun2021-03-048-13/+23
|
* lib: Remove unused constantsMartin Braun2021-03-042-6/+5
| | | | | The constants were either commented out, when their value is still useful to the reader, or removed if not.
* host: Update code base using clang-tidyMartin Braun2021-03-0422-266/+270
| | | | | | | | | The checks from the new clang-tidy file are applied to the source tree using: $ find . -name "*.cpp" | sort -u | xargs \ --max-procs 8 --max-args 1 clang-tidy --format-style=file \ --fix -p /path/to/compile_commands.json
* uhd: lambda capture the node instead of vert descSteven Koo2021-01-211-4/+14
| | | | | | | | | | | 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>
* rfnoc: Update radio to support multiple SPCWade Fife2021-01-111-4/+10
|
* rfnoc: Add accessors for item width and nipc for NSSWade Fife2021-01-112-0/+23
| | | | | | - Add get_item_width() and get_nipc() methods to the Null/Source/Sink block controller. - Add missing enumerated types for get_count() method.
* uhd: Split radio_control into rf_control interfacesLane Kolbly2021-01-114-20/+98
| | | | | | These rf_control interfaces allow easier implementation of radio controls as well as allowing easier sharing of code for implementing e.g. gain_profile.
* rfnoc: Fix remote stream buffer formatWade Fife2020-12-211-0/+18
| | | | | | | | When configuring remote streams, we were setting the format at the source stream endpoint, but not at the destination stream endpoint. Therefore, the destination used the default or whatever it was set to during a previous run. This change sets the format at the destination stream to match the format of the source stream.
* rfnoc: Fix time conversion in ctrlport_endpoint sleep methodCiro Nishiguchi2020-12-211-2/+4
|
* RFNoC: Demoted zero sample error to warningmichael-west2020-12-101-2/+3
| | | | | | | | Requesting zero samples was resulting in an error and causing applications to crash. This was a change frome previous versions of UHD. Demoted to warning so applications continue as they did before. Signed-off-by: Michael West <michael.west@ettus.com>
* graph: Restore default resolver callback at node removalAaron Rossetto2020-11-202-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* DUC: Fix incorrect DDS_GAINmichael-west2020-10-261-1/+1
| | | | | | | Fixes incorrect value for the DDS_GAIN that was causing the TX output power to be 6 dB lower than it was supposed to be. Signed-off-by: michael-west <michael.west@ettus.com>
* graph: Serialize all graph-related functionsAaron Rossetto2020-10-221-6/+11
| | | | | | | | 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.
* graph: Re-fetch dst_node descriptor after src_node potential removalAaron Rossetto2020-10-221-0/+3
| | | | | | | | | | | | | | | | | 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.
* fixup! rfnoc: Fix thread unsafe accesses in ctrlportCiro Nishiguchi2020-10-201-7/+5
|