[USRP-users] Re: RFNoC custom image build errors

[Wade Fife]

Hi Jeff,

You've got these two lines in your YAML:

  - { srcblk: radio1, srcport: out_0, dstblk: split2, dstport: in_0 }
...
  - { srcblk: radio1, srcport: out_0, dstblk: split3, dstport: in_0 }

So you've got radio1(out_0) driving two different blocks, which isn't
allowed. I'm a little surprised this didn't cause an error with
rfnoc_image_builder. I think you meant to use out_1 for one of them.

Unfortunately, there are a lot of warnings with Vivado that are difficult
to remove. It's good to keep an eye on them, but usually they can be
ignored unless you get an error.

As for your approach, it's a lot of DDCs and stream endpoints, and hence a
lot of resources. I think you might run out of block RAM with that
buff_size value on the stream endpoints. I'm also curious how the software
will handle having more DDCs than radios. It's an interesting experiment.

Wade

On Thu, Jun 17, 2021 at 12:40 PM Jeff Clintoon 
wrote:

> Hello,
>
> I'm trying to use an Ettus X310 with two TwinRX boards to capture signals
> from four antennas with two frequency channels on each antenna, spaced
> about 40 MHz apart.  I've implemented this in Gnuradio Companion by
> capturing the whole swath on the X310, and then filtering and
> downconverting to the desired channels, but my CPU can't keep up---I get
> buffer overruns and large gaps in the data.
>
> My thought was to use RFNoC to offload the processing to the FPGA.  I'm
> using UHD 4.0.  I've tried to build a custom image with two radios, 4 DDCs
> (it looks like each DDC can handle two channels), and 4 split_stream
> blocks.  When I try to build the image, I get the following error:
>
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
> x300_core/bus_int_i/rfnoc_sandbox_i/b_split3_5/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/m_radio1_out_0_tready
> has multiple drivers:
> x300_core/bus_int_i/rfnoc_sandbox_i/b_split2_4/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/o_tvalid_i_3__30/O,
> and
> x300_core/bus_int_i/rfnoc_sandbox_i/b_split3_5/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/o_tvalid_i_4__18/O.
>
> I also get a lot of warnings on most of the Xilinx tasks about unconnected
> pins, some critical warnings on the final synthesis step, mostly along the
> lines of "set_clock_groups:No valid object(s) found for '-group [get_clocks
> bus_clk]'."  I have no idea if these are to be expected.
>
> Does this sound like the right approach for this problem?  If so, what am
> I doing wrong when building this?
>
> Thanks,
> Jeff
>
> Here's my image configuration YML file:
>
> # General parameters
> # -
> schema: rfnoc_imagebuilder_args # Identifier for the schema used
> to validate this file
> copyright: 'Ettus Research, A National Instruments Brand' # Copyright
> information used in file headers
> license: 'SPDX-License-Identifier: LGPL-3.0-or-later' # License
> information used in file headers
> version: 1.0# File version
> rfnoc_version: 1.0  # RFNoC protocol version
> chdr_width: 64  # Bit width of the CHDR bus for
> this image
> device: 'x310'
> default_target: 'X310_HG'
>
> # A list of all stream endpoints in design
> # 
> stream_endpoints:
>   ep0:   # Stream endpoint name
> ctrl: True  # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for data
>   ep1:   # Stream endpoint name
> ctrl: False # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for data
>   ep2:   # Stream endpoint name
> ctrl: False # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for data
>   ep3:   # Stream endpoint name
> ctrl: False # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for data
>   ep4:   # Stream endpoint name
> ctrl: False # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for data
>   ep5:   # Stream endpoint name
> ctrl: False # Endpoint passes control traffic
> data: True  # Endpoint passes data traffic
> buff_size: 65536# Ingress buffer size for 

[USRP-users] CMake Error Compiling init_usrp Example Ubuntu 20.04

[Alex Bouvy via USRP-users]

Hi,

I'm hoping someone might be able to help me out. I'm running Ubuntu 20.04. I'm 
encountering errors when trying to use CMake to compile the init_usrp example. 
This is the error I receive:

CMake Error at CMakeLists.txt:26 (find_package):
  By not providing "FindUHD.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "UHD", but
  CMake did not find one.

  Could not find a package configuration file provided by "UHD" (requested
  version 3.15.0) with any of the following names:

UHDConfig.cmake
uhd-config.cmake

  Add the installation prefix of "UHD" to CMAKE_PREFIX_PATH or set "UHD_DIR"
  to a directory containing one of the above files.  If "UHD" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also "/home/alex/init_usrp/CMakeFiles/CMakeOutput.log".

