aboutsummaryrefslogtreecommitdiffstats
path: root/host/lib/rfnoc/radio_control_impl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* rfnoc: Add atomic item size property for RFNoC blocksLars Amsel2022-01-101-0/+37
| | | | | | | | | | | | | | | An RFNoC block (like the radio) might require a minimal number of items in each clock cycle, e.g. the radio has to process SPC (samples per cycle). Because data in RFNoC is transmitted and processed in packets, we have to make sure the items inside these packets are a multiple of the items processed in each cycle. This commit adds an atomic item size properties which is set by the radio and adapted by the streamers. The streamers adapt the SPP property of the radio block controller depending on the MTU value. This might lead to an SPP value which does not align with the SPC value of the radio block, hence we add a property resolver for the atomic item size.
* rfnoc: radio: Fix comment in radio_control_implMartin Braun2022-01-071-1/+1
| | | | | As Github user johnwstanford kindly points out, the comment was incorrect.
* host: Make radio_control constants an enumLane Kolbly2021-12-101-28/+0
| | | | | | | In C++, variables whose address are taken must be defined somewhere. PERIPH_BASE had no such definition, so on some compilers/systems caused a linker error. This commit switches to using enums to prevent this happening again in the future.
* rfnoc: Clarify usage of MTU vs. max payload size, remove DEFAULT_SPPMartin Braun2021-12-021-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 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>
* 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.
* 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.
* rfnoc: radio: Add getter for SPC valueMartin Braun2021-03-191-0/+5
| | | | | | 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.
* lib: Fix warnings related to unnecessary lambda capturesMartin Braun2021-03-041-0/+1
|
* rfnoc: Update radio to support multiple SPCWade Fife2021-01-111-4/+10
|
* uhd: Split radio_control into rf_control interfacesLane Kolbly2021-01-111-20/+16
| | | | | | 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: 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>
* uhd: Add APIs for getting the available power rangeMartin Braun2020-08-171-0/+18
| | | | | | | | | The previously added APIs for getting/setting power reference levels was missing an option to read back the currently available power levels (minimum and maximum power levels). This adds getters for TX and RX power ranges to multi_usrp and radio_control. The power API is thus now more similar to the gain API, which always had getters for gain ranges.
* RFNoC: Demote MTU message in radio controlmichael-west2020-08-041-1/+1
| | | | | | Change message from warning to debug when spp is greater than MTU. Signed-off-by: michael-west <michael.west@ettus.com>
* radio_control: Provide default implementations for ref power APIsMartin Braun2020-06-101-22/+39
| | | | | | | | The various implementations for the reference power APIs are always the same, assuming the existence of a pwr_cal_mgr object. We therefore store references to power cal managers in radio_control_impl, which radios can choose to populate. The APIs then don't have to be reimplemented in the various radio classes, unless they want to for whatever reason.
* python: Add radio RFNoC block controller bindingsAaron Rossetto2020-06-091-1/+0
|
* rfnoc: radio: Add APIs to query cal keysMartin Braun2020-05-201-0/+10
| | | | | | | | This allows asking the radio for the keys it uses to read/write its calibration data. By querying radio_control::get_{rx,tx}_power_ref_keys(), the return values can be used to access uhd::usrp::cal::database::read_cal_data().
* uhd: Add reference power level API to multi_usrp and radio_controlMartin Braun2020-04-171-0/+36
| | | | | | | | | | | | | | | | | | This adds the following API calls: - multi_usrp::has_{rx,tx}_power_reference() - multi_usrp::set_{rx,tx}_power_reference() - multi_usrp::get_{rx,tx}_power_reference() - radio_control::has_{rx,tx}_power_reference() - radio_control::set_{rx,tx}_power_reference() - radio_control::get_{rx,tx}_power_reference() It also adds a manual page explaining the philosophy of the API. Note that this does not actually add this feature to any device implementation. Calling the new API calls will thus result in `uhd::not_implemented_error` exceptions being thrown. This commit is to lock down the API and ABI.
* fixup! rfnoc: Use multichannel register interface for RFNoC blocksmattprost2020-04-071-3/+3
|
* rfnoc: Use multichannel register interface for RFNoC blocksmattprost2020-04-021-30/+31
| | | | | | | | Allows RFNoC blocks to perform register peeks and pokes on blocks with multiple channels without having to worry about handling register address translation every time. Signed-off-by: mattprost <matt.prost@ni.com>
* uhd: Apply clang-format against all .cpp and .hpp files in host/Martin Braun2020-03-031-15/+23
| | | | | Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of files that clang-format gets applied against.
* rfnoc: actions: Cleanup rx_event_action_info ctorsteviez2020-02-181-6/+5
| | | | | Set error code member variable in rx_event_action_info constructor instead of relying on the caller to set it after object creation
* rfnoc: actions: Fix uninitialized timestampssteviez2020-02-181-3/+3
| | | | | | tx_event_action_info objects were being created with uninitialized timestamp members which led to uhd::tx_streamer::recv_async_msg() returning with invalid timestamps
* rfnoc: radio: Add API call to disable timestampsMartin Braun2019-11-261-0/+5
| | | | | By calling radio_control::enable_rx_timestamps(false, chan), the radio will not add timestamps to outgoing packets.
* rfnoc: radio: Interpret MTU as max payload sizeMartin Braun2019-11-261-3/+3
| | | | This matches the streamer code.
* rfnoc: Add multi_usrp_rfnoc, modify multi_usrpBrent Stapleton2019-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a separate version of multi_usrp for RFNoC devices. It is compatible with RFNoC devices only, and prefers C++ APIs over property tree usage. The factory of multi_usrp is modified such that it picks the correct version, users of multi_usrp don't care about this change. This also introduces some API changes: - Removing redundant GPIO functions. Now all GPIO control, setting, and readback is done with uint32_t's. - Adding getter/setter for GPIO source. This was done to simplify the other GPIO settings, as the source for each pin is not always a binary. The CTRL mode, for example, can either be ATR or GPIO. However, the source can be controlled by various radios or "PS" or some other source. - Removing the mask from the RFNoC radio controllers' set_gpio_attr(). - Adding state caching to gpio_atr_3000, and a getter for it. Whenever an attribute is set, that value is cached, and can now be retreieved. - Remove low-level register API. Since UHD 3.10, there is no USRP that implements that API. Modifying the filter API in the following ways: - Splitting filter API getter/setter/list into separate RX and TX functions - Adding channel numbers as an argument - The filter name will no longer be a property tree path, but rather a filter name. For RFNoC devices, this will take the form `BLOCK_ID:FILTER_NAME`. For non-RFNoC devices, this will just be the filter name (e.g. `HB_1`) - Removing search mask from listing function. Users can do their own searching Co-Authored-By: Martin Braun <martin.braun@ettus.com>
* rfnoc: radio/streamer: Handle late commands and burst ACKsMartin Braun2019-11-261-0/+16
| | | | | | | - Burst ACKs are already handled by the TX streamer, but the radio now also sends an action upstream on reception of a burst ACK - Late commands were only acquitted by an 'L', now an action gets sent downstream and is handled in the rx streamer
* rfnoc: Implement flushing on overrunCiro Nishiguchi2019-11-261-15/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This modifies the overrun handling such that the RX streamer does not restart the radios until the packets that were buffered prior to the overrun are read by the user. When an RX streamer receives an overrun, it will run the following algorithm: 1. Stop all upstream producers. 2. Set an internal flag in the streamer that indicates that the producers have stopped due to an overrun. 3. Continue servicing calls to recv until it runs out of packets in the host buffer (packets that can be read from the transport using a 0 timeout). 4. Once the packets are exhausted, return an overrun error from recv. The radio, if it was in continuous streaming mode before the overrun, includes a flag in its initial action whether or not to restart streaming. 5. If the radio requested a restart, 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. 6. 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.
* rfnoc: tx_streamer: add support for async messagesCiro Nishiguchi2019-11-261-2/+14
| | | | | | Add an async message queue that aggregates errors from multiple sources. Errors can come from the strs packets originating from the stream endpoint or from the radio block through control packets to the host.
* rfnoc: radio: Add async message validationMartin Braun2019-11-261-0/+48
| | | | | This adds a method to the radio to check if an async message is valid, which can be used to ack async messages immediately.
* rfnoc: radio: Introduce coerce_rate() methodMartin Braun2019-11-261-3/+8
| | | | | This is a helper method for property resolution, where set_rate() is not appropriate.
* rfnoc: Add MTU trackingMartin Braun2019-11-261-1/+11
| | | | | | | | | | | | | | | | | 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).
* rfnoc: Implement overrun handling using action APIMartin Braun2019-11-261-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* rfnoc: radio: Remove async message registers for timestampMartin Braun2019-11-261-8/+5
| | | | These are no longer used.
* rfnoc: async message: Include timestamp in async message handlingMartin Braun2019-11-261-5/+10
| | | | | | | | | 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.
* rfnoc: radio_control: Add async message handlerMartin Braun2019-11-261-14/+102
| | | | | | | 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.
* rfnoc: Add radio block controllerMartin Braun2019-11-261-0/+771