Re: [USRP-users] rfnoc_image_builder error with clock domain
On Thu, Feb 18, 2021 at 7:28 AM Mike via USRP-users < usrp-users@lists.ettus.com> wrote: That is a typo in AN-400 that should probably be fixed. > Indeed it is! Good catch, and my apologies for the inconvenience. Glad you found the resolution. I've filed an issue on GitHub to update the application note to fix the typo: https://github.com/EttusResearch/uhd/issues/416 It's obvious now but first time through it tripped me up. > Even now, I'd hesitate to call it obvious. :) Best regards, Aaron ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc_image_builder error with clock domain
On Tue, Feb 16, 2021 at 10:15 AM Mike via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Any ideas?
Try changing the clock domain connection to your FFT block to this:
- { srcblk: _device_, srcport: rfnoc_chdr,dstblk: fft0, dstport:ce
}
Does that allow rfnoc_image_builder to complete successfully?
Best regards,
Aaron
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC OTT Block on E320
On Fri, Feb 12, 2021 at 5:53 AM Mark D via USRP-users
wrote:
> So far I’ve got the FPGA built and uploaded to the FPGA. Uhd_usrp_probe shows
> that the RFNoC routing as expected, but the name of OTT block has been
> replaced with Block#0. The OOT project appears as a folder in GNU radio with
> the new block available to be dragged into the project.
The output of '0/Block#{number}' from uhd_usrp_probe for out-of-tree
blocks in UHD 4.0 is a known limitation and expected. When UHD
discovers the topology of the RFNoC graph, it can see that a block is
there, but because it isn't registered with UHD, it is display with
the unimaginative name of 'Block'. Normally, the block controller
class contains the code to register the block with UHD; only in-tree
blocks that are built as a part of UHD have their names displayed in
uhd_usrp_probe.
Best regards,
Aaron
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC 4 rfnocmodtool
On Mon, Feb 8, 2021 at 5:35 AM Askar, Ramez via USRP-users wrote: > Is rfnocmodtool made to create a completely new module, or it is also support > adding the provided modules from Ettus, such as FIR, FFT, etc to the design? > I am asking as I have noticed that the RFnoC modules are supported for C++ > application, however, a limited subset appears in the Gnuradio Ettus OOT > module. How do I add the rest to Gnuradio? rfnocmodtool is intended to help you get started creating a new RFNoC block. The tool provides some boilerplate Verilog code that provides the 'shell' of an RFNoC block, some boilerplate C++ code for creating a block controller and bindings to use the block with GNU Radio, and a block definition .yml file which is needed to integrate the block into an RFNoC design. If you want to use a new IP core in an RFNoC design, you'll first have to create an RFNoC block and adapt the IP core to the RFNoC block standards. Integrating that block into an RFNoC signal path requires modifying the .yml file that describes the collection of blocks for your radio's FPGA image and the connections between them. (For example, for the X300 series of radios, see fpga/usrp3/top/x300/x300_rfnoc_image_core.yml in the UHD repo for how that is specified.) Once again, I *highly* recommend watching the RFNoC 4 Workshop video that I linked in a previous message in this thread, which walks you through the entire process of creating a new RFNoC block, integrating it into a radio image, and then interacting with the block controller from GNU Radio. It essentially details every step that you will need to perform. Best regards, Aaron ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC 4 rfnocmodtool
Hi Ramez, I'd like to recommend a thorough viewing of the excellent RFNoC 4 Workshop video that Jonathon Pendlum and Neel Pandeya from Ettus Research put together for GRCon 2020, which is available on YouTube at https://www.youtube.com/watch?v=M9ntwQie9vs. This should walk you through the process of creating a new out-of-tree RFNoC 4 module and adding support for it to GNU Radio and your USRP device. Best regards, Aaron On Thu, Feb 4, 2021 at 12:15 PM Askar, Ramez via USRP-users wrote: > > Dear Sir or Madam, > > > > I would like to use one of the available FPGA blocks from Ettus – such as FIR > filter -- to customize my FPGA image, and add the corresponding control > driver for C++ application and Gnuradio. However, after creating newmod with > rfnocmodtool, I have tried to add fir filter block, the tool is not aware > about the existing blocks. Instead, the rfnocmodtool has created a module > from scratch called FIR. In other words, it did not import the FIR module > that is offered by Ettus team. Is there any other way of doing this? How can > add a OOT RFNoC FIR control module to gnuradio? > > > > Best regards / Mit freundlichen Grüßen > > -- > Askar, Ramez, M.Sc. > Research Associate / Project Manager / Delegate > > Wireless Communications and Networks > Fraunhofer Institute for Telecommunications, Heinrich Hertz Institute, HHI > Einsteinufer 37, 10587 Berlin, Germany > +49 (0)30 31002-628 > ramez.as...@hhi.fraunhofer.de > www.hhi.fraunhofer.de > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] DPDK troubles (invalid ELF header loading dpdk library)
on at pps edge > [INFO] [MULTI_USRP] 2) set times next pps (synchronously) > [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. > [WARNING] [0/Radio#1] Attempting to set tick rate to 0. Skipping. > [WARNING] [0/Radio#1] Attempting to set tick rate to 0. Skipping. > [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. > Setting TX spp to 1989 > [00:00:04.907401082] Testing receive rate 62.50 Msps on 4 channels > [00:00:04.914615576] Testing transmit rate 62.50 Msps on 4 channels > [00:00:15.167869894] Benchmark complete. > > > Benchmark rate summary: > Num received samples: 2549794336 > Num dropped samples: 0 > Num overruns detected:0 > Num transmitted samples: 2499910452 > Num sequence errors (Tx): 0 > Num sequence errors (Rx): 0 > Num underruns detected: 0 > Num late commands:0 > Num timeouts (Tx):0 > Num timeouts (Rx):0 > > > Done! > > // Second run fails > root@irisheyes5-hp-z240-sff:~# benchmark_rate --tx_rate=62.5e6 > --rx_rate=62.5e6 --channels="0,1,2,3" > --args="use_dpdk=1,mgmt_addr=192.168.1.88,addr=192.168.60.2" > > [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; > UHD_4.0.0.0-50-ge520e3ff > EAL: Detected 8 lcore(s) > EAL: Detected 1 NUMA nodes > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > EAL: No free hugepages reported in hugepages-1048576kB > EAL: Probing VFIO support... > EAL: VFIO support initialized > EAL: PCI device :03:00.0 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: using IOMMU type 1 (Type 1) > EAL: PCI device :03:00.1 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: PCI device :03:00.2 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: PCI device :03:00.3 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > [ERROR] [DPDK] All DPDK links did not report as up! > EAL: FATAL: already called initialization. > EAL: already called initialization. > [ERROR] [UHD] Device discovery error: RuntimeError: DPDK: All DPDK links did > not report as up! > [ERROR] [DPDK] Error with EAL initialization > [ERROR] [X300] X300 Network discovery error RuntimeError: Error with EAL > initialization > [00:00:00.000122] Creating the usrp device with: > use_dpdk=1,mgmt_addr=192.168.1.88,addr=192.168.60.2... > EAL: FATAL: already called initialization. > EAL: already called initialization. > [ERROR] [DPDK] Error with EAL initialization > [ERROR] [UHD] Device discovery error: RuntimeError: Error with EAL > initialization > EAL: FATAL: already called initialization. > EAL: already called initialization. > [ERROR] [DPDK] Error with EAL initialization > [ERROR] [X300] X300 Network discovery error RuntimeError: Error with EAL > initialization > Error: LookupError: KeyError: No devices found for -> > Device Address: > use_dpdk: 1 > mgmt_addr: 192.168.1.88 > addr: 192.168.60.2 > > // Third run fails > root@irisheyes5-hp-z240-sff:~# benchmark_rate --tx_rate=62.5e6 > --rx_rate=62.5e6 --channels="0,1,2,3" > --args="use_dpdk=1,mgmt_addr=192.168.1.88,addr=192.168.60.2" > > [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; > UHD_4.0.0.0-50-ge520e3ff > EAL: Detected 8 lcore(s) > EAL: Detected 1 NUMA nodes > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > EAL: No free hugepages reported in hugepages-1048576kB > EAL: Probing VFIO support... > EAL: VFIO support initialized > EAL: PCI device :03:00.0 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: using IOMMU type 1 (Type 1) > EAL: PCI device :03:00.1 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: PCI device :03:00.2 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > EAL: PCI device :03:00.3 on NUMA socket -1 > EAL: Invalid NUMA socket, default to 0 > EAL: probe driver: 8086:1584 net_i40e > [ERROR] [DPDK] All DPDK links did not report as up! > EAL: FATAL: already called initialization. > EAL: already called initialization. > [ERROR] [UHD] Device discovery error: RuntimeError: DPDK: All DPDK links did > not report as up! > [ERROR] [DPDK] Error with EAL initialization > [ERROR] [X300] X300 Network discovery error RuntimeError: Error with EAL > initialization > [00:00:00.000148] Creating the usrp device with:
Re: [USRP-users] DPDK troubles (invalid ELF header loading dpdk library)
On Mon, Feb 1, 2021 at 9:02 PM Rob Kossler via USRP-users
wrote:
> Has anyone successfully used DPDK with Ubuntu 20.04, UHD 4.0, Intel XL710
> NIC, and N310 (or X310)?
If I remember correctly, I believe DPDK tries to dlopen() *everything*
in the directory specified by the dpdk_driver parameter in the DPDK
section of uhd.conf, leading to a lot of errors similar to yours
('Invalid ELF header' and the like). Having the correct collection of
.so files in that directory is key.
What's worked for me in the past when using DPDK with an Intel XL710
is creating a directory (I used /usr/local/lib/dpdk-pmds) and copying
a specific set of DPDK .so files into this directory:
* librte_mempool_ring.so
* librte_pdump.so (I think this one is optional--I had been trying to
get packet dumps from DPDK a while back)
* librte_pmd_i40e.so
* librte_pmd_ixgbe.so (may be optional?)
* librte_pmd_pcap.so (this one is also optional, I think)
* librte_pmd_ring.so
(Symlinking to the actual libraries wherever they get installed
instead of copying them into the directory would probably work as
well.)
Then, make sure that the dpdk-driver key in the [use_dpdk=1] section
of uhd.conf points to that directory:
dpdk_driver = /usr/local/lib/dpdk-pmds
Hopefully that will resolve the issue and get you a little further
down the road.
Best regards,
Aaron
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues getting UHD and DPDK working with Mellanox ConnectX-5
Hi Jorge, The '[WARNING] [DPDK] Detected use_dpdk argument, but DPDK support not built in' message means that the version of UHD you are using (in this case, the 3.15.LTS version you installed via PyBOMBS) was not compiled with DPDK support. For DPDK to be available and usable, the UHD driver has to be built against the appropriate version of the DPDK libraries for UHD. If you build the UHD 3.15.LTS branch from source and have the appropriate DPDK libraries installed, the cmake step prior to compilation will indicate support for DPDK in the output: -- Found DPDK: /usr/local/include/dpdk (found version "18.11") (note: this is the output for building UHD-4.0, hence the more recent version) : : -- ## -- # UHD enabled components -- ## : -- * DPDK : Then you should be able to proceed. Best regards, Aaron On Thu, Jan 28, 2021 at 6:48 AM Jorge Arroyo Giganto via USRP-users wrote: > > Hi, > > I am trying to get DPDK and UHD working with a Mellanox ConnectX-5 NIC. > > I am using UHD-3.15.LTS (the installation was done with PyBOMBS in order to > have RFNoC support, I did it following the RFNoC Getting Started guide), with > an X310 and running Ubuntu 16.04 on the Host. > > I have followed the guides Getting Started with DPDK and UHD and UHD's manual > DPDK page with no luck. > > For DPDK, as I am using Ubuntu 16.04, I downloaded from DPDK's download page > the recommended DPDK 17.11.10 (LTS) version. > > About the ConnectX-5, I installed its drivers (the LTS version of MLNX_OFED) > with "./mlnxofedinstall --upstream-libs --dpdk". The drivers seem to work > fine as I am able to run UHD applications using the X310 at 10Gb/s, however > when setting "use_dpdk=1" I always get the "[WARNING] [DPDK] Detected > use_dpdk argument, but DPDK support not built in." message. > > My uhd.conf file looks like this: > > [use_dpdk=1] > dpdk-mtu=9000 > dpdk-driver=~/dpdk-stable-17.11.10/build/build/drivers ; (not sure about > this line as I don't have the /usr/lib/x86_64-linux-gnu/dpdk-17.11-drivers/ > directory, maybe this is a clue?) > dpdk-corelist=0,1 > dpdk-num-mbufs=4095 > dpdk-mbufs-cache-size=315 > > [dpdk-mac=04:3f:72:c3:70:fd] > dpdk-io-cpu=1 > dpdk-ipv4=192.168.40.1/24 > > [dpdk-mac=04:3f:72:c3:70:fc] > dpdk-io-cpu=1 > dpdk-ipv4=192.168.10.1/24 > > > If anyone with this setup has gotten DPDK to work I would appreciate the help > very much. > > Best regards, > > Jorge > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] uhd4.0 and blocks with multiple ports
I agree that this question is more in the domain of GNURadio, but I do want to point out that RFNoC 4.0 blocks most certainly can have different numbers of inputs and outputs. A good example is the RFNoC Fosphor block: https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/lib/rfnoc/fosphor https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/fosphor.yml The GR 3.8 support for this block (and other UHD 4.0 RFNoC blocks) is in gr-ettus: https://github.com/EttusResearch/gr-ettus/blob/master/grc/ettus_rfnoc_fosphor.block.yml Best regards, Aaron On Mon, Jan 25, 2021 at 3:25 PM Marcus D Leech via USRP-users wrote: > > This is clearly a question for the discuss-gnuradio mailing list. > > Sent from my iPhone > > > On Jan 25, 2021, at 2:43 PM, dario via USRP-users > > wrote: > > > > > > Hi, > > I created a block with two output ports and one input port however when i > > try to connect it via stream endpoints gnuradio companion claims it doesn't > > know how to handle this. I then added a sexond inout as i recall that on > > uhd 3.15 it is necessary to have as many inputs as outputs but it gave back > > the same error now saying it doesn't know how to connect blocks with two > > inputs and two outputs. > > I'm a bit confuse because it seems radio for example has two outputs > > however it is statically connected. Is it at all possible to have a dynamic > > connection of a block with multiple outputs? What is the possible reason > > why node manager reports it doesn't support this connection? > > > > Thanks, > > > > Dario > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
On Mon, Jan 25, 2021 at 11:33 AM Cédric Hannotier via USRP-users wrote: > So the action is propagated by the gain block iif the controller is > built with UHD and hence recognized by uhd_usrp_probe. > Building the controller as OOT makes the block unrecognized and > hence falls back to name 'Block' and controller 'noc_block_base', > that does not seem to forward issue_stream_cmd. > > All of this is quite inconvenient (for me). > Do you know if there is an internal roadmap to fix this? Thanks for taking the time to build the module with UHD and discover the inconsistent (and I agree inconvenient) behavior. I would like to encourage you to file an issue about this on the UHD issues page at https://github.com/EttusResearch/uhd/issues. That way we can ensure that it is on our radar. Best regards, Aaron ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
On Thu, Jan 21, 2021 at 4:49 PM Cédric Hannotier via USRP-users
wrote:
> On a side note:
> Are we forced to implement a custom controller for each RFNoC block?
> I was expecting that I could just write the verilog part
> and use the basic noc_block_base controller to manage my blocks in C++,
> using regs()->peek32/poke32 to set my registers etc.
> But from above, it seems that it does not forward the issue_stream_cmd
> by default? Is that correct?
For very basic RFNoC block prototyping, you should be able to use the
default noc_block_base implementation if you are willing to access
your NoC block's functionality via register reads and writes and deal
with some additional complications when dealing with multiple custom
RFNoC blocks. You should be able to get a reference to the block by
calling get_block() on your rfnoc_block object--this method returns a
noc_block_base::sptr.
The bit that's complicated is that get_block() takes a block_id_t,
which consists of the device number, block name, and instance (e.g.,
'0/MyBlock#0' when represented as a string). Generally, the name is
assigned to the block in the custom block controller via the
UHD_RFNOC_BLOCK_REGISTER_DIRECT() macro. If the block is not
registered via this macro, as is the case when using noc_block_base
directly, the block will be assigned the unimaginative but technically
correct name of 'Block'. Thus, if you want to use multiple different
custom RFNoC blocks without custom block controllers in this manner,
you will need to verify that when you call get_block("0/Block#n"), it
is the block that you expect. You can call get_noc_id() on the
noc_block_base that is returned and ensure that the 32-bit ID indeed
represents the block that you wish to control.
Unless specifically overridden, the default behavior of a
noc_block_base-derived object, I believe, is to forward actions
(stream commands) using the ONE_TO_ONE forwarding policy, which means
to forward the action to the same port on the opposite edge (so to
output port #N if the action is received on input port #N, and vice
versa). Consult the documentation of uhd::rfnoc::node_t and
forwarding_policy_t for more details.
Best regards,
Aaron
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] DPDK runtime error
Hello Florian, I believe in UHD 3.15, the keys in the uhd.conf file use dashes (-), not underscores between words, e.g.: [dpdk-mac=00:11:22:33:44:55] dpdk-io-cpu = 1 dpdk-ipv4 = 192.168.10.1/24 Hope that helps, Aaron From: USRP-users On Behalf Of Florian Kaltenberger via USRP-users Sent: Wednesday, January 8, 2020 10:10 AM Subject: [EXTERNAL] Re: [USRP-users] DPDK runtime error Hi, we now installed DPDK 17.11 but I still have exactly the same problem. I have a feeling the problem is that I am not addressing the device correctly. Here is what I did: The USRP is connected to ethernet interfaces "p1p2" (mac_addr 64:9d:99:b1:1e:8d) and "p1p4" (mac_addr 64:9d:99:b1:1e:8f) which are originally configured with IP addresses 192.168.10.1 and inet_addr 192.168.20.1. This configuration works fine without dpdk. Then I deactivate these two interfaces using "ifconfig p1p2 down" "ifconfig p1p4 down"and do "dpdk-devbind --bind=vfio-pci 01:00.1" and "dpdk-devbind --bind=vfio-pci 01:00.3". The status of "dpdk-devbind -s" is below. In the file /etc/uhd/uhd.conf I specify [dpdk_mac=64:9d:99:b1:1e:8d] dpdk_io_cpu = 1 dpdk_ipv4 = 192.168.10.1/24 [dpdk_mac=64:9d:99:b1:1e:8f] dpdk_io_cpu = 2 dpdk_ipv4 = 192.168.20.1/24 Is this the correct way of specifying it? What surprises me is that DPDK requires to address the device by its PCI address while UHD still requires to set the IP addresses. Florian. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
