Update UHD #7
Open
Update UHD #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Corrected tested Fedora versions to 37, 38 (was 34, 35, 36) - Removed duplicate changelog for 4.7.0.0 in debian changelog
- The regular color was set to black, which would not read well on dark terminals. It now uses the default - Some other colors were adapted. Some effort was made to make 'debug' not stand out, but that always depends on the terminal color theme that is chosen.
Co-authored-by: Virendra Kakade <[email protected]>
- point to python3 - Fix linter & autoformatting issues
Hat tip to usrp-users member Chris, who reported that the previous order would cause build issues on mingw64.
- This change requires UHD 4.7, but since we ship the example together with UHD, we simply change that to match the UHD version - Bitfiles now get put into the build/ directory. All other FPGA build artifacts get put into subdirs under build/. All assuming bitfiles are built using 'make'. - The X310 example image core is adapted to not produce warnings about unconnected ports, same as within UHD (these warnings are new starting with UHD 4.7).
This is a combination of running include-what-you-need for clang14 on the files in host/include with a manual vetting process. As these are exposed header files, this seems like the most valuable are to fix missing includes. The manual vetting process consists of: - Making sure iwyu uses <> includes consistently with our codebase (it sometimes uses "" includes instead) - For boost includes, do the "normal" inclusion (e.g., include boost/optional.hpp instead of just all the individual sub-includes that are required) for better cross-Boost-version compatibility - Prefer cstddef over stddef.h
The fancy output generated by the image builder can cause issues with scripts that use the output of the image builder. In any case, the standard behaviour for command line tools is to not color output when on non-TTYs, so we adopt the same behaviour here by default. For full control, the new --color option can be used to force color on and off. It follows the same scheme as `ls --color` (can be always, auto, or never). Out of precaution, we also use different markers for warnings and errors when not using color (i.e., no UTF8 symbols). This commit also removes a `staticmethod` decorator which causes issues with Python 3.8 and 3.9.
Edited LO Frequency to RF Frequency in the DSP tuning section on Tuning Notes
This tool worked with Python3, but used a lot of Python2-isms. This makes it proper Python3 script. - Fix linter and autoformatting - Newlines are forced to be \n
…version we ship currently
Also fixes some of the more simpler linter issues.
When powering up the GPSDO, ensure the GPS_3V3 rail is up before taking the GPSDO out of reset. When powering down the GPSDO, ensure I/O signals are driven low to ensure GPSDO isn't backfed power via its I/O input pins. Co-authored-by: Martin Braun <[email protected]>
Signed-off-by: Virendra Kakade <[email protected]>
Previously Max287x assumed RFOUT (RFOUTA) port for output, and automatically enabled output from this port when setting the frequency of the chip. This allows for output selection of AUX_OUT (RFOUTB) instead during set_frequency. This also adds a function to set the output enable for RF_OUT mirroring the added function for AUX_OUT, so that output enable is not solely controlled by setting frequency.
With ruamel.yaml versions >= 0.18, the current image builder doesn't work, because it uses a deprecated call. This call was part of a wrapper that fixes Python 3.5-compatibility. Since our minimum version of Python is now 3.6, we don't need this anyway so we just can just replace the deprecated usage with ruamel.yaml's round-trip loader.
- The main installation path is now always an include path and can be used as such (e.g., /usr/share/uhd/rfnoc) - fpga_includes and dts_includes have been streamlined. They now work identically on all blocks/modules/_device_, and can use resolve() the same way as other arguments do. - Error messages for missing include files are improved.
The method ImageBuilderConfig.get_module_list() can now take a 'nodevice' argument, which is a wildcard argument for "return all blocks and modules, but not the device". The docstring is also updated.
This adds more checks for clock connections: - When an input clock is not connected, a warning is now produced, like this: ⚠ Unconnected clock input: gain0.ce Previously, this would go without any warning. - When source or destination block are incorrectly specified, the error message is improved to give a much clearer indication which line of the input file is wrong: ⛔ Invalid clock domain connection: _device_:ce → gaen0:ce (destination block is not defined) - When two input or output clocks are connected, this is now also flagged as an error: ⛔ Invalid clock domain connection: radio0:radio → gain0:ce (radio is not a clock output) - When a block specifies a timebase or control clock (as the radio blocks on X4x0 do, for example) we now check the validity of the clocks. If an invalid or unknown clock is provided, there is now a clear error message: ⛔ Invalid timebase_clock for block radio0: _device_.tb_clk - Clock checking is now performed on all modules, transport adapters, and blocks with the same rules applying to all of them. - Because of all the new features, the clock management code was simplified to recoup some complexity. The `self.clocks` object was discarded, and all blocks, modules, and transport adapters now store all clock information on themselves. For example, `self.noc_blocks["radio0"].clocks` would provide all information on the clocks for radio0. This change also makes the builder object more similar to the YAML file (there is no "clocks" object in the YAML). - As a result of the previous change, the template code for generating clock indices for control and timebase clock was simplified, and the logic for looking up the correct index was moved into builder_config.py.
In case of multiple NICs which have no restriction regarding NUMA nodes, the pool_index needs to be 0 in all cases.
Test both DPDK 19.11 and 23.11
When using recent compilers (e.g. clang 18) and C++20 flags, the DPDK headers that are included by UHD produce warnings because they are not fully compliant. Because those headers are external to UHD, we simply ignore the warnings originating from DPDK.
udp_dpdk_link did not have a virtual destructor, which it should have as a virtual class (other classes inheriting from recv_link_if or send_link_if do this correctly). This would produce compiler warnings on more compilers (e.g., clang 18) like this: warning: destructor called on non-final 'uhd::transport::udp_dpdk_link' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor]
The class dpdk_frame_buff was referred to as a struct in the DPDK code, which is valid, but can causes trouble. Recent compilers (e.g., clang 18) will produce a warning. We therefore fix the reference.
Unused variables, constants, and functions cause compiler warnings on recent compilers. We therefore remove those, or comment them out. The heuristic for when to comment out and when to delete is as such: If there is a list of constants or variables, where the unused constant makes sense within a list, it is commented out. Otherwise, it is deleted.
This improves error checking and -messages for IO ports. In particular, this will now be able to check wire widths for compatibility. Imagine you have a BSP with a radio connection of 1 SPC, 64-bit CHDR width, and attempt to instantiate a radio block with 2 SPC (and also 64-bit CHDR width). Without this changeset, the misconnection would either be caught by the bitfile generation process, or not at all (e.g., if we are connecting a narrow bus to a wider one, we would simply connect the least significant bits). With this changeset, a clear error message is given immediately when the YAML is parsed such as this: Connection _device_:radio0 → radio0:radio has a wire width mismatch. Source port radio_rx_data_radio0 has width 64, destination port radio_rx_data has width 128.
- Default BSP parameters are now also resolved and can make use of previously defined BSP parameters - Regular block parameter resolution is simplified
This simplifies image core files by generating a RADIO_NIPC parameter for the X410, X440 and E31x BSP files. The IO port widths for X410 are now dynamically widened based on the NIPC value, which is a function of the RF_BW parameter, and cannot be modified. The radio block can now read the NIPC value from the BSP, and populate its spc parameter dynamically. This avoids having to know the right spc value when writing YAML image core files and reduces redundancy. This also removes the RADIO_NIPC parameter entirely from all the image core files. This parameter was fine, but it was a bit confusing because it referenced a Verilog parameter, which you just had to know was there in the generated Verilog. By referencing the BSP parameter instead, the YAML files (BSP, radio.yml, and image core file) are now self-contained regarding the RADIO_NIPC/spc information. As a minor upside, the input wire widths for X410's and N310's rfnoc_image_core.sv module are now generated with the correct widths, and not, as before, with the worst-case width (and then we assume Vivado will do the right thing).
This fixes an issue where default clocks would not get detected properly when checking for correct clock domain connections (change added in ce96d9b). The following error message could be observed with some image cores: [error] Invalid clock domain connection: _device_:rfnoc_chdr → ddc0:ce (rfnoc_chdr is not a clock output) [error] Invalid clock domain connection: _device_:rfnoc_chdr → duc0:ce (rfnoc_chdr is not a clock output) Clearly, _device_.rfnoc_chdr is a valid clock output, but it was not detected because default clocks are stored differently from non-default clocks.
Co-authored-by: Joerg Hofrichter <[email protected]>
Implementing tune requests in rfnoc blocks using Action API. Created new tune request action which contains the tune_request, tune_result and ranges required for tuning. The tune request can be issued using issue_tune_request() API from RX/TX Streamers. The tune request action propagates through the blocks in the rfnoc graph and does necessary frequency settings. The output tune frequency can also be obtained from the RX/TX streamers using get_rx_tune_frequency() or get_tx_tune_frequency() respectively. Co-authored-by: Riya Alias <[email protected]>
This adds tests for action forwarding in DDC and DUC block tests which are required for Tune Requests in RFNoC. Co-authored-by: Riya Alias <[email protected]>
Changed rfnoc_replay_samples_from_file and rfnoc_rx_to_file examples to demonstrate the use of tune requests in RFNoC blocks. Co-authored-by: Riya Alias <[email protected]>
The IO port width of the radio ports is bitfile-dependent. We therefore create a new device parameter for X440 called NUM_PORTS_PER_RADIO and peg it to the RF_BW.
This adds support for generating RFNoC bitfiles from GNU Radio Companion (.grc) files. Note that this requires changes to GNU Radio as well (updated block definition files for the GRC bindings). There is a new mini-feature in the image builder itself: The option to dump the YAML file into the build directory. For the GRC import, this makes sense, because it allows reading the UHD YAML represenation of a GRC image core.
When using the following command syntax:
rfnoc_image_builder --fpga-dir=~/path/to/uhd/fpga \
--yaml-config=~/path/to/image_core.yml
The shell won't expand the ~ (shorthand for $HOME) and the image builder
needs to expand the path itself, which is fixed in this commit (for
--fpga-dir, --yaml-config, and --grc-config).
Note that this is not a problem when skipping the "=", i.e., the
following work without this fix, assuming a shell that auto-expands the
tilde symbol (e.g., bash, zsh):
rfnoc_image_builder --fpga-dir ~/path/to/uhd/fpga \
--yaml-config ~/path/to/image_core.yml
or
rfnoc_image_builder -F ~/path/to/uhd/fpga \
-y ~/path/to/image_core.yml
When attempting to generate an image core file with no control SEPs
(which is illegal), the image builder would throw an exception while
trying to produce the proper error message. The exception would look
like this:
File "[...]/site-packages/uhd/rfnoc_utils/builder_config.py", \
line 330, in _check_configuration
failures += [
TypeError: can only concatenate str (not "list") to str
This fixes the error, such that a regular error messages is shown now in
case of missing control SEPs.
... which are located at host/include/uhd/rfnoc/core
The RFNoC DDC/DUC block controllers had a bug, in which they would only
program the upper 24 bits of the 32-bit phase increment value for the
digital frequency shifter.
The DDC/DUC use a 24-bit DDS + multiplier to shift frequency digitally,
but the phase increment input to the DDS is a 32-bit value, which we
were (incorrectly) quantizing to a 24-bit value. This meant we were
artificially limiting the digital frequency accuracy, e.g., for a 200
MHz sample clock, to 200MHz / 2^{24} == (approx.) 12 Hz, which in turn
meant there was an unnecessary frequency error of up to 6 Hz (for lower
clock rates, the error would be smaller but still unnecessarily high).
This patch fixes the width of the phase increment value and allows for
sub-Hz accuracy (once again).
This bug was introduced in 699870d (first released with UHD 4.2).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add updates from parent UHD