I've tried adding the installation prefix of UHD to the CMAKE_PREFIX_PATH as 
suggested but this does not seem to fix the issue. I installed UHD using 
PyBOMBS, if that makes any difference. Am I missing something obvious? Could 
somebody point me in the right direction?

Thanks,
Alex
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Troubles with the QSFP+ on the N3x0 series

[Jason Matusiak]

Thank you for the info Paul. It was certainly something that we were hoping to 
pursue, but I think that we will have to hold off for now.  I'd love to be able 
to take advantage of even a fraction of that 40Gb bandwidth that Aurora offers, 
but ultimately, we need the stream on a server, so I am not sure that there 
will be a solution in the near-term.  I suppose we could look into some sort of 
high-speed FPGA card to run from within a server, but at that point it would 
start to get convoluted (if it was even possible).

Report back if you have any successes!




I’m digging into this myself now Using X310s. Yes, Aurora is an FPGA to FPGA 
interface Created by Xilinx. Ettus has HA and XA images for the X series and I 
believe AA and something else for N3xx series. Ettus also has an aurora BIST 
python script for X310 in the firmware directory of UHD. It took forever to 
find this, but it’s very useful. I’m sure there’s some equivalent for N3xx too, 
but I haven’t looked. The script basically just confirms that the SFP1 ports 
are setup to communicate properly over Aurora and is sending data between those 
two interfaces across 2 devices. In the “UHD FOUR-O” video from GRCON2019 there 
is A demo of two X310s passing an RF stream between them using GNURadio and 
RFNoC. Other than that, yes it’s very sparse as far as evidence or examples of 
how Aurora can be used with Ettus products.

Hoping to have some better information to offer here soon, but for now that’s 
about all I have.

Hope this is helpful.



On Jun 9, 2021, at 09:14, Jason Matusiak  wrote:


Thank you for all the info Michael.

Are you aware of any examples/writeups/tutorials of USRPs and Aurora in action? 
 I am trying to wrap my head around how it is intended to be used.  It seems 
like it can only really be used in an FPGA-to-FPGA environment, but almost 
everything I find in Ettus documentation is just that certain devices are 
Aurora capable, and not much else to go on. TIA.


From: Michael Dickens 
Sent: Friday, June 4, 2021 5:00 PM
Cc: Ettus Mail List 
Subject: Re: [USRP-users] Troubles with the QSFP+ on the N3x0 series

When using White Rabbit, the WR link does not appear to the OS; WR signal 
processing is handled directly in the FPGA, and made available to the OS / UHD 
via special commands. Or, that's what's supposed to happen. As of UHD 
3.14.0.0rc1 WR does not work; we just recently found out this fact, and we are 
working hard to get the issue(s) resolved.

I've never used the Aurora FPGA image .. AA or AQ. From < 
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rh_sfp_protocols
 > it looks like AQ uses all 4 QSFP+ lanes, which between the actual Aurora 
protocol and using all 4 10 Gb lanes one should be able to get 40 Gb aggregate 
data ... literally bits in, bits out ... no ENET overhead!


On Fri, Jun 4, 2021 at 4:43 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Afternoon Michael! This is exactly the info I needed. I misspoke when I said 
WX, I meant XQ.

After putting the new image on, we knew the /data/ directory still had the two 
sfp network setups, but we were expecting something in addition for the qsfp. 
It makes sense that it doesn't //need// to change since we are only using 2 
lanes of one, or 2 lanes of the other. BUT, what I couldn't be 100% sure of is 
since white rabbit needs Ethernet as well, why wouldn't THAT be the sfp0 
configuration, make sense? I'm not working the white rabbit side, but I 
understand it to be ip based.

Lastly. If we go the pure Aurora route, I know that we lose white rabbit, but 
we gain a full 40Gbps, right?

Thanks again.
On Jun 4, 2021, at 4:18 PM, Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:
Hi Jason - Answers, and more. I hope this is useful and helps clarify the 
options. - MLD

1) The N32x QSFP+ port/link/interface should work with UHD 3.15 via the XQ FPGA 
image. I haven't tried that in a while, but it did work for me once upon a time.

