aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* fpga: n3xx: Fix DRAM FIFO address alignmentWade Fife2022-02-103-6/+6
|
* fpga: rfnoc: Change AWIDTH default for axi_ram_fifoWade Fife2022-02-101-1/+1
| | | | | Change AWIDTH to be the same as MEM_ADDR_W by default. Current USRPs assume the AXI address width is the same as MEM_ADDR_W.
* rfnoc: Expose buffer parameters for DRAM FIFO blockWade Fife2022-02-101-0/+2
|
* fpga: e31x: Add DRAM supportWade Fife2022-02-1016-99/+1503
| | | | | | | | | This adds DRAM support to E31x devices. Due to the size of the DDR3 memory controller, it is not enabled by default. You can include the memory controller IP in the build by adding the DRAM environment variable to your build. For example: DRAM=1 make E310_SG3
* fpga: rfnoc: Add BLANK_OUTPUT to FIR filter block's parametersJonathon Pendlum2022-02-104-11/+21
|
* fpga: x400: Add DRAM enable macroJavier Valenzuela2022-02-101-0/+4
|
* images: Add utilization report files to B2xx image filesMartin Braun2022-02-101-4/+8
|
* fpga: b2xx: Generate utilization report filesMartin Braun2022-02-102-18/+24
| | | | | | | | | | | | Currently, the build process copies the .twr and .syr files into the build/ process after running ISE. For a succinct utilization report, those files are not suitable, though, because they contain too much information. However, the build process already produces a custom, short utilization report using grep and a summary of those reports. This patch modifies the build such that the same output is copied into a usrp_$product_fpga.rpt file, similar to our gen-3 devices.
* fpga: x400: zbx: cpld: Bump ZBX regmap copyrightJavier Valenzuela2022-02-1011-11/+11
|
* fpga: x400: cpld: Bump CMI wrapper copyrightJavier Valenzuela2022-02-102-2/+2
|
* images: Revert x4xx manifest and FPGA compat updateAaron Rossetto2022-02-082-2/+2
|
* mpm: add device name to discovery processLars Amsel2022-02-083-0/+4
| | | | | | | | | | | | | | | | | | | MPM devices currently do not report their device name in the discovery process. This adds the device name. After the change the device name is reported, e.g. when using uhd_find_devices, like so: $> uhd_find_devices -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: DEADBEEF claimed: False fpga: X4_200 mgmt_addr: <mpm device ip> name: <mpm device host name> product: x410 type: x4xx
* ci: Enable ctest on macOS buildsSteven Koo2022-02-082-2/+6
| | | | Signed-off-by: Steven Koo <steven.koo@ni.com>
* ci: flash fpga on x410 ATS runsSteven Koo2022-02-073-3/+14
| | | | Signed-off-by: Steven Koo <steven.koo@ni.com>
* ci: Add mpm folder to triggersSteven Koo2022-02-072-0/+2
| | | | | | | Since we build the system images now and test downstream for x410, trigger builds on mpm changes. Signed-off-by: Steven Koo <steven.koo@ni.com>
* host: Throw exception when accessing properties with incorrect typeLane Kolbly2022-02-074-14/+55
|
* host: Minor cleanups in property_tree codeLane Kolbly2022-02-073-18/+30
|
* cmake: Remove libatomic check on macOSSteven Koo2022-02-071-1/+1
| | | | | | | This removes the libatomic check on macOS. Like MSVC, just assume that it's built in. Signed-off-by: Steven Koo <steven.koo@ni.com>
* utils: Add space to rfnoc_image_builder helpWade Fife2022-02-071-1/+1
|
* fpga: ci: Increase PR pipeline timeoutWade Fife2022-02-071-3/+3
|
* fpga: x400: Bump minor versionWade Fife2022-02-073-8/+8
|
* fpga: x400: Update rfnoc_image_core filesWade Fife2022-02-078-98/+1327
| | | | | Updates the RFNoC image core files to include DRAM and default image changes.
* fpga: x400: Add Replay to 100 and 200 MHz imagesWade Fife2022-02-072-36/+107
| | | | | This adds the RFNoC replay block to the defautl 100 and 200 MHz images for X410.
* fpga: x400: Add DRAM supportWade Fife2022-02-076-106/+1276
|
* fpga: x400: Set DRAM speed to 2.0 GT/sWade Fife2022-02-071-26/+26
|
* fpga: x400: Add axi_inter_4x64_512_bd IPWade Fife2022-02-073-0/+604
|
* fpga: x400: Add axi_inter_2x128_512_bd IPWade Fife2022-02-073-0/+449
|
* rfnoc: Rename and enlarge axi4_mm IO signatureWade Fife2022-02-0711-18/+17
|
* mpm: x4xx: Update FPGA minor compat numberAaron Rossetto2022-02-071-1/+1
|
* images: Update manifestAaron Rossetto2022-02-071-1/+1
|
* uhd: Harmonize fuzzy frequency comparisonsMartin Braun2022-02-049-43/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Throughout UHD, we often do floating-point comparisons for frequency ranges that require resilience to floating point rounding errors. Most of the time the checks look like this: ```cpp if (fp_compare_epsilon<double>(freq) > boundary) { // ... } ``` The exception is the N320 daughterboard control, which uses a custom epsilon: ```cpp if (fp_compare_epsilon<double>(freq, RHODIUM_FREQ_COMPARE_EPSILON) > boundary) { // ... } ``` This was, for the most part, not by design, but because authors simply didn't think about which epsilon value was appropriate for the frequency comparison. This was complicated by the fact that fp_compare_epsilon previously had some issues. This patch introduces FREQ_COMPARE_EPSILON, which is a sensible default value for fp_compare_epsilon when doing frequency comparisons (note that fp_compare_delta already had such a value). Also, it introduces freq_compare_epsilon(x), which is a shorthand for fp_compare_epsilon<double>(x, FREQ_COMPARE_EPSILON). We then replace all occurrences of fp_compare_epsilon<double> which are specific to frequency checks with freq_compare_epsilon.
* math: fp_compare: Adapt fp_compare_epsilon API to actual useMartin Braun2022-02-043-32/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UHD had an issue where the design of fp_compare_epsilon and its usage differed. In fact, the *only* usage of fp_compare_epsilon outside of unit tests was to do a fuzzy frequency comparison, and it always took a form like this: ```cpp // The argument EPSILON may be implied, i.e., using the default if (fp_compare_epsilon<double>(test_freq, EPSILON) < boundary_freq) { // ... } ``` However, the API of fp_compare_epsilon was such that it would apply DOUBLE_PRECISION_EPSILON to part of the frequency comparison, thus rendering the argument EPSILON obsolete. When the default EPSILON was used, this was OK, but only when the floating point type of fp_compare_epsilon<> was `double`, and not `float`. As an example, consider the following: ``` if (fp_compare_epsilon<double>(1e9 + x, LITTLE_EPSILON) == 1e9) { // .... } double BIG_EPSILON = x * 10; if (fp_compare_epsilon<double>(1e9 + x, BIG_EPSILON) == 1e9) { // .... } ``` If you expect the second comparison to pass even if the first failed, then you are not alone. However, that's not what UHD would do. Because of the aforementioned behaviour, it would use DOUBLE_PRECISION_EPSILON for the right hand comparison, which would fail again. Instead of fixing the instances of fp_compare_epsilon throughout UHD, this patch changes the comparison algorithm from "very close with tolerance epsilon" to "close enough with tolerance epsilon". This requires only one side to be close to the other, using its own epsilon, so the aforementioned example would always pass on the second check. However, this exposed a second bug in fp_compare_epsilon. For greater-/less-than comparisons, it would use epsilon like a delta value, i.e., it would check if a + epsilon < b - epsilon That means that if a < b, but (b-a) < 2*epsilon, this check would return "false", i.e., it would report that a >= b, which is incorrect. These operators are now changed such that they first check equality of a and b using the algorithm described in the code, and then compare the values of a and b (ignoring epsilon) directly. A unit test for this case was added.
* systemd: enable tx flow control automaticallyAndrew Lynch2022-02-042-0/+2
|
* ci: Change yaml dependency to ruamelSteven Koo2022-02-045-5/+5
| | | | Signed-off-by: Steven Koo <steven.koo@ni.com>
* ci: Add support for Ubuntu 22.04Steven Koo2022-02-043-3/+72
| | | | Signed-off-by: Steven Koo <steven.koo@ni.com>
* ci: Remove Fedora 33 and add Fedora 35Steven Koo2022-02-042-3/+3
| | | | | | Fedora 33 is going EOL and Fedora 35 was recently released Signed-off-by: Steven Koo <steven.koo@ni.com>
* uhd: rfnoc: Let connect_through_blocks() return edge listMartin Braun2022-02-042-2/+10
| | | | | | This changes the return value of connect_through_blocks() from void to a list of edges. If the connection can be made, then it will now return the list of connections between the source block and port.
* host: x4xx: Fix some warnings on mac OSLane Kolbly2022-02-042-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the following warnings: ``` /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2335:5: warning: \ delete called on non-final 'uhd::rfnoc::x400::x400_gpio_port_mapping' that has \ virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor] delete __ptr; ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2648:7: note: in \ instantiation of member function 'std::__1::default_delete<uhd::rfnoc::x400::x4\ 00_gpio_port_mapping>::operator()' requested here __ptr_.second()(__tmp); ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2602:19: note: in\ instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\ pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\ ping> >::reset' requested here ~unique_ptr() { reset(); } ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:4063:21: note: in\ instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\ pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\ ping> >::~unique_ptr' requested here unique_ptr<_Yp> __hold(__p); ^ /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_radio_control.cpp:1\ 92:33: note: in instantiation of function template specialization 'std::__1::sh\ ared_ptr<uhd::mapper::gpio_port_mapper>::shared_ptr<uhd::rfnoc::x400::x400_gpio\ _port_mapping>' requested here auto gpio_port_mapper = std::shared_ptr<uhd::mapper::gpio_port_mapper>( ``` and: ``` /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\ 4:75: warning: adding 'const uint32_t' (aka 'const unsigned int') to a string d\ oes not append to the string [-Wstring-plus-int] "Could not find corresponding GPIO pin number for given SPI pin " + value); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\ 4:75: note: use array indexing to silence this warning "Could not find corresponding GPIO pin number for given SPI pin " + value); ^ & [ ] ```
* ci: Add libuhd python dependencies to macOSSteven Koo2022-02-041-1/+1
| | | | Signed-off-by: Steven Koo <steven.koo@ni.com>
* mpm: Add x4xx DRAM BISTWade Fife2022-02-031-1/+23
|
* mpm: Fix units for DRAM BISTWade Fife2022-02-033-4/+4
| | | | | There was a mixture of KB/s and B/s in the DRAM BIST. The BIST now returns B/s in all cases.
* host: zbx: Expose tuning table on property treeLane Kolbly2022-02-035-5/+87
| | | | | This allows viewing or, conceivably, customizing the tuning table that ZBX uses, depending on the particular needs of the end user.
* ci: Add x410 test to mono pipelineSteven Koo2022-02-025-0/+412
| | | | | | | | | This change brings in x410 testing into the uhd mono pipeline. This also creates a test development pipeline that executes on uhd mono pipeline as an upstream artifact source. Signed-off-by: Steven Koo <steven.koo@ni.com>
* ci: Enable building of init_usrpMartin Braun2022-02-011-0/+22
| | | | | | | This builds init_usrp against UHD during CI runs. init_usrp is an example for how to write third-party apps using CMake that link against UHD. This will test the UHDConfig.cmake (and related) CMake files, as well as the example itself.
* ci: Make uhdSrcDir directly reference Build.SourcesDirectoryMartin Braun2022-02-011-5/+5
|
* python: rfnoc: Add get_property bindingsWade Fife2022-02-011-0/+60
|
* docs: Add shim Sphinx config for readthedocsMartin Braun2022-02-016-0/+255
| | | | | | | | | This adds a faux Sphinx project under host/docs. When invoking sphinx, it will in fact forward the generator request to Doxygen. This is useful for generating the UHD manual, e.g., on readthedocs. To enable the latter service, .readthedocs.yaml and environment.yml files were added as well.
* rfnoc: Update the MTU forwarding property for some blocksMartin Braun2022-02-018-0/+25
| | | | | | | | | | | | | | | | Note that the default MTU forwarding policy is ONE_TO_ONE, therefore, it is only strictly necessary to modify the MTU forwarding policy for blocks that route data in a different manner. However, it may be nice to explicitly state the forwarding policy for the benefit of the reader. The following blocks had their policies updated: - addsub: ONE_TO_FAN - duc: ONE_TO_ONE - dmafifo: ONE_TO_ONE - null block: DROP - replay block: DROP - split stream: ONE_TO_FAN - switchboard: ONE_TO_FAN
* rfnoc: Set the default MTU forwarding policy to ONE_TO_ONE.Martin Braun2022-02-012-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the default was DROP. For almost all RFNoC blocks, this is not a good default. It is very easy to crash USRPs by not properly propagating the MTU. For example, the following flow graph: Radio -> DDC -> FIR -> Streamer would crash an X310 when not manually setting an spp value. The reason is: The Radio block has an output buffer of 8192 bytes, capable of handling 2044 samples per packet. However, that's too big for the Ethernet portion of the X310, which would cause the X310 to lose connection between UHD and firmware. If the FIR were configured to propagate MTU, the Host->USRP connection (which has an MTU of <= 8000) would limit the MTU on all links, and the spp value would automatically be reduced to 1996 (or less). This commit uses the post_init() feature to check the user set an MTU in the constructor, and sets it to the default if that didn't happen. This doesn't solve all problems (the new default of ONE_TO_ONE) could also be incorrect, but is a much more suitable default. As a consequence, this has a minor change in how set_mtu_forwarding_policy() can be used: It now must be called during the constructor. Before, the rule was that it may only be called once, but that could also have happened, e.g., during the first property resolution. Now, the constructor is the last time block authors can choose an MTU forwarding policy.
* rfnoc: Add post_init() method to noc_block_baseMartin Braun2022-02-013-0/+34
| | | | | | | | This method allows running a fixed set of rules to check the internal consistency of a block. This may be necessary, because blocks authors may incorrectly implement a certain design rule, and we want the ability to not start an RFNoC graph with blocks that have rule violations which we can write checks for.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 15:52:58 +0000