aboutsummaryrefslogtreecommitdiffstats
path: root/host/lib
Commit message (Collapse)AuthorAgeFilesLines
* host: x4xx: gpio: Properly unmap FPGA GPIO valuesLane Kolbly2022-01-242-39/+44
| | | | | | The FPGA GPIO registers don't exactly match the pin numbering on the front panel and in the docs. This commit changes the algorithm so that the API presented to the user matches the front panel.
* rfnoc: Ignore errors in ctrlport response packets if ACKs not wantedAaron Rossetto2022-01-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 0caed5529, a change was made to ctrlpoint_endpoint's behavior such that if a client does not care about checking for ACKs on poke or poll operations, the code calls `wait_for_ack()` with a flag indicating that it should not wait for the ACK, but find and remove the corresponding response from the response queue. This prevents the queue from potentially growing endlessly with response packets that the client doesn't even care about. However, this introduced a subtle, undesired behavioral change. When `wait_for_ack()` finds the corresponding response for a request, it also checks the status field of the response to report any errors flagged by the hardware such as invalid command, routing error, etc. Prior to the change mentioned above, since `wait_for_ack()` was never called when the client doesn't want ACKs, the client would never be never notified of any errors associated with the request. However, with the aforementioned change in placd, when `wait_for_ack()` is called to find and remove the unwanted response packet corresponding to the request, errors **are** checked and reported up the user. The behavior change was unearthed by the X410 ZBX CPLD initialization code, which writes an initial value of 0 to all ZBX CPLD registers--even read-only registers. A control request to write a read-only register results in a response with CMDERR in its status field, as it should. However, since the ZBX CPLD register initialization is performed with a `poke32()` operation which by default doesn't wait for ACKs, this was never a problem until the change to drain the response queue inadvertently caused the error to surface. The result is that creating a USRP session or RFNoC graph session to an X410 device is seen to occasionally fail with a 'RuntimeError: RuntimeError: Failure to create rfnoc_graph' message printed to the console. This commit preserves the desired queue-draining behavior, but ignores any error status on the response when it is found and removed from the queue, thus restoring the behavior pre-0caed5529.
* host: fix build with DPDK v21.11 LTSLuca Boccassi2022-01-205-43/+94
| | | | | | | | | | | | | Some APIs were changed with the latest DPDK LTS release, add some ifdefs to fix the build. Fixes https://github.com/EttusResearch/uhd/issues/547 Updated CMake file to reflect updated DPDK version. Fixed mbuf size to take ethernet headers into account. Updated documentation. Co-authored-by: Martin Anderseck <martin.anderseck@ni.com>
* host: Implement nameless_gain_mixinLane Kolbly2022-01-206-83/+150
|
* lib: set dynamic_lookup and flat_namespaceSteven Koo2022-01-191-3/+4
| | | | | | This resolves some linking issues across binaries. Signed-off-by: Steven Koo <steven.koo@ni.com>
* tests: disable x4xx_radio_block_test on macOSSteven Koo2022-01-191-0/+1
| | | | | | | | This commit disables x4xx_radio_block_test on macOS because the platform has stricter casting and symbol export rules, which causes this test to fail. Signed-off-by: Steven Koo <steven.koo@ni.com>
* lib: Make simple_claimer atomicMartin Braun2022-01-141-38/+19
| | | | | | | | | | | | | | | This fixes multiple issues: - The simple_claimer was not truly atomic, it tested and set the locked-flag on separate lines - It used a Boost yield statement, although we're not running Boost threads - It used the deprecated UHD_INLINE macro We also remove spin_wait_with_timeout(), which was only used in claim_with_wait() because it's not worth putting into its own function. This is no API change on simple_claimer, but it may result in different performance of this spinlock.
* deps: rpclib: Replace distutils.dir_util with shutilAaron Rossetto2022-01-141-2/+1
| | | | | This commit replaces the use of distutils.dir_util.copy_tree() with the equivalent function shutil.copytree().
* SPI: Implement SPI engine for x410Martin Anderseck2022-01-138-15/+366
| | | | | Add SPI Core host implementation for x410 and a discoverable feature to make it accessible.
* rfnoc: Always clear response queue in ctrlport_endpointMartin Braun2022-01-131-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the behaviour of ctrlport_endpoint (the register interface for block controllers) to always check for an ACK after doing a poke or poll of any kind. Previously, the behaviour was to only check for an ACK if the policy was set that way, or if the user requested the ACK to be received. The problem with the former approach was that if many pokes were performed without ever requesting an ACK or a poll, the response queue would fill up without ever getting emptied, eventually draining the available heap space. Note that this is not a memory leak in the usual sense, as the response queue was correctly holding on to the response packets. With this change, ctrlport_endpoint::wait_for_ack() now receives a require_ack parameter. If it is false, the behaviour of wait_for_ack() is changed as follows: - If the response queue is empty, immediately return with an empty response payload object. - Otherwise, continue reading elements out of the response queue until it is either depleted (in which case the previous rule kicks in), or we find the ACK corresponding to the command previously sent out. Note that this replicates the corresponding behaviour in UHD 3 (see ctrl_iface_impl::wait_for_ack()).
* uhd: Fix non-standard function name macrosMartin Braun2022-01-124-7/+9
| | | | | | | | | | | | | | | | | Throughout UHD, we are using a random mix of __FUNCTION__, __func__, __PRETTY_FUNCTION__, and BOOST_CURRENT_FUNCTION. Note that the first two macros are non-standard (although many compilers understand them), and the last requires Boost. __func__ is available since C++11, but is not the best choice because the C++ standard doesn't require it to be of any specific value. We thus define UHD_FUNCTION and UHD_PRETTY_FUNCTION as portable macros. The former simply contains the undecorated function name, the latter the expanded function with full signature. As it happens, our currently supported compilers didn't have any issues using non-standard macros, so the main fix here is the removal of the Boost macros and the harmonization of the other macros.
* x300: Fix LED configuration for TwinRXMartin Braun2022-01-111-13/+53
| | | | | | | | | | | | | | The problem was that TwinRX has a special LED configuration (unlike most other daughterboards): Since it has two channels, it is possible to stream RX from both SMA ports. In that case, we would light up both LEDs in green (which was not happening, only one LED would light up, depending on which antenna was set last). This fixes the problem and turns on both LEDs when both channels are used, and both SMA ports are selected. Note that the reason for this issue was an incorrect porting of this code from UHD 3. There, we had separate LED ATR objects per channel.
* x300: clang-formatMartin Braun2022-01-1110-61/+65
|
* e3xx: Fix frequency queryingMartin Braun2022-01-101-2/+11
| | | | | | | The E3xx devices have one LO per TX/RX, respectively. That means when changing the frequency on channel 0, the frequency on channel 1 also gets changed. The code didn't track this change properly: When setting channel 1, channel 0's frequency didn't match.
* RFNoC: Fix DSP frequency accuracymichael-west2022-01-104-12/+26
| | | | | | | | | | The host code was calculating and programming a 32-bit value for the DSP frequency, but the DDS modules in the FPGA only use the upper 24-bits. This led to inaccurate frequency values being returned. This change corrects the resolution of the value on the host side so an accurate value is returned. Signed-off-by: michael-west <michael.west@ettus.com>
* rfnoc: Add atomic item size property for RFNoC blocksLars Amsel2022-01-108-10/+115
| | | | | | | | | | | | | | | 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: transport: Check if streamers are connected in send() and recv()Martin Braun2022-01-102-2/+40
| | | | | | | | | | | | | | | | This adds a check in send() and recv() whether or not the streamer is actually connected. If not, an exception is thrown with the message: [rx_stream] Attempting to call recv() before all channels are connected! or [tx_stream] Attempting to call send() before all channels are connected! The check is a single boolean flag check, but it does add a branch in our hot code. Since this event is unlikely, and only happens in badly configured apps, we will get some help from the CPUs branch prediction to reduce the additional cost of this check.
* host: multi_usrp: Merge set_tx_subdev_spec and set_rx_subdev_specLane Kolbly2022-01-101-99/+67
| | | | | This change simply refactors these methods so that the core of the algorithm is no longer duplicated between them.
* rfnoc: ddc/duc: Improve variable name for _set_freq()Martin Braun2022-01-072-4/+4
| | | | | | | | As Github user johnwstanford points out, the DUC calls the argument 'input_rate', which is wrong (and was copy/pasted from the DDC code). By calling it dds_rate in both cases, we avoid such confusion. This commit only renames a variable. No changes whatsoever.
* lib: SSPH: Fix comment for convert_to_in_buff()Martin Braun2022-01-071-2/+1
| | | | | | | As Github user dylan-baros points out, the comment is copy/pasted from the SRPH. Only comment changes here.
* 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: Add divider constructor to spi_config_tLane Kolbly2022-01-061-0/+9
|
* host: rf_control: Add internal antenna API abstraction.Lane Kolbly2022-01-055-49/+202
|
* host: Make core_iface inheritence virtualLane Kolbly2022-01-051-1/+1
|
* host: Implement operator<< for data_reader_tLane Kolbly2022-01-051-0/+7
|
* lib: Remove superfluous includes of udp_zero_copy.hppMartin Braun2022-01-052-2/+0
|
* uhd: Remove tcp_zero_copyMartin Braun2022-01-052-250/+0
| | | | | This removes the tcp_zero_copy interface, which is not supported by any USRP.
* host: Add char* overload for device_addr_tLane Kolbly2022-01-052-6/+6
| | | | | | | This allows constructing a multi_usrp using a string constant: ``` auto usrp = uhd::usrp::multi_usrp::make("type=x4xx"); ```
* dpdk: correct MTU warning messageAndrew Lynch2021-12-171-1/+1
|
* rfnoc: graph: make topology failure more descriptivemattprost2021-12-171-4/+41
| | | | | | | | Clarify that invalid RFNoC graph topology failures are due to an attempt to access input or output ports that are not connected to anything in the FPGA. Signed-off-by: mattprost <matt.prost@ni.com>
* dpdk: support new MTU discoveryAndrew Lynch2021-12-171-4/+4
|
* rfnoc: Fix block_id::get_tree_root()Martin Braun2021-12-161-1/+1
| | | | | The path it returned was only valid in UHD 3. Added unit test to confirm.
* host: Make radio_control constants an enumLane Kolbly2021-12-102-108/+82
| | | | | | | 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: Fix back-edge consistency checkMartin Braun2021-12-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On back-edges, no properties are forwarded, but properties must be consistent after property resolution. This breaks when the source edge on a back-edge has an edge property which the destination block does not. Consider the following graph: DDC -> Replay -> DDC where both instances of 'DDC' refer to the same block. Now, assume the first edge is declared a back edge (in principle, it shouldn't matter). The DDC block has an edge property `samp_rate` which the Replay block does not. Therefore, it can't forward this edge property to the Replay block's input edge property list. In the consistency check code, we don't check for the existence of edge nodes, because it is assumed edge properties where either forwarded, or aligned through some other manner. This leads to a property lookup failure. With this fix, we skip the consistency check for edge properties which don't exist on the destination node. This is safe because the destination block can not have a property resolver defined for undefined properties. This means the destination block can either: - Drop the property. In this case, there is no value in checking consistency. Even if we could forward edge properties on back-edges, they would always have the same value. - Forward the property. In that case, the consistency check would happen elsewhere in the graph where there's no back-edge.
* host: Fix typos and small thingsLane Kolbly2021-12-092-1/+2
|
* e3xx: Remove unused constantMartin Braun2021-12-091-2/+0
|
* rfnoc: Add ops pending to management opWade Fife2021-12-081-1/+2
| | | | | | The ops pending for each operation was stored implicitly in the data structure. This adds it explicitly, which is useful for debugging and packet dissection.
* dpdk: disable warnings for using an experimental featureAndrew Lynch2021-12-061-0/+6
|
* dpdk: Upgrade to DPDK 19.11 APIAndrew Lynch2021-12-0610-126/+126
| | | | Support DPDK versions 19.11 and 20.11
* rfnoc: Enable drop counter on chdr_ctrl_endpointMartin Braun2021-12-032-4/+23
| | | | | | | | | | | | This class has a member _num_drops, which can be read out using the get_num_drops() API call. However, when dropping packets, this counter was not incremented, which is fixed now. This also includes a very minor optimization from 2 map<> lookups to 1 lookup (they are in O(log N)). Since there are usually a small two-digit number of endpoints connected to the async message receiver, this change is not expected to yield major improvements, but the lookup *is* in a hot loop.
* max287x: Fix key in table of freq rangesMartin Anderseck2021-12-031-1/+1
| | | | | | The keys for the table of frequency ranges for each VCO value counts up consecutively but key "1" was there twice while "2" was missing. This is fixed here.
* uhd: Remove superfluous boost/bind.hpp includesMartin Braun2021-12-031-1/+0
| | | | | On newer versions of Boost, they show deprecation notes. However, they're not actually used any more so they can go.
* 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.
* mpmd: Add MTU plausibility checkMartin Braun2021-12-021-0/+42
| | | | | | | | | | | | | | | | | | We have noticed that on 1 GbE connections, MTU discovery can become unreliable. Since we now use the MTU directly for deriving spp and other values, a correct MTU is important. Because we don't have a way of knowing if MTU discovery worked or not, we add some heuristics in form of a plausibility check. For now, the only rule in this check is if that the detected MTU is a bit larger than 1472 bytes, we coerce down to 1472, because this is such a standard value (most 1 GbE interfaces default to an IPv4 MTU of 1500 bytes). For the cases where the interface MTU is set to be between 1500 and 1528 bytes, this would cause a very minor performance loss. We accept this performance loss as it is small, and those cases are very rare. MTUs are usually 1500 bytes, or >= 8000 bytes for high-speed links using jumbo frames.
* x300: Remove usage of CHDR_MAX_LEN_HDRMartin Braun2021-12-021-2/+6
| | | | | | | This constant was generally harmful, since it was only correct under certain circumstances (64 bit CHDR with timestamps). The X3x0 code was the last place it was being used, and we remove it without substitute because it was not doing anything useful here.
* rfnoc: Clarify usage of MTU vs. max payload size, remove DEFAULT_SPPMartin Braun2021-12-0213-74/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix issue in uhd::rfnoc::connect_through_blocks()Martin Braun2021-12-011-6/+9
| | | | | | | | | | | | | | | | | | | | | | | When connect_through_blocks() was called on blocks within a single chain, there was a bug where the chain was incorrectly cropped. In a standard FPGA image, say one was to use this API call to connect the radio to the DDC. It would generate a chain of blocks hanging off the radio as such: Radio -> DDC -> SEP What the code should do, and what this fix provides, is that the chain gets cropped after the DDC, to look like this: Radio -> DDC With the current bug, it would assume the chain has a dangling edge, and incorrectly throw an exception. Note that this bug would not appear when source and destination block are on separate chains (i.e., both have an SEP in their chain). This patch includes minor logging and comment improvements around the offending lines of code.
* 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-172-10/+10
| | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-04 01:22:22 +0000