2) When using the WX FPGA image on any N3xy, you get just SFP+ port 1 for data, 
which is just a single 10 Gb link -- not the QSFP+ port (which is on the N32x 
only, by the way). If you use the XQ FPGA image with the N32x then you get 1x 
or 2x 10 Gb links via the QSFP+ port: lanes 0 and 1 (or 1 and 2 if you count 
lanes as 1's-based). In theory you could use 2x SFP+ 10 Gb links on a host NIC 
and aggregate them via fiber into a QSFP+ adapter attached to the USRP; I've 
never tried this directly, but I can say that taking QSFP+ off a host NIC and 
switching lanes works fine using the appropriate adapters and fiber cables and 

[USRP-users] RFNoC custom image build errors

[Jeff Clintoon]

Hello,

I'm trying to use an Ettus X310 with two TwinRX boards to capture signals from 
four antennas with two frequency channels on each antenna, spaced about 40 MHz 
apart.  I've implemented this in Gnuradio Companion by capturing the whole 
swath on the X310, and then filtering and downconverting to the desired 
channels, but my CPU can't keep up---I get buffer overruns and large gaps in 
the data.

My thought was to use RFNoC to offload the processing to the FPGA.  I'm using 
UHD 4.0.  I've tried to build a custom image with two radios, 4 DDCs (it looks 
like each DDC can handle two channels), and 4 split_stream blocks.  When I try 
to build the image, I get the following error:

ERROR: [DRC MDRV-1] Multiple Driver Nets: Net 
x300_core/bus_int_i/rfnoc_sandbox_i/b_split3_5/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/m_radio1_out_0_tready
 has multiple drivers: 
x300_core/bus_int_i/rfnoc_sandbox_i/b_split2_4/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/o_tvalid_i_3__30/O,
 and 
x300_core/bus_int_i/rfnoc_sandbox_i/b_split3_5/noc_shell_split_stream_i/gen_input_in[0].chdr_to_chdr_data_in_in/chdr_flusher_i/out_pipe_i/o_tvalid_i_4__18/O.

I also get a lot of warnings on most of the Xilinx tasks about unconnected 
pins, some critical warnings on the final synthesis step, mostly along the 
lines of "set_clock_groups:No valid object(s) found for '-group [get_clocks 
bus_clk]'."  I have no idea if these are to be expected.

Does this sound like the right approach for this problem?  If so, what am I 
doing wrong when building this?

Thanks,
Jeff

Here's my image configuration YML file:

# General parameters
# -
schema: rfnoc_imagebuilder_args # Identifier for the schema used to 
validate this file
copyright: 'Ettus Research, A National Instruments Brand' # Copyright 
information used in file headers
license: 'SPDX-License-Identifier: LGPL-3.0-or-later' # License information 
used in file headers
version: 1.0# File version
rfnoc_version: 1.0  # RFNoC protocol version
chdr_width: 64  # Bit width of the CHDR bus for this 
image
device: 'x310'
default_target: 'X310_HG'

# A list of all stream endpoints in design
# 
stream_endpoints:
  ep0:   # Stream endpoint name
ctrl: True  # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep1:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep2:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep3:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep4:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep5:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep6:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data
  ep7:   # Stream endpoint name
ctrl: False # Endpoint passes control traffic
data: True  # Endpoint passes data traffic
buff_size: 65536# Ingress buffer size for data

# A list of all NoC blocks in design
# --
noc_blocks:
  radio0:
block_desc: 'radio_2x64.yml'
  radio1:
block_desc: 'radio_2x64.yml'
  split0:
block_desc: 'split_stream.yml'
  split1:
block_desc: 'split_stream.yml'
  split2:
block_desc: 'split_stream.yml'
  split3:
block_desc: 'split_stream.yml'
  ddc0:
block_desc: 'ddc.yml'
parameters:
  NUM_PORTS: 2
  ddc1:
block_desc: 'ddc.yml'
parameters:
  NUM_PORTS: 2
  ddc2:
block_desc: 'ddc.yml'

[USRP-users] Hello all;

[rblack]

My current gnuradio/UHD  install has the xml files for a number of RFNoc blocks 
in /usr/share/gnuradio/grc/blocks; e.g. uhd_rfnoc_radio.xml.

But I do not have such a file for the rfnoc replay block, even though I do have 
the rfnoc replay function in my firmware .bit load.  Does such a block exist? 
Also has anyone ever used the “replay block” in a grc flowgraph?

Currently I have UHD 3.15,  but will soon have v 4.0

thanks rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: is there a UHD v4.0.0.0 for Ubuntu 20.04 LTS?

[Dustin Widmann]

Seeing as the swapfile is handled by the kernel, you don't need to do 
anything else.


Dustin

On 6/17/21 8:59 AM, para...@kwesst.com wrote:


Philip Balister wrote:

