aboutsummaryrefslogtreecommitdiffstats
path: root/host
Commit message (Collapse)AuthorAgeFilesLines
* tools: Add missing fields to CHDR dissectorWade Fife2021-12-081-0/+3
| | | | | | | | | | | | - Add data packet payload field - Add metadata support - Add missing management fields (OpsPending, ExtendedInfo). - Add missing control fields (byte_enable, data, has_time) - Update offsets for management OpPayload fields. - Make the field names more consistent, readable, and consistent with the RFNoC specification. - Display value of fields in addition to name. - Fix timestamp, eob, and eov offsets
* rfnoc: Add ops pending to management opWade Fife2021-12-082-3/+12
| | | | | | 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.
* cmake: tests: Conditionally compile tests for X400Martin Braun2021-12-081-30/+32
| | | | | When using ENABLE_X400=OFF, we should also disable the corresponding tests, or we get linker errors.
* docs: Remove obsolete man pagesMartin Braun2021-12-083-112/+0
| | | | | | The man pages for usrp_x3xx_fpga_burner and octoclock_firmware_burner are obsolete; the corresponding utilities were replaced by uhd_image_loader many UHD versions ago.
* rfnoc: Fix noc_shell direction commentsWade Fife2021-12-083-5/+5
| | | | | | Some comments describing data flow direction were wrong. This commit updates the Mako files and updates the noc_shell modules with newly generated versions.
* tests: Remove non-functional DPDK testAndrew Lynch2021-12-061-97/+2
|
* dpdk: disable warnings for using an experimental featureAndrew Lynch2021-12-061-0/+6
|
* docs: Update DPDK documentationAndrew Lynch2021-12-061-13/+37
|
* dpdk: Upgrade to DPDK 19.11 APIAndrew Lynch2021-12-0612-129/+129
| | | | 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.
* docs: Improve documentation for properties and -propagationMartin Braun2021-12-038-2/+498
|
* 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-032-3/+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-022-5/+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-0221-96/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* examples: Improve rfnoc_rx_to_fileMartin Braun2021-12-011-112/+143
| | | | | | | | | | | | | | | This example had some major issues since UHD 4, which are now fixed. Mainly, the option to include a custom RFNoC block was not working. The example was rehauled severely: - Custom blocks are now usable again. - UHD/RFNoC code is used for the connections, rather than a custom kludge. - Sample rate is set via property propagation - boost::format() was not helpful in this example, and was removed. - A list of active connections is now printed - The --block-args argument is dropped in favour of --block-props. The former never did anything useful, and "block args" are a UHD 3 thing.
* rfnoc: Add more comments to rfnoc_graphMartin Braun2021-12-011-0/+14
| | | | | This adds some more explanatory comments around active and static connections.
* 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.
* tests: add automated streaming testsMatthew Crymble2021-11-303-0/+382
|
* tests: add streaming setup script for performance enhancementsMatthew Crymble2021-11-301-0/+288
| | | | | | | | | This script is intended to be run before streaming. - Manages network interfaces, memory buffers, and other aspects of the system configuration to give the host machine ideal performance during streaming. - Installs/updates dpdk/util dependencies for the script - Generates and writes uhd config files for dpdk
* 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>
* host: Add ability to get time from Radio blockmichael-west2021-11-173-1/+43
| | | | | | Add API calls to Radio control to get ticks and time. Signed-off-by: michael-west <michael.west@ettus.com>
* tests: Remove skip_dram from streaming performance test scriptMartin Braun2021-11-161-2/+2
|
* docs: Several minor manual improvementsMartin Braun2021-11-166-10/+49
| | | | | | | - Remove documentation of skip_dram, skip_ddc, skip_duc, which are all obsolete since UHD 4 - Properly document serialize_init - Add a table of valid args for X310 as with other devices
* examples: Use cmul for gain block in-tree IP exampleWade Fife2021-11-151-21/+18
|
* 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-126-1/+15
| | | | | | | 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.
* rfnoc: Make chdr_w_to_bits() C++11-compatibleMartin Braun2021-11-121-0/+15
| | | | | | | This allows consumers of UHD compiling with C++11 to include this file (which is now included via noc_block_base) by turning a switch statement into a functionally equivalent (albeit less readable) nested ternary statement.
* tests: Fix rfnoc_graph mock nodes stop-stream commandMartin Braun2021-11-121-1/+1
| | | | Thanks to Github user johnwstanford for pointing this out.
* B200: Re-sync timesmichael-west2021-11-102-10/+31
| | | | | | | | | | The times on the device can glitch if either the tick rate changes or the number of active chains changes. This throws off the time if the user gets streamers, changes the sample rate, or changes the tick rate after synchronizing the time. This change re-synchronizes the times automatically in those cases. Signed-off-by: michael-west <michael.west@ettus.com>
* python: multi_usrp: Add set_rx_spp()Wade Fife2021-11-091-0/+1
|
* doc: x4xx: Document configuring eth0 static IPLane Kolbly2021-11-091-1/+28
|
* mpmd: Increase UHD-side MTU cap for 10 GbE and 1 GbEMartin Braun2021-11-081-4/+14
| | | | | | | | | This gets closer to what our hardware can actually support. See the comments for further explanations. This has the side-effect of patching an issue on X410 (using 200 MHz images) where garbage samples would get injected (one per packet). It is not, however, the final fix for that problem.
* docs: x410: Document GPIO API and capabilitiesLane Kolbly2021-11-054-0/+251
|
* docs: Collect all RFNoC block controllers in a module in the manualMartin Braun2021-11-0519-2/+51
| | | | | | This lets Doxygen create a page in the UHD manual that lists all RFNoC block controllers. It will be accessible under Manual -> Modules -> RFNoC -> RFNoC Blocks shipped with UHD.
* rfnoc: blocks: Minor cleanup (whitespace, typos)Martin Braun2021-11-056-13/+5
|
* host: python: Add gpio_voltage python APILane Kolbly2021-11-051-1/+11
|
* host: Add gpio_voltage discoverable featureLane Kolbly2021-11-054-0/+147
|
* host: Add RPC calls for GPIO voltageLane Kolbly2021-11-052-1/+30
|
* examples: Test all variants in gain testbenchWade Fife2021-11-043-15/+61
|
* examples: Make IQ order clear in gain RFNoC blockWade Fife2021-11-041-16/+25
|
* host: python: Return mb_controller with reference_internalLane Kolbly2021-11-041-1/+1
|
* fixup! host: x4xx: Implement GPIO APILane Kolbly2021-11-031-2/+14
|
* example: gpio: Separate bank and port argumentsLane Kolbly2021-11-031-10/+18
| | | | | | | "bank" refers to what the radio control sees, and "port" refers to what the user looking at the physical device sees. For example, on X410 each radio control only has a single (24-bit) output, which can be routed to either of two ports.
* host: x4xx: Implement GPIO APILane Kolbly2021-11-036-0/+257
| | | | | | | | | | | | This implements the GPIO API for X410 through get_gpio_attr and set_gpio_attr. In ATR mode, which channel's ATR state is chosen by the set_gpio_src call, setting e.g. DB0_RF0 for channel 0 or DB0_RF1 for channel 1. In manual mode, all 24 bits (for both ports) are set in a single register write. Although the front panel of the device has two ports, labelled GPIO0 and GPIO1, this API exposes them as though they were a single 24-bit GPIO port.
* host: Add GPIO functions to MPM RPC shimLane Kolbly2021-11-032-0/+20
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 21:39:46 +0000