The gcc killed message says the out of memory killer is killing
the compiler. Since you are in a hurry, add swap.

Philip


I suspected as much, if I add a swap partition, does gcc just know to 
use it, or do i have to pass an argument of some sort to the makefile?



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


OpenPGP_0x85706BEA425306B5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B205mini 10 MHz reference

[Marcus D Leech]

They’re not quoting RMS levels. 

Stick to a 3.3 to 5V square wave and you’re golden. 

Sent from my iPhone

> On Jun 17, 2021, at 12:21 AM, dave_a...@bigpond.com wrote:
> 
> 
> I’m confused by the specs for the 10 MHz reference for the B205mini.
> 
> In kb.ettus.com/B200/B210/B200mini/B205mini#Timing_Reference_Input, and in 
> the schematics, the minimum level is specified as 0/1.8V minimum and the 
> maximum 0/5V. The limits are also given as 10 dBm to 27 dBm.
> 
> 27 dBm into a 50 ohm load translates to 5Vrms, 7.07 V peak, 14.15 Vpp.
> 
> 10 dBm translates to 0.7 Vrms, 0.99 Vpeak, 2.00 Vpp.
> 
> A 17 dB difference in power (between 27 dBm and 10 dBm) indicates a voltage 
> ratio of about 7.
> 
> What am I getting wrong, please?
> 
> Thanks.
> 
> Dave
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: is there a UHD v4.0.0.0 for Ubuntu 20.04 LTS?

[paradis]

Philip Balister wrote:

> The gcc killed message says the out of memory killer is killing the compiler. 
> Since you are in a hurry, add swap.
>
> Philip

I suspected as much, if I add a swap partition, does gcc just know to use it, 
or do i have to pass an argument of some sort to the makefile?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: is there a UHD v4.0.0.0 for Ubuntu 20.04 LTS?

[Philip Balister]

The gcc killed message says the out of memory killer is killing the compiler. 
Since you are in a hurry, add swap.

Philip

On June 17, 2021 8:21:44 AM EDT, para...@kwesst.com wrote:
>Thanks for the help everyone. I’m still trying to build the UHD v4.0.0.0 on 
>the SBC but it keeps dying at about 28%. I feel like it might be a storage 
>and/or ram/memory issue. It’s a Newport GW6200 with 1GB of RAM, but after 
>installing Ubuntu and all the depencies for UHD and clone the UHD repo, 
>there’s only about 20% disk space left.
>
>I’ll take a look at the bitbake stuff, but I don’t know if that will help me 
>right now, since I need this up and running by tomorrow at the latest, 
>otherwise there’s no point.
>
>I had two different SBCs running builds overnight, and the build both failed 
>at the same spot: Trying to build ‘magnesium_radio_contro.ccp.o’ I get this 
>error:
>
>c++: fatal error: Killed signal terminated program cc1plus
>
>compilation terminated.
>
>make\[2\]: \*\*\* \[lib/CMakeFiles/uhd.dir/build.make:2010: 
>lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_control.cpp.o\] 
>Error 1
>
>make\[1\]: \*\*\* \[CMakeFiles/Makefile2:961: lib/CMakeFiles/uhd.dir/all\] 
>Error 2
>
>make: \*\*\* \[Makefile:163: all\] Error 2
>
>Does anyone know what the error or problem could be with that file?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: is there a UHD v4.0.0.0 for Ubuntu 20.04 LTS?

[paradis]

Thanks for the help everyone. I’m still trying to build the UHD v4.0.0.0 on the 
SBC but it keeps dying at about 28%. I feel like it might be a storage and/or 
ram/memory issue. It’s a Newport GW6200 with 1GB of RAM, but after installing 
Ubuntu and all the depencies for UHD and clone the UHD repo, there’s only about 
20% disk space left.

I’ll take a look at the bitbake stuff, but I don’t know if that will help me 
right now, since I need this up and running by tomorrow at the latest, 
otherwise there’s no point.

I had two different SBCs running builds overnight, and the build both failed at 
the same spot: Trying to build ‘magnesium_radio_contro.ccp.o’ I get this error:

c++: fatal error: Killed signal terminated program cc1plus

compilation terminated.

make\[2\]: \*\*\* \[lib/CMakeFiles/uhd.dir/build.make:2010: 
lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_control.cpp.o\] 
Error 1

make\[1\]: \*\*\* \[CMakeFiles/Makefile2:961: lib/CMakeFiles/uhd.dir/all\] 
Error 2

make: \*\*\* \[Makefile:163: all\] Error 2

Does anyone know what the error or problem could be with that file?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com