Re: [USRP-users] Current Recommended UHD RFNoC Versions?

[Jonathon Pendlum via USRP-users]

Hi Jeff,

Here are links to the RFNoC 3 & 4 workshop videos that will help you get
started. Personally, I would suggest trying out RFNoC 4 first.

RFNoC 4: https://www.youtube.com/watch?v=M9ntwQie9vs
RFNoC 3: https://www.youtube.com/watch?v=VbODcrmpLaU

On Sat, Mar 6, 2021 at 2:12 PM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> By the way, if RFNoC 4 is what you're interested in, the current master
> branch of
> gr-ettus, GNU Radio 3.8 and UHD 4.x are what you're aiming for!
>
>
> On 04.03.21 22:08, Jeff S via USRP-users wrote:
>
> > I'm getting ready to help someone install code and I'm seeing
> conflicting things
> > regarding GNURadio v3.7/v3.8 with respect to wanting to do RFNoC
> development.  They are
> > going to use an N310 and I've been using maint-3.7 for quite a while.
> >
> > Are we still using the rfnoc-devel branches of UHD and FPGA, maint-3.7
> of GNURadio, and
> > master for gr-ettus?  Or is there some later, stable recommendations?
> >
> > Sorry if there was any recent related posts, but I didn't find any.
> >
> > Thanks,
> > Jeff
> >
> > ___
> > 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] Software Loopback RFNoC TX/RX same flowgraph

[Jonathon Pendlum via USRP-users]

Hi Robert,

Here is a patch to gr-ettus that adds loopback support and an example
flowgraph. You can apply it using "git am". This may not be what the final
result will look like when merged into gr-ettus, so consider this a
temporary solution.

Jonathon

On Wed, Feb 24, 2021 at 4:14 PM Robert Wilson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> OS: Linux Ubuntu 20.04
> GRC: 3.8
> UHD: 4.0
> USRP: X310 with two UBX-160 daughterboards
>
> Attempting to receive and repeat a spectrum with low latency without using
> RX/TX streamers with RFNoC in GnuRadio.
> Currently using the default x310 image core.
> Steps I have taken to do this:
> Shown that I can receive correct signal with a RX-Radio RFNoC Block ->DDC
> RFNoC->Rx Streamer.
> Also shown that I can transmit correct signal via TX Streamer-.>DUC
> RFNoC->TX-Radio RFNoC Block.
> However, when attempting  RX-Radio RFNoC Block ->DDC RFNoC-> DUC
> RFNoC->TX-Radio RFNoC Block, there is no signal output and no TX/RX RX2
> link lights.
> Changing the Block Instances to match the existing default x310 image core
> Static connections made the flow graph run, but again with no lights or
> output.
>
> I found (through this mailing list) relevant material on this, the "Stupid
> RFNoC Tricks: Loopback"  in removing timestamps on received signals.
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> But, the current UHD build does not have the same filesystem or files
> (from what I can tell).
>
> Looking for guidance or reference in order to build this repeater.
>
> Robert
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
From 477e7ddaf1d4cef86f707beaa76c1ae13ddf9ffe Mon Sep 17 00:00:00 2001
From: Jonathon Pendlum 
Date: Sun, 18 Oct 2020 21:56:50 -0400
Subject: [PATCH 1/2] grc: Fix DUC parameters

---
 grc/ettus_rfnoc_duc.block.yml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/grc/ettus_rfnoc_duc.block.yml b/grc/ettus_rfnoc_duc.block.yml
index 5383902..bf96a5b 100644
--- a/grc/ettus_rfnoc_duc.block.yml
+++ b/grc/ettus_rfnoc_duc.block.yml
@@ -8,7 +8,6 @@ templates:
   make: |-
 ettus.rfnoc_duc(
 self.rfnoc_graph,
-${num_chans},
 uhd.device_addr(${block_args}),
 ${device_select},
 ${instance_index})
-- 
2.25.1


From b0011df686835c6be608742a82fd99e59e8e25b5 Mon Sep 17 00:00:00 2001
From: Jonathon Pendlum 
Date: Sun, 18 Oct 2020 22:05:28 -0400
Subject: [PATCH 2/2] rfnoc: Add RX->TX loopback support and example flowgraph

---
 examples/rfnoc/rfnoc_rxtx_loopback.grc | 301 +
 grc/ettus_rfnoc_graph.block.yml|   6 +
 grc/rfnoc.domain.yml   |   2 +-
 include/ettus/rfnoc_rx_radio.h |   6 +
 lib/rfnoc_graph_impl.cc|   3 +-
 lib/rfnoc_rx_radio_impl.cc |  15 ++
 lib/rfnoc_rx_radio_impl.h  |   3 +
 7 files changed, 334 insertions(+), 2 deletions(-)
 create mode 100644 examples/rfnoc/rfnoc_rxtx_loopback.grc

diff --git a/examples/rfnoc/rfnoc_rxtx_loopback.grc b/examples/rfnoc/rfnoc_rxtx_loopback.grc
new file mode 100644
index 000..5f60746
--- /dev/null
+++ b/examples/rfnoc/rfnoc_rxtx_loopback.grc
@@ -0,0 +1,301 @@
+options:
+  parameters:
+author: ''
+category: '[GRC Hier Blocks]'
+cmake_opt: ''
+comment: ''
+copyright: ''
+description: ''
+gen_cmake: 'On'
+gen_linking: dynamic
+generate_options: qt_gui
+hier_block_src_path: '.:'
+id: rfnoc_rxtx_loopback
+max_nouts: '0'
+output_language: python
+placement: (0,0)
+qt_qss_theme: ''
+realtime_scheduling: ''
+run: 'True'
+run_command: '{python} -u {filename}'
+run_options: prompt
+sizing_mode: fixed
+thread_safe_setters: ''
+title: RFNoC RX->TX Loopback
+window_size: ''
+  states:
+bus_sink: false
+bus_source: false
+bus_structure: null
+coordinate: [8, 8]
+rotation: 0
+state: enabled
+
+blocks:
+- name: ettus_rfnoc_graph
+  id: ettus_rfnoc_graph
+  parameters:
+alias: ''
+clock_source_0: ''
+clock_source_1: ''
+clock_source_2: ''
+clock_source_3: ''
+clock_source_4: ''
+clock_source_5: ''
+clock_source_6: ''
+clock_source_7: ''
+comment: 'For loopback, skip propagation
+
+  must be set to True'
+dev_addr: ''
+dev_args: ''
+num_mboards: '1'
+skip_propagation: 'True'
+time_source_0: ''
+time_source_1: ''
+time_source_2: ''
+time_source_3: ''
+time_source_4: ''
+time_source_5: ''
+time_source_6: ''
+time_source_7: ''
+  states:
+bus_sink: false
+bus_source: false
+bus_structure: null
+coordinate: [242, 8]
+rotation: 0
+state: true
+- name: rx_freq
+  id: variable_qtgui_range
+  parameters:
+comment: ''
+gui_hint: ''
+label: RX Frequency (Hz)
+min_len: '200'
+orient: Qt.Horizontal
+

Re: [USRP-users] E310 and RFNoC

[Jonathon Pendlum via USRP-users]

Hi Mike,

Did you cross-compile your RFNoC OOT module and install it to the E310?

Jonathon

On Tue, Feb 9, 2021 at 9:52 PM Mike via USRP-users <
usrp-users@lists.ettus.com> wrote:

> All,  I wanted to resurrect a problem that I had couple months ago that
> I put aside and would now like to fix.  The issue is that I get a python
> error when executing a flow graph on an E310 that was generated from GRC.
>
> The error is posted below.  For background I'm using UHD 3.15 with GNU
> Radio 3.7.  I've successfully created a bit file for the FPGA with a
> custom block (simple gain block).  I've updated the UHD xml file such
> that uhd_usrp_probe correctly identifies the new block.  Also, using a
> python command line tool, I've been able to import my module and enough
> of other modules like ettus and create a device3 variable to see that I
> can instantiate my mikes.digitalgain block.  Previously I've
> successfully generated non-RFNoC OOT modules and run them on the E310.
> So, I'm a little stumped how to get past this error.  Is there an
> additional step that I'm missing to compile the RFNoC module so that the
> E310 version of GNU Radio can successfully import the module and connect
> to it in the top block.  Is the warning about using the default block
> controller relevant?  I thought that simple blocks could be controlled
> through the XML files using the default controller.  Any help would be
> greatly appreciated...
>
> root@ni-e31x:~# ./e310_rx_spectrum.py
> [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106800;
> UHD_3.15.0.0-62-g7a3f1516
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=3092E3A,claimed=False
> [WARNING] [MPM.RPCServer] A timeout event occured!
> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003310)
> [WARNING] [RFNOC] Can't find a block controller for key digitalgain,
> using default block controller!
> [INFO] [0/digitalgain_0] Initializing block control (NOC ID:
> 0x1234123412341234)
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e310_sg1,mgmt_addr=127.0.0.1'.
> [WARNING] [RFNOC] Can't find a block controller for key FFT, using
> default block controller!
> [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
> [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
> Traceback (most recent call last):
>File "./e310_rx_spectrum.py", line 191, in 
>  main()
>File "./e310_rx_spectrum.py", line 180, in main
>  tb = top_block_cls(freq=options.freq,
> rfnoc_gain=options.rfnoc_gain, rx_gain=options.rx_gain)
>File "./e310_rx_spectrum.py", line 80, in __init__
>  self.mikes_digitalgain_0 = mikes.digitalgain(
> AttributeError: 'module' object has no attribute 'digitalgain'
> root@ni-e31x:~# ^C
>
>
> On 11/16/20 3:53 PM, Mike via USRP-users wrote:
> > All,
> >
> > I'm working with the E310 unit and have run up against a road block.
> > I've completed almost the entire application note, AN-823 (Getting
> > started with RFNoC Development).
> >
> > I'm using UHD 3.15 with GNU Radio 3.7.  I've successfully built a
> > custom FPGA with the tutorial's "gain" block.  I can see the new block
> > with the proper name with uhd_usrp_probe.
> >
> > I updated the XML files to allow GRC to implement the RFNoC block.
> >
> > Here is where I run into problems.  When I copy the gnuradio python
> > file over to the E310 I keep getting an error that states that the
> > 'module' object has no attribute 'gain'.
> >
> > root@ni-e31x:~# python e310_rx_spectrum.py
> > [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106800;
> > UHD_3.15.0.0-62-g7a3f1516
> > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> >
> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=3092E3A,claimed=False
> > [WARNING] [MPM.RPCServer] A timeout event occured!
> > [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> > [INFO] [0/Radio_0] Initializing block control (NOC ID:
> > 0x12AD10003310)
> > [WARNING] [RFNOC] Can't find a block controller for key gain, using
> > default block controller!
> > [INFO] [0/gain_0] Initializing block control (NOC ID: 0x)
> > [INFO] [MPM.PeriphManager] init() called with device args
> > `mgmt_addr=127.0.0.1,product=e310_sg1'.
> > [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> > [WARNING] [RFNOC] Can't find a block controller for key FFT, using
> > default block controller!
> > [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
> > [INFO] 

Re: [USRP-users] Burst transmissions consistently lead to hard lock up on X310

[Jonathon Pendlum via USRP-users]

Hi Geoff,

There has been a lot of investigation into a potential bug in the DmaFIFO
RFNoC block logic, however it has been very difficult to consistently
reproduce the issue. If you are able to provide code to reproduce the
issue, that would be a huge help. If you have access to Vivado, you can
also try applying the fix from this post and see if that helps:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057721.html
.

Jonathon

On Tue, Jan 26, 2021 at 1:56 PM Geoffrey Mainland via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I’m encountering a consistently reproducible problem on the X310 platform
> that causes the radio to lock up to the point where I have to power cycle
> it or flash it over JTAG to return it to a working state.
>
> My application is DragonRadio
> , Drexel’s DARPA SC2
> competition radio. This radio can use either a TDMA MAC, which uses timed
> TX bursts with a time spec, or an FDMA MAC, which uses TX bursts without a
> time spec (has_time_spec is false). The problem occurs in both cases, so
> it doesn’t seem to be related to the use of timed bursts.
>
> After several minutes of data transfer, one of the X310 radios will
> produce the following error and lock up:
>
> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet - 
> AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
> uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned 
> int]
>   at /root/dragonradio/dependencies/uhd/host/lib/rfnoc/ctrl_iface.cpp:151
>
> At this point, I have to power cycle the radio or flash it over JTAG to
> use it again.
>
> I am currently using UHD 3.15, but I have tried every UHD release since
> 3.9 (except 3.12), and the same problem occurs. UHD 4 fails too, but the
> error is slightly different:
>
> [ERROR] [X300] 192.168.40.2: x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
> terminate called after throwing an instance of 'uhd::assertion_error'
>   what():  AssertionError: reply.sequence == request.sequence
>   in virtual uint32_t 
> x300_ctrl_iface_enet::__peek32(uhd::wb_iface::wb_addr_type)
>   at 
> /root/dragonradio/dependencies/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:165
>
> The problem *does not* occur with UHD 3.9.
>
> Both MACs only end a burst when they run out of data to send continuously,
> and keeping them fed prevents the hang.
>
> My problem seems to be the same that is described in the closed GitHub UHD 
> issue
> 203 . As Brian Padalino
> suggests in that issue, resizing the DRAM FIFO so latency is reasonable and
> then zero stuffing the TX pipeline also prevents the radio from locking up.
> I have not tried skip_dram=1. I also haven’t figured out how to resize
> the DRAM FIFO with UHD 4, so I don’t know if the work-around applies to
> that version.
>
> This problem is 100% reproducible with a few minutes (1–20) of run time.
> Constructing a minimal failing example would be a lot of work, but the
> radio I’m using is open source, so anyone should be able to reproduce the
> problem (I’d be happy to provide additional instructions for doing so).
>
> Has anyone else seen this kind of behavior? There definitely seems to be a
> bug in the DRAM FIFO.
>
> Thanks,
> Geoff
> ___
> 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] Generate blocks with more than 1 input/output using rfnocmodtool

[Jonathon Pendlum via USRP-users]

HI Maria,

Rfnocmodtool does not support multiple inputs / outputs. You'll need to
edit the generated yaml file and use it with the utility
rfnoc_create_verilog to generate the block and noc shell. See
https://kb.ettus.com/RFNoC_4_Migration_Guide#Generating_a_Custom_Noc_Shell.
To edit the yaml file, you can refer to the RFNoC specification (
https://files.ettus.com/app_notes/RFNoC_Specification.pdf) or look at an
existing RFNoC block's yaml file that supports multiple ports such as the
FIR filter block (uhd/host/include/uhd/rfnoc/blocks/fir_filter.yml).

Also, as you've noticed, the generated yaml file has the wrong interface,
"fpga_iface: axis_data" should be "fpga_iface: axis_pyld_ctxt". That is a
known issue that is in the pipeline to be fixed.

Jonathon

On Wed, Jan 20, 2021 at 8:18 AM Maria Muñoz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> Is it possible to automatically create an rfnoc_block schema with, for
> example, 2 inputs and 2 outputs payload stream packets as in the addsub
> blockdata using rfnocmodtool?
> I can generate it using rfnoc_create_verilog.py through a block.yml file
> following the steps in :
> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Generating_Your_Block_Using_the_ModTool
> But I don't know the steps to do that using rfnocmodtool, it always
> generates a 1 input, 1 output block with axis_pyload_ctxt interface even
> though the block.yml generated in block folder has axis_data interface:
>
>
>
>
>
>
>
>
> *schema: rfnoc_modtool_argsmodule_name: multinoutversion:
> 1.0rfnoc_version: 1.0chdr_width: 64noc_id: 0x4321makefile_srcs:
> "/home/usr/rfnoc/src/gr-ettus/rfnoc-prueba/rfnoc/fpga/rfnoc_block_multinout/Makefile.srcs"*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *clocks:  - name: rfnoc_chdrfreq: "[]"  - name: rfnoc_ctrlfreq:
> "[]"  - name: cefreq: "[]"control:  sw_iface: nocscript  fpga_iface:
> ctrlport  interface_direction: slave  fifo_depth: 32  clk_domain: ce
> ctrlport:byte_mode: Falsetimed: Falsehas_status: Falsedata:
> fpga_iface: axis_data  clk_domain: ce  inputs:in:  item_width: 32
> nipc: 1  info_fifo_depth: 32  payload_fifo_depth: 32
> format: int32  mdata_sig: ~  outputs:out:  item_width: 32
> nipc: 1  info_fifo_depth: 32  payload_fifo_depth: 32  format:
> int32*
> *  mdata_sig: ~*
>
> Can I modify this file and somehow reload the files generated in the first
> attempt or is there other way to do what I want?
>
> Kind Regards,
>
> Maria
> ___
> 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 rfnoc-example gain block not recognized

[Jonathon Pendlum via USRP-users]

Hi Cedric,

There is a known issue with uhd_usrp_probe in UHD 4.0 / RFNoC4 where custom
RFNoC blocks do not report the block name correctly. You can use "auto
gain_blocks = graph->find_blocks("");"
to get your gain block.

Jonathon

On Thu, Jan 14, 2021 at 6:37 PM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> After following [1] (testing OOT gain block from example code),
> uhd_usrp_probe outputs:
>
> [...]
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xb16,
> 0x
> [...]
> |   |   * 0/Block#0
> |   |   * 0/DDC#0
> [...]
>
> and in C++:
>
> auto gain_blocks =
> graph->find_blocks("");
>
> is empty, while:
>
> rfnoc::example::gain_block_control::sptr gain_ctrl =
> graph->get_block("0/Block#0");
>
> failed with:
>
> "Error: LookupError:
> This device does not have a block of type
> rfnoc::example::gain_block_control with ID: 0/Block#0"
>
> Does anyone know what am I missing?
>
> [1]
> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Out-of-tree_Modules
>
> Regards
> --
>
> Cédric Hannotier
>
> ___
> 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] Testing single RFNoC block produces out-of-sequence (S) errors

[Jonathon Pendlum via USRP-users]

Hey Rob,

Since you are definitely dropping packets, I think trying DPDK is a good
next step.

Jonathon

On Tue, Jan 12, 2021 at 10:12 PM Rob Kossler  wrote:

> Hi Jonathon,
> I had not tried the "netstat -s" but after your suggestion I did and the
> "receive buffer errors" does increase after running my application.  I had
> previously increased the ring buffer size to  the max 4096.
> Rob
>
> On Mon, Jan 11, 2021 at 9:50 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Rob,
>>
>> If you run netstat -s before and after running your flowgraph, do you see
>> "receive buffer errors" in the UDP section increasing? I imagine you've
>> tried this but just in case: have you increased the ring buffer size with
>> "sudo ethtool -G  tx 4096 rx 4096"?
>>
>> Jonathon
>>
>> On Tue, Jan 5, 2021 at 6:08 PM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>> I created a custom pulse-detector block which attempts to pass/discard
>>> samples based upon an instantaneous power estimate. Each set of
>>> consecutively passed samples constitutes a "burst" (i.e. the EOB is set on
>>> the TLAST corresponding to the final passed sample of the burst).  A burst
>>> can have as few as 1 sample because my block does not prevent this.
>>>
>>> The block does what I expect in the testbench and even in the FPGA
>>> binary when using the same data as the testbench.  However, when using a
>>> long input stream (~250MSamps from previous recording that I have handy) to
>>> test this block running in the FPGA, I get out-of-sequence errors on
>>> receive. My graph is tx_streamer => pulse_detector => rx_streamer
>>> (actually, my pulse_detector is a 2x2 block so there are 2 tx_streamers and
>>> 2 rx_streamers, all of which are run in separate threads).
>>>
>>> I am wondering if the Sequence errors have nothing to do with my block
>>> but rather are related to the way Ubuntu handles incoming Ethernet data
>>> such that perhaps it is running out of RX descriptors. I have tried slowing
>>> down my Transmit and seen some improvement but without eliminating the
>>> errors completely. So, I'm wondering what suggestions others might have.
>>> My ideas are:
>>> * invest some time to get DPDK working.  With this, perhaps Sequence
>>> errors cannot occur??
>>> * try slowing down my Tx even further?
>>> * create artificial data sets (rather than real collected data) such
>>> that I can control the length of the output pulses
>>>
>>> Let me know if you have any suggestions.
>>> Rob
>>> ___
>>> 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] UHD 4.0 RFNoC testbench throws fatal error with GUI xsim

[Jonathon Pendlum via USRP-users]

Hi Cedric,

"Fatal: The connected block has an incompatible backend interface".


Try adding a short delay, such as #1 or @posedge( at the start of the
testbench to get past this.

Jonathon

On Tue, Jan 12, 2021 at 1:04 AM Cédric Hannotier 
wrote:

> On 11/01/21 21:40, Jonathon Pendlum wrote:
> > Hi Cedric,
>
> Hi Jonathon,
>
> > Does the issue go away if you comment out test.start_tb(...) and all
> > instances of test.start_test(...) and test.end_test() in the testbench?
>
> If I comment out test.{start,end}_tb, it fails with:
> "Fatal: The connected block has an incompatible backend interface".
> The testbench is unusable in this case (whatever the GUI value).
>
> If I comment out test.{start,end}_test, it prints:
> "Fatal: No test running",
> but proceed to run the full testbench (without reporting test status).
> With GUI=1, I get the same error message than previously:
> "FATAL_ERROR: Vivado Simulator kernel has discovered
> an exceptional condition from which it cannot recover"
>
> Regards
> --
>
> Cédric Hannotier
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Testing single RFNoC block produces out-of-sequence (S) errors

[Jonathon Pendlum via USRP-users]

Hi Rob,

If you run netstat -s before and after running your flowgraph, do you see
"receive buffer errors" in the UDP section increasing? I imagine you've
tried this but just in case: have you increased the ring buffer size with
"sudo ethtool -G  tx 4096 rx 4096"?

Jonathon

On Tue, Jan 5, 2021 at 6:08 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I created a custom pulse-detector block which attempts to pass/discard
> samples based upon an instantaneous power estimate. Each set of
> consecutively passed samples constitutes a "burst" (i.e. the EOB is set on
> the TLAST corresponding to the final passed sample of the burst).  A burst
> can have as few as 1 sample because my block does not prevent this.
>
> The block does what I expect in the testbench and even in the FPGA binary
> when using the same data as the testbench.  However, when using a long
> input stream (~250MSamps from previous recording that I have handy) to test
> this block running in the FPGA, I get out-of-sequence errors on receive. My
> graph is tx_streamer => pulse_detector => rx_streamer (actually, my
> pulse_detector is a 2x2 block so there are 2 tx_streamers and 2
> rx_streamers, all of which are run in separate threads).
>
> I am wondering if the Sequence errors have nothing to do with my block but
> rather are related to the way Ubuntu handles incoming Ethernet data such
> that perhaps it is running out of RX descriptors. I have tried slowing down
> my Transmit and seen some improvement but without eliminating the errors
> completely. So, I'm wondering what suggestions others might have.  My ideas
> are:
> * invest some time to get DPDK working.  With this, perhaps Sequence
> errors cannot occur??
> * try slowing down my Tx even further?
> * create artificial data sets (rather than real collected data) such that
> I can control the length of the output pulses
>
> Let me know if you have any suggestions.
> Rob
> ___
> 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] UHD 4.0 RFNoC testbench throws fatal error with GUI xsim

[Jonathon Pendlum via USRP-users]

Hi Cedric,

Does the issue go away if you comment out test.start_tb(...) and all
instances of test.start_test(...) and test.end_test() in the testbench?

Jonathon

On Thu, Jan 7, 2021, 12:49 Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> I have an issue with a testbench for a custom RFNoC block.
> The testbench template is taken from host/example/rfnoc-example
> and generated with rfnoc_create_verilog.py,
> as stated in the wiki [1].
>
> Running "make testbenches" completes without issue.
> However, running the testbench with GUI ("make testbenches GUI=1")
> failed with "FATAL_ERROR: Vivado Simulator kernel has discovered
> an exceptional condition from which it cannot recover" during the wave
> generation (1%), making the soft unusable.
> Files: Block [2], testbench [3], log [4].
> Version: UHD 4.0, Vivado 2019.1.
>
> I would like to simulate signal waveforms to check latency/timing.
>
> Any idea how to fix or to check latency/timing?
>
> [1]
> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Generating_Your_Block_Using_the_ModTool
> [2] https://paste.debian.net/hidden/5fa3b59e/
> [3] https://paste.debian.net/hidden/281ffb17/
> [4] https://paste.debian.net/hidden/db686780/
>
> Regards
> --
>
> Cédric Hannotier
>
> ___
> 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] rfNoc Replay Benchmark with N321

[Jonathon Pendlum via USRP-users]

Hi Dylan,

Are you saying you want a flowgraph like this?
Replay Block -> Radio TX
Radio RX -> Host (2x 10GigE)

If so, yes that is possible. See
http://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Dual_10_Gb_Interface
for how to benchmark rx. Also, take note of the "second_addr" device arg in
that example as it will be needed when you write your UHD app for the above
flowgraph.

Jonathon

On Wed, Dec 30, 2020 at 10:52 AM Dylan Baros via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good morning,
>
> I am interested in using a rfnoc replay block to benchmark rx over both 10
> gb ports, is that possible? I would like to dedicate both ports to
> receiving and the rfnoc replay block to transmit. I am using a N321.
>
> Thanks,
> Dylan
> ___
> 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] How to build RFNoC blocks in /lib/rfnoc/blocks directory?

[Jonathon Pendlum via USRP-users]

Hi Tuan,

A few of the in-tree RFNoC blocks do not have GRC support yet. The window
block is one of them. That will come in a future update, although I don't
have an exact timeline.

Jonathon

On Sun, Jan 3, 2021 at 11:24 PM Đình Tuấn Hoàng via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I'm learning RFNoC with UHD 4.0 and GRC 3.8. I have a question about how
> to build RFNoC blocks in /lib/rfnoc/blocks directory?
>
> For example, with window block, by doing the following steps:
> + Using rfnocmodtool to create test module with window block.
> + Copy yml file and fpga files from window lib directory to test directory.
> + Run cmake, testbench, make install command.
>
> although the window block has been built successfully, its GRC block
> appeared with only one user_register like gain example block.
> The gr_ettus has been installed but no GRC block for window block or some
> others.
> So how I can build the blocks in the lib directory with full registers and
> parameters?
> I can not find any guiding document about that thing, hope that it will be
> supported in the near future.
>
> Thank you!
> Tuan
> ___
> 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] Advice sought for custom FFT/Window RFNoC block

[Jonathon Pendlum via USRP-users]

Hey Rob,

I haven't thought of using axi_rate_change in this way, but I think it
should work fine. What issues are you seeing?

Jonathon

On Wed, Dec 23, 2020, 21:51 Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I created an RFNoC block (4.0) with both windowing and a Xilinx FFT IP
> core. In order to address the issue of partial packets arriving (or packets
> less than the FFT size of 4096 or higher), I added the axi_rate_change
> module (after looking for all options). Even though my block does not
> change rate, the axi_rate_change is convenient because it automatically
> drops partial packets and handles the header for you in the event of
> dropping partial packets. In my UHD block controller, I just set the M/N
> registers the same since the rate doesn't change.
>
> In any case, I am seeing some unexpected issues and now I'm questioning
> whether or not using the axi_rate_change block for this use case is a good
> idea.  Any comments/advice would be appreciated.
> Rob
> ___
> 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] RFNoC passing metadata on the dataplane

[Jonathon Pendlum via USRP-users]

Hi Jeff,

The m_axis_data_tdata and s_axis_data_tdata signals carry the CHDR packet's
data (usually SC16 samples) only. The tuser signals are for the CHDR
header. For instance, the incoming CHDR packet's header is output on
m_axis_data_tuser (regardless of the state of SIMPLE_MODE). When
SIMPLE_MODE=0, the header on s_axis_data_tuser will be used for the
outgoing CHDR packet's header. When SIMPLE_MODE=1, the header is handled
automatically by reusing the incoming packet's header. Technically,
SIMPLE_MODE works by storing the incoming packet's header in a FIFO. That
is why when using SIMPLE_MODE you must produce a packet for every packet
consumed, otherwise the FIFO will either overflow or underflow.

Jonathon

On Wed, Dec 16, 2020 at 6:50 PM Hodges, Jeff 
wrote:

> When  SIMPLE_MODE=0 for AXI_WRAPPER, is the header provided as the first
> data  word (or two data words if the timestamp is used) on
> m_axis_data_tdata?  It seemed redundant since it’s provided on
> m_axis_data_tuser, but the  Header is shown in the waveform on Slide 22 of
> the RFNOC Workshop (Part  2), so I wanted to clarify exactly what the data
> on m_axis_data_tdata  will be. Also, I assume that this same behavior
> should be mimicked on  s_axis_data_tdata when sending a packet out, but
> again, I wanted to  clarify.
>
>
> Thanks,
>
>
> Jeff
> --
> *From:* Jonathon Pendlum 
> *Sent:* Wednesday, December 16, 2020 12:05:58 AM
> *To:* Hodges, Jeff
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNoC passing metadata on the dataplane
>
> Hi Jeff,
>
>  Is  there a document describing the CHDR header for 3.15? Looking at the
>> code, there are significant differences between the header format in  3.15
>> and what’s in the 4.0 spec. I think I understand it from the code, but if
>> there’s a doc with more detail or explanation, that would be useful.
>
>
> The RFNoC3 CHDR header is described in the UHD 3.15 manual:
> https://files.ettus.com/manual_archive/v3.15.0.0/html/page_rtp.html.
> There is a bit more detail in these slides:
> https://kb.ettus.com/images/f/f6/rfnoc3_workshop_slides_202008_part_2.pdf
>
>  Is there a maximum payload size for a CHDR data packet
>
>
> Technically it is 64k bytes, but due to FIFO sizing in our devices, you
> should not exceed 7992 bytes / 1998 SC16 samples.
>
> Jonathon
>
> On Tue, Dec 15, 2020 at 11:18 PM Hodges, Jeff 
> wrote:
>
>> Thanks, Jonathan, that is very helpful. Two questions using SIMPLE_MODE=0
>> and AXI wrapper:
>>
>> 1.   Is  there a document describing the CHDR header for 3.15?
>> Looking at the  code, there are significant differences between the header
>> format in  3.15 and what’s in the 4.0 spec. I think I understand it from
>> the code, but if there’s a doc with more detail or explanation, that would
>> be useful.
>> 2.   Is there a maximum payload size for a CHDR data packet
>>
>> Jeff
>>
>> --
>> *From:* Jonathon Pendlum 
>> *Sent:* Friday, December 11, 2020 4:47:57 PM
>> *To:* Hodges, Jeff
>> *Cc:* usrp-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] RFNoC passing metadata on the dataplane
>>
>> Hi Jeff,
>>
>> RFNoC3 / UHD 3.15 does not support metadata. That is a new feature in
>> RFNoC4 / UHD 4.0, so option 2 is not possible.
>>
>> If you want to send out metadata in RFNoC3, I would suggest prepending it
>> to packets you send to AXI wrapper. You can still use SIMPLE_MODE as long
>> as you are producing a packet for every packet consumed. The different
>> input/output packet lengths do not matter as AXI wrapper internally
>> calculates the output packet length and updates the header automatically.
>>
>> Jonathon
>>
>> On Fri, Dec 11, 2020 at 3:48 PM Hodges, Jeff via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I meant rfnoc_create_verilog.py
>>>
>>>
>>>
>>> https://github.com/EttusResearch/uhd/blob/master/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py
>>>
>>>
>>> jeff
>>> --
>>> *From:* Hodges, Jeff
>>> *Sent:* Friday, December 11, 2020 3:44:41 PM
>>> *To:* usrp-users@lists.ettus.com
>>> *Subject:* RFNoC passing metadata on the dataplane
>>>
>>>
>>> I'd like to pass metadata over the dataplane using the available space
>>> in the CHDR header.  However, I cannot find an easy way to do this using
>>> UHD3.15.
>>>
>>>
>>> I've identified two possible approaches but I'm not sure either will
>>> work:
>>> (1) Set AXI_Wrapper (Simple_Mode =0) to require user provided CHDR
>>> header. It's unclear how to provide the header, and if this can be modified
>>> quickly.
>>>
>>> (2) Expose the AXI-Stream CHDR interface the way UHD4.0 does it:
>>>
>>> In UHD4.0 the verilog_image_builder.py includes the options to expose
>>> HDL interface:
>>>
>>> o Definition: Which HDL interface to expose
>>> o Options: “AXI-Stream CHDR” (axis_chdr), “AXI-Stream Payload Context”
>>> (axis_pyld_ctxt), or “AXI-Stream Data” (axis_data)
>>>
>>> If Option (2) is the recommended, can I just 

Re: [USRP-users] RFNoC DUC arguments

[Jonathon Pendlum via USRP-users]

Hi Ben,

A fix for this that will be merged soon. For now, you can use this patch.

Jonathon

On Tue, Dec 15, 2020, 16:09 Robert Wilson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello All,
>
> uhd 4.0
> gnuradio 3.8
> ubuntu 20.04
>
>
> When in GnuRadio and attaching a RFNoC Digital Upconverter to the  RFNoC
> Tx Radio Block we are receiving an error message:
>
> TypeError: make() takes 4 positional arguments but 5 were given
>
> Is this a known issue? How do you correct this?
>
> Thanks,
> Ben
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
From 81806669e94fb4012184741a2461f5cea633730c Mon Sep 17 00:00:00 2001
From: Jonathon Pendlum 
Date: Sun, 18 Oct 2020 21:56:50 -0400
Subject: [PATCH] grc: Fix DUC parameters

---
 grc/ettus_rfnoc_duc.block.yml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/grc/ettus_rfnoc_duc.block.yml b/grc/ettus_rfnoc_duc.block.yml
index 5383902..bf96a5b 100644
--- a/grc/ettus_rfnoc_duc.block.yml
+++ b/grc/ettus_rfnoc_duc.block.yml
@@ -8,7 +8,6 @@ templates:
   make: |-
 ettus.rfnoc_duc(
 self.rfnoc_graph,
-${num_chans},
 uhd.device_addr(${block_args}),
 ${device_select},
 ${instance_index})
-- 
2.25.1

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC passing metadata on the dataplane

[Jonathon Pendlum via USRP-users]

Hi Jeff,

 Is  there a document describing the CHDR header for 3.15? Looking at the
> code, there are significant differences between the header format in  3.15
> and what’s in the 4.0 spec. I think I understand it from the code, but if
> there’s a doc with more detail or explanation, that would be useful.


The RFNoC3 CHDR header is described in the UHD 3.15 manual:
https://files.ettus.com/manual_archive/v3.15.0.0/html/page_rtp.html. There
is a bit more detail in these slides:
https://kb.ettus.com/images/f/f6/rfnoc3_workshop_slides_202008_part_2.pdf

 Is there a maximum payload size for a CHDR data packet


Technically it is 64k bytes, but due to FIFO sizing in our devices, you
should not exceed 7992 bytes / 1998 SC16 samples.

Jonathon

On Tue, Dec 15, 2020 at 11:18 PM Hodges, Jeff 
wrote:

> Thanks, Jonathan, that is very helpful. Two questions using SIMPLE_MODE=0
> and AXI wrapper:
>
> 1.   Is  there a document describing the CHDR header for 3.15? Looking
> at the  code, there are significant differences between the header format
> in  3.15 and what’s in the 4.0 spec. I think I understand it from the code,
> but if there’s a doc with more detail or explanation, that would be useful.
> 2.   Is there a maximum payload size for a CHDR data packet
>
> Jeff
>
> --
> *From:* Jonathon Pendlum 
> *Sent:* Friday, December 11, 2020 4:47:57 PM
> *To:* Hodges, Jeff
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNoC passing metadata on the dataplane
>
> Hi Jeff,
>
> RFNoC3 / UHD 3.15 does not support metadata. That is a new feature in
> RFNoC4 / UHD 4.0, so option 2 is not possible.
>
> If you want to send out metadata in RFNoC3, I would suggest prepending it
> to packets you send to AXI wrapper. You can still use SIMPLE_MODE as long
> as you are producing a packet for every packet consumed. The different
> input/output packet lengths do not matter as AXI wrapper internally
> calculates the output packet length and updates the header automatically.
>
> Jonathon
>
> On Fri, Dec 11, 2020 at 3:48 PM Hodges, Jeff via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I meant rfnoc_create_verilog.py
>>
>>
>>
>> https://github.com/EttusResearch/uhd/blob/master/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py
>>
>>
>> jeff
>> --
>> *From:* Hodges, Jeff
>> *Sent:* Friday, December 11, 2020 3:44:41 PM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* RFNoC passing metadata on the dataplane
>>
>>
>> I'd like to pass metadata over the dataplane using the available space in
>> the CHDR header.  However, I cannot find an easy way to do this using
>> UHD3.15.
>>
>>
>> I've identified two possible approaches but I'm not sure either will work:
>> (1) Set AXI_Wrapper (Simple_Mode =0) to require user provided CHDR
>> header. It's unclear how to provide the header, and if this can be modified
>> quickly.
>>
>> (2) Expose the AXI-Stream CHDR interface the way UHD4.0 does it:
>>
>> In UHD4.0 the verilog_image_builder.py includes the options to expose HDL
>> interface:
>>
>> o Definition: Which HDL interface to expose
>> o Options: “AXI-Stream CHDR” (axis_chdr), “AXI-Stream Payload Context”
>> (axis_pyld_ctxt), or “AXI-Stream Data” (axis_data)
>>
>> If Option (2) is the recommended, can I just copy the code from
>> verilog_image_builder.py TEMPLATE such as below, or were other changes made
>> to make it incompatible with 3.15?
>>
>>  %if config['data']['fpga_iface'] ==
>> "axis_pyld_ctxt":
>> assign axis_data_clk =
>> ${config['data']['clk_domain']}_clk;
>> assign axis_data_rst =
>> ${config['data']['clk_domain']}_rst;
>>  <%include
>> file="/modules/axis_pyld_ctxt_modules_template.mako"/>
>>
>>
>>
>> Thanks,
>>
>> Jeff
>>
>>
>>
>> ___
>> 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] RFNoC passing metadata on the dataplane

[Jonathon Pendlum via USRP-users]

Hi Jeff,

RFNoC3 / UHD 3.15 does not support metadata. That is a new feature in
RFNoC4 / UHD 4.0, so option 2 is not possible.

If you want to send out metadata in RFNoC3, I would suggest prepending it
to packets you send to AXI wrapper. You can still use SIMPLE_MODE as long
as you are producing a packet for every packet consumed. The different
input/output packet lengths do not matter as AXI wrapper internally
calculates the output packet length and updates the header automatically.

Jonathon

On Fri, Dec 11, 2020 at 3:48 PM Hodges, Jeff via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I meant rfnoc_create_verilog.py
>
>
>
> https://github.com/EttusResearch/uhd/blob/master/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py
>
>
> jeff
> --
> *From:* Hodges, Jeff
> *Sent:* Friday, December 11, 2020 3:44:41 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* RFNoC passing metadata on the dataplane
>
>
> I'd like to pass metadata over the dataplane using the available space in
> the CHDR header.  However, I cannot find an easy way to do this using
> UHD3.15.
>
>
> I've identified two possible approaches but I'm not sure either will work:
> (1) Set AXI_Wrapper (Simple_Mode =0) to require user provided CHDR header.
> It's unclear how to provide the header, and if this can be modified quickly.
>
> (2) Expose the AXI-Stream CHDR interface the way UHD4.0 does it:
>
> In UHD4.0 the verilog_image_builder.py includes the options to expose HDL
> interface:
>
> o Definition: Which HDL interface to expose
> o Options: “AXI-Stream CHDR” (axis_chdr), “AXI-Stream Payload Context”
> (axis_pyld_ctxt), or “AXI-Stream Data” (axis_data)
>
> If Option (2) is the recommended, can I just copy the code from
> verilog_image_builder.py TEMPLATE such as below, or were other changes made
> to make it incompatible with 3.15?
>
>  %if config['data']['fpga_iface'] ==
> "axis_pyld_ctxt":
> assign axis_data_clk =
> ${config['data']['clk_domain']}_clk;
> assign axis_data_rst =
> ${config['data']['clk_domain']}_rst;
>  <%include file="/modules/axis_pyld_ctxt_modules_template.mako"/>
>
>
>
> Thanks,
>
> Jeff
>
>
>
> ___
> 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] Receiver error ERROR_CODE_LATE_COMMAND with txrx_loopback_to_file example.

[Jonathon Pendlum via USRP-users]

Hi Dylan,

Can you try adding "rx_usrp->set_time_now(uhd::time_spec_t(0.0));" after
line 526 in txrx_loopback_to_file.cpp, re-build, and see if that fixes your
issue?

Jonathon

On Wed, Dec 9, 2020 at 9:37 AM Dylan Baros via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good morning,
>
> I am attempting to run the txrx_loopback_to_file example with the
> following hardware:
>
> USRP N320 @ 192.168.20.2 10g sfp+ port 1
> USRP N321 @ 192.168.10.2 10g sfp+ port 0
>
> Connection between RF1 TX/RX on N321 to the RF1 RX on N320.
>
> My command to run is:
>
> ./txrx_loopback_to_file \
> --tx-args "type=n3xx,addr=192.168.10.2,master_clock_rate=250e6" \
> --rx-args "type=n3xx,addr=192.168.20.2,master_clock_rate=250e6" \
> --file "txrx_const0_rate50e6_sanslo_cw500e6_march3_11am.dat" \
> --settling 5 \
> --nsamps 5 \
> --tx-rate 50e6 \
> --rx-rate 50e6 \
> --tx-freq 500e6 \
> --rx-freq 500e6 \
> --ampl .5 \
> --tx-gain 10 \
> --rx-gain 40 \
> --tx-subdev "B:0" \
> --rx-subdev "B:0" \
> --tx-bw 10e6 \
> --rx-bw 10e6 \
> --wave-type "CONST" \
> --wave-freq 0 \
> --ref "external" \
> --tx-channels 0 \
> --rx-channels 0
>
>
> Output:
>
> Creating the transmit usrp device with:
> type=n3xx,addr=192.168.10.2,master_clock_rate=250e6...
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_4.0.0.0-25-g1a34ba8a
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=n3xx,product=n320,serial=31EDB79,claimed=False,addr=192.168.10.2,master_clock_rate=250e6
> [INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g90ce6062
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 31EDB79
> [INFO] [MPM.Rhodium-0] Enabling LO distribution board
> [INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
> [INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled
> in the device tree overlay (e.g., HG, XG images).
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,time_source=internal'.
> [INFO] [MPM.Rhodium-0] init() called with args
> `clock_source=internal,time_source=internal'
> [INFO] [MPM.Rhodium-1] init() called with args
> `clock_source=internal,time_source=internal'
> [INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
> [INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
> [INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
> [INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
> [INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training
> Complete
> [INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
> [INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
> [INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training
> Complete
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [INFO] [MPM.PeriphManager] init() called with device args
> `master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'.
> [INFO] [MPM.Rhodium-0] init() called with args
> `master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'
> [INFO] [MPM.Rhodium-1] init() called with args
> `master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'
> [INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
> [INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
> [INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
> [INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
> [INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training
> Complete
> [INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
> [INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
> [INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training
> Complete
>
> Creating the receive usrp device with:
> type=n3xx,addr=192.168.20.2,master_clock_rate=250e6...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=31F2BA2,claimed=False,addr=192.168.20.2,master_clock_rate=250e6
> [INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g90ce6062
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 31F2BA2
> [INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
> [INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled
> in the device tree overlay (e.g., HG, XG images).
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,time_source=internal'.
> [INFO] [MPM.Rhodium-0] init() called with args
> `clock_source=internal,time_source=internal'
> [INFO] [MPM.Rhodium-1] init() called with args
> `clock_source=internal,time_source=internal'
> [INFO] 

Re: [USRP-users] USRP B200 Function Question

[Jonathon Pendlum via USRP-users]

In case you don't know, N210s are still available for purchase on ettus.com.

On Mon, Dec 7, 2020, 17:30 Mark McAllister via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hmmm. It seems that using the B2xx series would cause us to make serious
> changes to a system that none of our current members have a good handle on
> how to adjust.
>
> Does anyone happen to have any suggestions for a proper ethernet
> compatible USRP that could act as a substitute for an N210 operating as a
> local oscillator?
>
> Pardon my ignorance with the topic, its not exactly my area of expertise.
>
> Mark McAllister
>
> Sent from my iPhone
>
> On Dec 7, 2020, at 11:21 AM, Marcus D Leech 
> wrote:
>
> Similarly it’s easy to get B2xx working with a super cheap SBC like the
> rPi boards or Odroids etc.
>
> Sent from my iPhone
>
> On Dec 7, 2020, at 2:16 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> 
> Mark,
> Just this past Friday, I had success controlling a B200mini directly from
> an N310 using the USB2 port on the N310.  Such a use case limits you to
> USB2 streaming for the B2xx and it also hogs CPU cycles from the N310.  Let
> me know if this is of interest to you I can can provide more info.
> Rob
>
> On Mon, Dec 7, 2020 at 1:56 PM Mark McAllister via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> My senior design team at California State University Northridge is
>> current using a USRP N210 as a  local oscillator for a smart antenna array.
>>
>> We're considering purchasing something from the B200 series in order to
>> replace it since we are current borrowing our N210.
>>
>> Our concern is that the B200 specifies the use of USB 3.0 for connecting
>> to a host computer, and we are currently connecting both an N210 and N310
>> to a router which connects all signals to a host computer.
>>
>> My main question is whether or not the B200 series will run properly
>> using a USB to Ethernet adapter or if the device MUST be connected directly
>> to the host computer via USB.
>>
>> Thank you for your time,
>> Mark McAllister
>> ___
>> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DPDK with UHD 4.0

[Jonathon Pendlum via USRP-users]

Hi Dario,

UHD 4.0 requires DPDK 18.11, but Ubuntu 20.04.1 packages version 19.11. See
the UHD manual for how to build version 18.11:
https://files.ettus.com/manual/page_dpdk.html#dpdk_installation.

Jonathon

On Tue, Dec 1, 2020 at 7:59 AM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> i'm trying to use DPDK with UHD 4 but it is not detected by cmake.
> i have ubuntu 20.04.1 which installs DPDK 19.11.3-0ubuntu0.2 when i use
> apt-get install dpdk dpdk-dev
>
> i tried passing manually environment variables for include and library
> directories but that doesn't work.
> can you please shed some light on this?
> 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

Re: [USRP-users] simulation error with uhd 4.0

[Jonathon Pendlum via USRP-users]

Hi Dario,

Unfortunately, Vivado's xsim simulator sometimes crashes when it runs into
syntax and elaboration errors. Make sure you don't have issues like signals
with multiple drivers, undriven signals, missing reset logic, typos, etc.
Note that these issues may be in code that is/seems unrelated to the cmul
instantiation.

Also, if you have access to ModelSim, I would highly suggest trying that
tool instead as it is far more robust than xsim. You can use the vsim make
target to use ModelSim.

Jonathon

On Sat, Nov 21, 2020 at 5:54 AM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> i'm trying to simulate a block where i'm using cmul. in order to have that
> compiled in i am including the following in my Makefile under rfnoc/fpga in
> my OOT directory:
>
> include $(BASE_DIR)/../lib/ip/Makefile.inc
> SIM_SRCS = $(abspath rfnoc_block_demod_tb.sv)  \
> $(LIB_IP_COMPLEX_MULTIPLIER_OUTS) \
>
> i tried also adding this to DESIGN_SRCS but when running simulation with
> Vivado 2019.1 i see the following error:
>
> ERROR: [XSIM 43-3983] Internal Compiler error encountered while processing
> aggregate association.
> ERROR: [XSIM 43-3915] Encountered a fatal error. Cannot continue.
> Exiting...
>
> if i remove cmul instance from my design simulation works.
>
> can you please shed some light on how to fix this?
> thanks,
>
> Dario Pennisi
> ___
> 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] Overrun on chan error 0 USRP e310 RFNoC

[Jonathon Pendlum via USRP-users]

Hi Ivan,

The Fosphor block averages and then significantly decimates the FFT output.
With the default settings, it has an output data rate comparable to a 500
kSPS stream. The Fosphor example is also only one channel.

I would suggest starting at a rate of 100 kSPS and increasing from there.
The E310's ARM processor has very low performance compared to a desktop
processor. It is mostly meant for overhead tasks and low rate DSP (100s
kSPS range). High rate DSP should be implemented in the FPGA fabric.

Jonathon

On Sat, Nov 21, 2020 at 6:54 AM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I was setting samp_rate to 1 msps and observed the same situation. In 
> addition, in the example fosphor samp_rate = 56 msps and no errors occur.
>
>
>
> сб, 21 нояб. 2020 г. в 05:12, Marcus D Leech :
>
>> There’s no way the fpga to ARM channel can support those data rates.
>> Lower your sample rate to 5msps and try again.
>>
>> Sent from my iPhone
>>
>> > On Nov 20, 2020, at 10:02 PM, Ivan Zahartchuk via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >
>> > 
>> > Hello, I want to launch two channels for receiving in parallel with
>> usrp e310 rfnoc. But on startup, I get an overrun error. What I need is
>> uninterrupted data transmission for phase analysis on both channels. How
>> can I do this?
>> > <Снимок экрана от 2020-11-21 04-50-17.png>
>> >
>> > <Снимок экрана от 2020-11-21 04-52-21.png>
>> >
>> > ___
>> > 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] Direction finding based on USRP E310 board

[Jonathon Pendlum via USRP-users]

Hi Ivan,

Try building with the gr-ettus maint-3.7 branch.

Jonathon

On Wed, Nov 18, 2020 at 1:08 PM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hello I am trying to install RFNoC for uhd 3.15. As far as I understand,
> this version supports RFNoC. And in order for me to have blocks in
> gnuradio, as I understand it, I need to install gr-ettus. But when
> installing, I get this error The found UHD version (3.15.0.0-3build2) is
> not compatible with the version required (4.0). how can I be in such a
> situation?
>
> ср, 18 нояб. 2020 г. в 16:24, Derek Kozel :
>
>> Hi Ivan,
>>
>> The TX/RX and RX2 are ports on the same receiver channel. As Julian says
>> there are two receivers, A and B. For a receive only application the RX2
>> ports are slightly better performing as they have one less switch that
>> the signal passes through.
>>
>> Regards,
>> Derek
>>
>> On 18/11/2020 14:01, Julian Arnold wrote:
>> > Ivan,
>> >
>> > to the best of my knowledge, there should not be any RX1 port.
>> > Instead, you should have two (coherent) channels "A" and "B" both
>> > allowing you to select one out of two available antenna ports when
>> > receiving ("TX/RX" or "RX2").
>> >
>> > Cheers,
>> > Julian
>> >
>> > On 11/18/20 10:31 AM, Ivan Zahartchuk via USRP-users wrote:
>> >>
>> >> Another question of interest is which channels are coherent? Rx1 and
>> >> RX2 or RX1 and RX / TX?
>> >>
>> >> вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice > >> >:
>> >>
>> >> Right!
>> >> Be careful, DOA estimation using only 2 antennas works but it’s not
>> >> so accurate.
>> >> Enjoy!
>> >>
>> >> Ivan
>> >>
>> >>  > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk
>> >> mailto:adray0...@gmail.com>> ha scritto:
>> >>  >
>> >>  > 
>> >>  >
>> >>  >
>> >>  >
>> >>  > That is, in theory, I can simply start two streams from two
>> >> channels and further process them using certain direction finding
>> >> algorithms?
>> >>  >
>> >>  >
>> >>
>> >>
>> >> ___
>> >> 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] E310 RFNOC OOT modules

[Jonathon Pendlum via USRP-users]

Hi Mike,

The might be due to the PYTHONPATH env variable not including the directory
where your OOT module is installed. Try looking for a directory like
/usr/lib/python2/dist-packages or similar and adding that to PYTHONPATH.

Jonathon

On Thu, Nov 12, 2020, 13:40 Mike via USRP-users 
wrote:

> I got an error when running a gnuradio python script on the E310.  The
> python script was created on the host machine in GRC and then copied
> (scp) over to E310.   I've done this successfully with built-in
> modules/blocks.  Now that I've created a custom FPGA, I've successfully
> updated the XML files in the OOT RFNoC module so that the new block
> shows up named correctly when I run "uhd_usrp_probe".
>
> The gnuradio error happens when I try to import the new module (in this
> case "import tutorial").
>
> root@ni-e31x:~# python e310_rx_spectrum.py
> Traceback (most recent call last):
>File "e310_rx_spectrum.py", line 19, in 
>  import tutorial
> ImportError: No module named tutorial
> root@ni-e31x:~#
>
> On the host side I am able to see the new OOT module and choose the new
> block (in this case, "gain") and create the new grc block diagram.  I
> compile the GRC diagram and then copy the python script over to the E310.
>
> I created a new "build-arm" directory in the rfnoc OOT directory (in
> this case, "rfnoc-tutorial").  I performed a cmake, make, and install
> similar to the other cross-compile steps with the result that I see the
> files being installed into the /e300 directory (i.e. the directory that
> is sshfs shared with the E310).  But, I still feel that something is
> missing since the embedded version of gnuradio is unable to locate the
> new tutorial module.
>
> Any suggestions?  I feel like I'm real close...
>
> Thanks,
>
> Mike
>
>
> ___
> 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] RFNoC Fosphor error

[Jonathon Pendlum via USRP-users]

Hi Robert,

Also use the "-DENABLE_QT=True" flag to build gr-ettus.

Jonathon

On Mon, Nov 9, 2020 at 9:43 AM Robert Wilson 
wrote:

> Hi Jonathon,
>
> I’ve gone ahead and given that a shot. I received a different message now:
>
> File “.../RFNoC.py” , line 164, in_init_
>   self.ettus_fosphor_display_0=ettus.fosphor_display(512, 64, 512)
>
> AttributeError:module ‘ettus’ has no attribute ‘fosphor_display’
>
> >>>Done (return code 1)
>
> Thanks,
> Ben
>
>
>
>
> On Sun, Nov 8, 2020 at 6:57 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Robert,
>>
>> Can you try rebuilding gr-ettus with the cmake flag
>> "-DCMAKE_BUILD_TYPE=Debug" and see if the issue goes away?
>>
>>
>> Jonathon
>>
>> On Fri, Nov 6, 2020 at 8:57 AM Robert Wilson 
>> wrote:
>>
>>>   Hi Jonathon,
>>>
>>> I've reduced both with no change.
>>>
>>> Ben
>>>
>>> On Wed, Nov 4, 2020 at 1:59 PM Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
 Hi Robert,

 Try using the maximum MTU size supported. Also, try reducing the FFT
 size and SPP to 512.

 Jonathon

 On Wed, Nov 4, 2020 at 8:45 AM Robert Wilson <
 robertbenwils...@gmail.com> wrote:

> My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is
> 6144 bytes. I’ve changed MTU to the max with no change in gnuRadio
> response. Is the 6144 bytes not enough?
>
> On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Ben,
>>
>> Try setting your NIC's MTU to 9000.
>>
>> Jonathon
>>
>> On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> OS: Linux Ubuntu 20.04.1 LTS
>>> GRC: 3.8
>>> UHD: 4.0
>>> USRP:X310 (HG)
>>>
>>> I have been looking at RFNoC only for a few weeks. I have followed
>>> the RFNoC Workshop 4 tutorial and successfully built my own custom gain
>>> block as well as implemented and FFT from existing blocks using the
>>> "Getting Started with RFNoC" document online.
>>>
>>> I am now attempting to get Fosphor up and running on my X310 to
>>> further understand bitstream generation from YAML files. At one point I
>>> believe there was an example bitstream that had the correct Fosphor
>>> configuration I don't see it in the build of UHD I have.
>>>
>>> I've attached my .yml file and a copy of my GRC flow graph.
>>> Below is the error message I'm receiving.
>>>
>>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
>>> UHD_4.0.0.0-1-gcf570707
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [GPS] No GPSDO found
>>> [INFO] [X300] Radio 1x clock: 200 MHz
>>> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
>>> 0xfd7d809a, 0x
>>> [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this
>>> device.
>>> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph...
>>> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
>>> gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph...
>>> gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command...
>>> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command...
>>>
>>> >>> Done (return code -11)
>>>
>>> More resources of this type of development would be welcome as well.
>>>
>>> Many Thanks,
>>> Ben Wilson
>>>
>>>
>>> ___
>>> 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] RFNoC Fosphor error

[Jonathon Pendlum via USRP-users]

Hi Robert,

Can you try rebuilding gr-ettus with the cmake flag
"-DCMAKE_BUILD_TYPE=Debug" and see if the issue goes away?

Jonathon

On Fri, Nov 6, 2020 at 8:57 AM Robert Wilson 
wrote:

>   Hi Jonathon,
>
> I've reduced both with no change.
>
> Ben
>
> On Wed, Nov 4, 2020 at 1:59 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Robert,
>>
>> Try using the maximum MTU size supported. Also, try reducing the FFT size
>> and SPP to 512.
>>
>> Jonathon
>>
>> On Wed, Nov 4, 2020 at 8:45 AM Robert Wilson 
>> wrote:
>>
>>> My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is 6144
>>> bytes. I’ve changed MTU to the max with no change in gnuRadio response. Is
>>> the 6144 bytes not enough?
>>>
>>> On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
 Hi Ben,

 Try setting your NIC's MTU to 9000.

 Jonathon

 On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello,
>
> OS: Linux Ubuntu 20.04.1 LTS
> GRC: 3.8
> UHD: 4.0
> USRP:X310 (HG)
>
> I have been looking at RFNoC only for a few weeks. I have followed the
> RFNoC Workshop 4 tutorial and successfully built my own custom gain block
> as well as implemented and FFT from existing blocks using the "Getting
> Started with RFNoC" document online.
>
> I am now attempting to get Fosphor up and running on my X310 to
> further understand bitstream generation from YAML files. At one point I
> believe there was an example bitstream that had the correct Fosphor
> configuration I don't see it in the build of UHD I have.
>
> I've attached my .yml file and a copy of my GRC flow graph.
> Below is the error message I'm receiving.
>
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_4.0.0.0-1-gcf570707
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [GPS] No GPSDO found
> [INFO] [X300] Radio 1x clock: 200 MHz
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
> 0xfd7d809a, 0x
> [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this
> device.
> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph...
> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
> gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph...
> gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command...
> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command...
>
> >>> Done (return code -11)
>
> More resources of this type of development would be welcome as well.
>
> Many Thanks,
> Ben Wilson
>
>
> ___
> 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] E310 FPGA Development

[Jonathon Pendlum via USRP-users]

Hi Mike,

Do not use pybombs, as the recipes are out of date and will just cause
confusion.

Make sure for UHD you are using the UHD-3.15.LTS branch and run "git
submodule update --init" so the fpga-src directory is updated to the
correct commit. Then try building your FPGA image again.

Jonathon

On Sat, Nov 7, 2020 at 9:44 PM Mike via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Wanted to add some additional information in hopes it might help point
> the way.
>
> An interesting thing that I found was that I was not able to get a
> working SD image through what I thought was the "normal" way.  I
> installed UHD v3.15.0.0 and then ran "uhd_images_downloader -t e310 -t
> sdimg".  This provided a file called usrp_e310_fs.sdimg in the
> /share/uhd/images folder.  I used both dd and bmaptool to copy the image
> onto a freshly erased SD card (partitions deleted).  The end result of
> both these methods was a SD card with 4 partitions (boot, data, primary,
> secondary).  Each time I installed this into the E310 it would error out
> in uboot with "ERROR: can't get kernel image".
>
> After some trial and error and poking around the Ettus web-site I found
> a directory of images:
>
>
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/e3xx_e310_sg1_sdimg_default-v3.15.0.0.zip.
>
> When I installed this image the E310 booted fine.  So, I downloaded the
> SDK that was in the same directory and was able to cross-compile UHD
> (and gnuradio) and see everything execute on the E310.  Everything seems
> great except the FPGA builds don't seem to work with this version of UHD.
>
> Another thing I noted was that when I installed the SDK it created a
> directory in the oe/sysroots folder for
> cortexa9t2hf-neon-oe-linux-musleabi whereas the pybombs installation is
> using:
>
> armv7ahf-vfp-neon-oe-linux-gnueabi
>
> Anyway, it seems like I'm trying to mix apples and oranges and I'm not
> sure what the correct combination is.
>
> Any ideas are greatly appreciated.
>
> Mike
>
> On 11/6/20 3:01 PM, Mike via USRP-users wrote:
> > Hi all - just joined today as I have recently started using the E310.
> >
> > My goal is to get a customized FPGA build running on the E310.
> >
> > Using the various application notes on the Ettus site I have been able
> > to install (manually with source) UHD, GNU Radio, gr-ettus. I've also
> > downloaded the SDK and cross-compiled each for the E310.  I've been
> > able to flash a SD image to a 32G SD card and then copy the newly
> > compiled development environment over to the E310.  I've been able to
> > verify gnuradio operation by implementing the simple FM receiver that
> > runs both on the embedded device and on the host.
> >
> > For the FPGA environment I used pybombs to install the rfnoc recipe. I
> > modified the rfnoc recipe as follows: (thinking that I need to ensure
> > FPGA is at 3.15 level which is what I manually cross-compiled the UHD
> > with)
> >
> > config:
> > packages:
> > uhd:
> > gitbranch: UHD-3.15.LTS
> > forcebuild: True
> > vars:
> >   config_opt: " -DENABLE_RFNOC=ON "
> > gnuradio:
> > gitbranch: maint-3.7
> > forcebuild: True
> > gr-ettus:
> > gitbranch: maint-3.7
> > forcebuild: True
> > uhd-fpga:
> > gitbranch: UHD-3.15.LTS
> >
> > I also have Xilinx, Vivado 2018.3.  I've been stepping through the
> > AN-823 (getting started with RFNOC).  Before getting into the more
> > complex development with rfnocmodtool, I started with simply creating
> > a new FPGA file with existing RFNOC modules.  I ran the script:
> > "./uhd_image_builder.py window fft -d e310 -t E310 -m 5
> > --fill-with-fifos" and successfully got the output files
> > (usrp_e310_sg1_fpga.bit/dts/rpt).  I then copied the output files onto
> > the E310 device into ~/fpga_bit.
> >
> > This is where I started to run into problems.  First, I verified that
> > I was using the newly installed version of UHD. I ran "which
> > uhd_usrp_probe" to verify
> > "/data/localinstall/usr/bin/uhd_usrp_probe".  I also checked the version:
> >
> > root@ni-e31x:/data/localinstall/usr/share/uhd/images# uhd_usrp_probe
> > --version
> > 3.15.0.HEAD-0-gaea0e2de
> >
> > Then I ran "uhd_image_loader --args type=e3xx --fpga-path
> > ~/fpga_bit/usrp_e310_sg1_fpga.bit"root@ni-e31x:/data/localinstall/usr/share/uhd/images#
>
> > uhd_image_loader --args type=e3xx --fpga-path
> > ~/fpga_bit/usrp_e310_sg1_fpga.bit
> >
> > With the following output:
> >
> > [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106800;
> > UHD_3.15.0.HEAD-0-gaea0e2de
> > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> >
> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=3092E3A,claimed=False,skip_init=1
> > [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> > [INFO] [MPMD] Claimed device without full initialization.
> > [INFO] [MPMD IMAGE LOADER] Starting update. This may take a 

Re: [USRP-users] rfnoc on uhd4 3.8/9

[Jonathon Pendlum via USRP-users]

Hi Dario,

Building UHD and gr-ettus from source is the correct approach. You can
either build GNURadio 3.8 from source or install it via your
distribution's package manager.

When building from source, make sure to use the following branches:
- UHD: UHD-4.0
- GNU Radio: maint-3.8
- gr-ettus: maint-3.8-uhd4.0

1) is there any way to use rfnoc in grc as of today that doesn't need
> manual creation of the block.yaml files?


I think your issue stems from using the wrong gr-ettus branch (maint-3.8 vs
maint-3.8-uhd4.0). Make sure you are using the branches I listed above.


> 2) why the fft block using the block.yaml definition from gr-uhd doesn't
> seem to work?


Do not build from GNURadio's master branch. Use the maint-3.8 branch.


> 3) how do I make oot blocks recognized by probe and grc?


R is aware of the uhd_usrp_probe Block#0 issue. It is benign and can be
ignored as it does not affect the functionality of your block.

Jonathon

On Sun, Nov 8, 2020 at 5:54 PM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I've been trying to create and use a rfnoc block for n310 within gnuradio
> 3.8 and uhd4.0. I first tried with pybombs but this doesn't not seem to
> work very well and there is no default recipe that works. I then moved to
> manual install from source and got something up using the maint-3.8 and
> uhd-4.0 branches however none of the rfnoc blocks in uhd 4.0 seem to be
> usable directly in gnuradio companion as the yaml files in uhd are not
> compatible with the yaml block files required by grc.
>
> I then moved to master branch of both repositories and this installs with
> gnuradio, some yaml files for some of the blocks in uhd, so I tired
> compiling a fpga with fft block as instructed in the tutorial but the fft
> would not produce output data.
>
> Finally I tried compiling the gain example block out of tree and installed
> its control block both with maint 3.8 branch (that uses swig) and master
> branches (that uses pybind11) but in both cases the block doesn't get
> recognized when i issue uhd_usrp_probe and it gets listed as block#0
> regardless of Ldconfig.
> I get it listed in grc after I created a second yaml file compatible with
> grc but of course running a graph will fail as it doesn't find the block
> control class, likely because in the installation process I don't see
> python bindings being generated for it, regardless of the binding creation
> mechanism.
>
> So my questions are:
> 1) is there any way to use rfnoc in grc as of today that doesn't need
> manual creation of the block.yaml files?
> 2) why the fft block using the block.yaml definition from gr-uhd doesn't
> seem to work?
> 3) how do I make oot blocks recognized by probe and grc?
>
> Thanks,
>
>
> Dario Pennisi
>
> ___
> 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] RFNoC Fosphor error

[Jonathon Pendlum via USRP-users]

Hi Robert,

Try using the maximum MTU size supported. Also, try reducing the FFT size
and SPP to 512.

Jonathon

On Wed, Nov 4, 2020 at 8:45 AM Robert Wilson 
wrote:

> My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is 6144
> bytes. I’ve changed MTU to the max with no change in gnuRadio response. Is
> the 6144 bytes not enough?
>
> On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Ben,
>>
>> Try setting your NIC's MTU to 9000.
>>
>> Jonathon
>>
>> On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> OS: Linux Ubuntu 20.04.1 LTS
>>> GRC: 3.8
>>> UHD: 4.0
>>> USRP:X310 (HG)
>>>
>>> I have been looking at RFNoC only for a few weeks. I have followed the
>>> RFNoC Workshop 4 tutorial and successfully built my own custom gain block
>>> as well as implemented and FFT from existing blocks using the "Getting
>>> Started with RFNoC" document online.
>>>
>>> I am now attempting to get Fosphor up and running on my X310 to further
>>> understand bitstream generation from YAML files. At one point I believe
>>> there was an example bitstream that had the correct Fosphor configuration I
>>> don't see it in the build of UHD I have.
>>>
>>> I've attached my .yml file and a copy of my GRC flow graph.
>>> Below is the error message I'm receiving.
>>>
>>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
>>> UHD_4.0.0.0-1-gcf570707
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [GPS] No GPSDO found
>>> [INFO] [X300] Radio 1x clock: 200 MHz
>>> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
>>> 0xfd7d809a, 0x
>>> [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this
>>> device.
>>> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph...
>>> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
>>> gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph...
>>> gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command...
>>> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command...
>>>
>>> >>> Done (return code -11)
>>>
>>> More resources of this type of development would be welcome as well.
>>>
>>> Many Thanks,
>>> Ben Wilson
>>>
>>>
>>> ___
>>> 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] RFNoC Fosphor error

[Jonathon Pendlum via USRP-users]

Hi Ben,

Try setting your NIC's MTU to 9000.

Jonathon

On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> OS: Linux Ubuntu 20.04.1 LTS
> GRC: 3.8
> UHD: 4.0
> USRP:X310 (HG)
>
> I have been looking at RFNoC only for a few weeks. I have followed the
> RFNoC Workshop 4 tutorial and successfully built my own custom gain block
> as well as implemented and FFT from existing blocks using the "Getting
> Started with RFNoC" document online.
>
> I am now attempting to get Fosphor up and running on my X310 to further
> understand bitstream generation from YAML files. At one point I believe
> there was an example bitstream that had the correct Fosphor configuration I
> don't see it in the build of UHD I have.
>
> I've attached my .yml file and a copy of my GRC flow graph.
> Below is the error message I'm receiving.
>
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_4.0.0.0-1-gcf570707
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [GPS] No GPSDO found
> [INFO] [X300] Radio 1x clock: 200 MHz
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
> 0xfd7d809a, 0x
> [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this device.
> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph...
> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
> gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph...
> gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command...
> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command...
>
> >>> Done (return code -11)
>
> More resources of this type of development would be welcome as well.
>
> Many Thanks,
> Ben Wilson
>
>
> ___
> 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] Building an Image using the image builder script

[Jonathon Pendlum via USRP-users]

Hi Roberto,

Do you get the same error if you try the v3.15.0.0 tag?

Jonathon

On Wed, Oct 21, 2020 at 12:13 PM Puertas Blanco, Roberto via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I´m trying to build an image following the commands described in
> https://github.com/EttusResearch/meta-ettus.
>
>
>
> Executing the repo command:
>
>
>
> repo init -u git://github.com/EttusResearch/oe-manifests.git -b v3.14.1.1
>
>
>
> I get the following errors:
>
>
>
> Downloading Repo source from https://gerrit.googlesource.com/git-repo
>
> Downloading manifest from git://github.com/EttusResearch/oe-manifests.git
>
> fatal: Couldn't find remote ref refs/heads/v3.14.1.1
>
> manifests:
>
> fatal: Couldn't find remote ref refs/heads/v3.14.1.1
>
>
>
> Otherwise, if I execute the repo command:
>
>
>
> repo init -u git://github.com/EttusResearch/oe-manifests.git -b thud
>
>
>
> and:
>
>
>
> repo sync
>
>
>
> The repository seems to be downloaded and synced but I get the following 
> errors after executing:
>
>
>
> ./meta-ettus/contrib/build_imgs_package.sh n3xx thud .
>
>
>
> Scripts seems to be executed but the process stops returning:
>
>
>
> Creating ./build/conf/auto.conf...
>
> meta-ettus/contrib/setup_build_env.sh: línea 181: ./build/conf/auto.conf: No 
> existe el fichero o el directorio
>
> You can now run 'bitbake '
>
> where  is e.g. developer-image or gnuradio-image.
>
> Launching build (gnuradio-image)...
>
> Loading cache: 100% 
> |##|
>  Time: 0:00:00
>
> Loaded 1262 entries from dependency cache.
>
> ERROR: Nothing PROVIDES 'gnuradio-image'
>
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> Build was not successful, stopping script
>
>
>
> Regards,
>
> Roberto
>
>
>
>
>
>
>
> --
>
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
> notificado que la lectura, utilización, divulgación y/o copia sin
> autorización está prohibida en virtud de la legislación vigente. En el caso
> de haber recibido este correo electrónico por error, se ruega notificar
> inmediatamente esta circunstancia mediante reenvío a la dirección
> electrónica del remitente.
> Evite imprimir este mensaje si no es estrictamente necesario.
>
> This email and any file attached to it (when applicable) contain(s)
> confidential information that is exclusively addressed to its recipient(s).
> If you are not the indicated recipient, you are informed that reading,
> using, disseminating and/or copying it without authorisation is forbidden
> in accordance with the legislation in effect. If you have received this
> email by mistake, please immediately notify the sender of the situation by
> resending it to their email address.
> Avoid printing this message if it is not absolutely necessary.
> ___
> 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] Error RFNoC X310 uhd_cal_tx_dc_offset

[Jonathon Pendlum via USRP-users]

Hi Jeff,

If you want to run code that relies on the multi-usrp API (pretty much any
example or utility that doesn't start with rfnoc_...), you will need to
include 1x or 2x DDC and DUC RFNoC blocks in your FPGA image. The safe bet
is to just include 2x of each.

Jonathon

On Thu, Oct 15, 2020 at 1:35 PM Hodges, Jeff via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi, I've built my own RFNoC block and everything works fine, except the
> tx_dc_offset is -40 dBc at all times, which seems pretty high.  I tried to
> follow the example from another user, since I have the same setup with my
> UBX in the second slot (B) but I get the error:
>
>
> >> uhd_cal_tx_dc_offset  --args="addr=192.168.10.2" --subdev "B:0"
> Error: RuntimeError: For legacy APIs, all devices require the same number
> of radios, DDCs and DUCs.
>
> I am using UHD 3.15-LTS with gr-ettus.
>
> In addition, I see the gr-ettus code appears to be commented out from
> gr-ettus/lib/rfnoc_radio_impl.cc  lines 144-158:
>
> // FIXME everything down from here needs to be mapped on to the block
> API
> void rfnoc_radio_impl::set_tx_dc_offset(bool enable, const size_t chan)
> {
>   //get_device()->set_tx_dc_offset(enable, chan);
> }
>
> void rfnoc_radio_impl::set_tx_dc_offset(const std::complex< double >
> , const size_t chan)
> {
>   //get_device()->set_tx_dc_offset(offset, chan);
> }
>
>
> Any advice on how to reduce the dc_offset?
>
> Thanks,
>
> Jeff
>
>
> ___
> 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] Failure: ERROR:add_1 must be in range [-1, DEPTH-1]

[Jonathon Pendlum via USRP-users]

The issue could be with the Window block then. Maybe it isn't getting
properly initialized or something changed from RFNoC 3 to RFNoC 4.

On Thu, Oct 15, 2020 at 3:44 PM Rob Kossler  wrote:

> OK. I'll check again.  One thing that's weird is that if I comment out
> either the Window or the FFT (and insert appropriate assign statements to
> replace the commented item), I don't get the error.  The error only occurs
> if both are in place.
> Rob
>
> On Thu, Oct 15, 2020 at 3:42 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hey Rob,
>>
>> I've ran into that issue when simulating Xilinx IP that use DSP48s. From
>> what I can tell, they don't handle X and U signal states properly. Try
>> double checking that all your signals are all properly driven.
>>
>> Jonathon
>>
>> On Thu, Oct 15, 2020, 15:08 Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>> I am getting this error (from the subject line) in a custom block I
>>> created that is effectively just the combination of a window block and a
>>> xilinx fft ip core. I am using UHD-4.0 (and Vivado 2019.1).
>>>
>>> After searching the user's list, I found some old posts from Jonathan
>>> Pendlum that indicated that this was a known issue related to the Xilinx
>>> FFT IP core.  The solution in the previous posts was to copy a "wave.do"
>>> file from the Ettus in-tree FFT tb folder.  I didn't find such a file in
>>> UHD-4.0 and so I'm wondering if there is a solution that works for UHD-4.0.
>>> Rob
>>> ___
>>> 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] Failure: ERROR:add_1 must be in range [-1, DEPTH-1]

[Jonathon Pendlum via USRP-users]

Hey Rob,

I've ran into that issue when simulating Xilinx IP that use DSP48s. From
what I can tell, they don't handle X and U signal states properly. Try
double checking that all your signals are all properly driven.

Jonathon

On Thu, Oct 15, 2020, 15:08 Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I am getting this error (from the subject line) in a custom block I
> created that is effectively just the combination of a window block and a
> xilinx fft ip core. I am using UHD-4.0 (and Vivado 2019.1).
>
> After searching the user's list, I found some old posts from Jonathan
> Pendlum that indicated that this was a known issue related to the Xilinx
> FFT IP core.  The solution in the previous posts was to copy a "wave.do"
> file from the Ettus in-tree FFT tb folder.  I didn't find such a file in
> UHD-4.0 and so I'm wondering if there is a solution that works for UHD-4.0.
> Rob
> ___
> 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] reading from ddr3 - high latency

[Jonathon Pendlum via USRP-users]

Hi Daniel,

The latency will be dominated by Xilinx's MIG IP that interfaces with the
DDR RAM. You can try looking at Xilinx's documentation and see what
parameters you can change to improve latency.

Jonathon

On Sat, Oct 3, 2020 at 9:10 AM Daniel Ozer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
> I'm working on usrp x310 .
> I create my own version of the replay block .
> I almost didn't change anything in the 2 state  machines in the
> axi_replay.v .
> everything worked fine  but then i saw in the chipscope that my replay
> block got data after 110 clks. (although the read ctrl ports indicate that
> the ddr start processing my read request )
> Is there any reason it takes 110clks to get the first data from a burst ?
> How can I lower this high latency ?
>
>
> ___
> 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] E300 sg3 images with uhd 4.0

[Jonathon Pendlum via USRP-users]

Hey Philip,

You are not the only person to report this. I'm working on getting an
answer, but it will take a bit longer.

Jonathon

On Thu, Oct 1, 2020 at 10:46 AM Philip Balister via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Ping? Anyone noticed sg3 units running slower with the uhd 4.0 image?
>
> Philip
>
> On 9/24/20 1:28 PM, Philip Balister via USRP-users wrote:
> > I booted an image from:
> >
> > https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/
> >
> > on a sg3 unit. The BogoMIPS display suggests the clocks are set to what
> > I expect for a sg1 unit though. I couldn't find any knobs in /sys or
> > /proc. I compared with the ancient release-4 image and that has the
> > number of BogoMIPS expected from that unit.
> >
> > Anyone at Ettus have any insite into how cpu clock speed is handled with
> > that image. Diffing the ps7 files didn't show many diffs in clock setup.
> > (And they looked like they came from a source besides vivado)
> >
> > Philip
> >
> > ___
> > 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] Speeding up build of usrp3 fpga code??

[Jonathon Pendlum via USRP-users]

Hi Eric,

Unfortunately no, but luckily that is usually a one time ordeal. The built
IP is kept separately from the main build, and it is not removed when you
run 'make clean'. Instead, you have to run 'make cleanall' if you want to
remove the IP build directory, which can be necessary if you switch UHD
releases and the supported Vivado version changed.

Jonathon

On Sat, Aug 29, 2020 at 8:07 PM Eric Blossom via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Folks,
>
> I'm in the midst of building the fpga code for the x310 on master.  I'm
> building on a 24-thread xeon with plenty of memory.
> Is there a magic flag, setting, etc that enables parallelism in generating
> the ip (the invocations of viv_generate_ip.tcl)??
> I tried make -j4 to no avail.
>
> I really like how the build system regenerates the ip for different
> families and part numbers.  NIcely done!
>
> Thanks!
> Eric
>
> ___
> 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] rfnoc data type‏

[Jonathon Pendlum via USRP-users]

Hi Daniel,

1. what is the change if  i pass data through rfnoc block as a byte type or
> as a sc16? Is there a change inside the fpga ?

2. At least in my uhd version the rfnoc: duc has only one type which is
> fc32 . can i change it to sc16 or anything else?


Almost all RFNoC blocks operate on SC16 samples, so you generally can only
use SC16. However, you may notice that UHD and GNU Radio examples usually
use FC32 samples. In that case, UHD automatically converts from FC32 to
SC16. You can also use SC16 samples (by setting CPU type to SC16), which in
that case there will not be any conversion. Note that type conversion only
happens when moving samples to / from the host and only if the CPU type /
OTW type differ. There is no enforcement or conversion of data types when
samples transfer between RFNoC blocks on the FPGA. For example, you can
make a RFNoC block that outputs 8-bit samples and hook that up to the DUC.
UHD will not stop you and the output will be meaningless. (As a side note,
this has improved in the UHD 4.0 release, where RFNoC blocks can define
what data type they accept and UHD will not allow a mismatch.)

3. If i pass data as from SW to the fpga as sc16 there should be any
> condition? like the, data has to be from -1 to 1 ?


If you are using CPU type SC16, then you should use a range of -32768 to
32767. I suspect you are asking for FC32's range though which is -1 to 1.

Jonathon

On Sat, Aug 29, 2020 at 9:14 AM Daniel Ozer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> hi everyone ,
> i have several question regarding to the rfnoc data type:
>
> 1. what is the change if  i pass data through rfnoc block as a byte
> type or as a sc16? Is there a change inside the fpga ?
>
> 2. At least in my uhd version the rfnoc: duc has only one type which is
> fc32 . can i change it to sc16 or anything else?
>
> 3. If i pass data as from SW to the fpga as sc16 there should be any
> condition? like the, data has to be from -1 to 1 ?
>
> ___
> 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] gr-ettus / GNU Radio 3.8

[Jonathon Pendlum via USRP-users]

Hi Sam,

That branch is still a work in progress.

Jonathon

On Sun, Aug 9, 2020 at 6:12 PM Carey, Samuel Craig via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Howdy,
>
>
>
> I see there’s a gr-ettus maint-3.8 branch for adding GNU Radio 3.8
> support, which seems to be finished as of this commit:
>
>
> https://github.com/EttusResearch/gr-ettus/commit/b69260655e974786ea6e611bd91ab578b13ec72a
>
>
>
> Is this branch good to go?
>
> Are there any known drawbacks?
>
> Will I theoretically be able to use this in the context of rfnoc/e310
> cross-compiling, etc.?
>
>
>
> I ask because there are a couple open issue about 3.8 without any replies
> (#37, #46), so I’m wary of investing time if it’s not ready.
>
>
>
> Thanks,
>
> Sam
> ___
> 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] Replay Block for UHD 3.15

[Jonathon Pendlum via USRP-users]

Hi Rob,

2) I have issues with repeated streaming (starting / stopping repeatedly)
> if the Replay block is connected through the DUC to the Radio.  I have not
> been able to resolve these.


Can you describe the issue you are running into? Is it a "no response
packet" error?

Jonathon

On Thu, Jul 30, 2020 at 12:35 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I use the Replay block for both the X310 and N310. But, there are a couple
> of issues that limit its usefulness. Is there a chance this could be
> addressed on 3.15?  (I realize that the issues may go away with UHD 4.0).
>
> 1) For the N310, you cannot connect the 4-port Replay block directly to
> the two 2-port Radio blocks.  This is a limitation of the noc_block to
> crossbar bandwidth. It could be fixed if the default image included two
> 2-port Replay blocks rather than one 4-port block.  (There is another
> concern as to whether the external RAM can handle the bandwidth of 500 MS/s
> that is needed, but I think that as long as you're only streaming out of
> the block (not streaming in simultaneously) it should work).  Note that the
> same issue holds for the X310 which has a single 2-port Replay block that
> restricts it from connecting to the two Radio blocks because of the same
> noc_block to crossbar bandwidth limitation.  It could be fixed by having
> two 1-port Replay blocks.
>
> 2) I have issues with repeated streaming (starting / stopping repeatedly)
> if the Replay block is connected through the DUC to the Radio.  I have not
> been able to resolve these.
>
> Rob
> ___
> 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] usrp_x310_fpga_RFNOC_HG.bit

[Jonathon Pendlum via USRP-users]

Hi Cherif,

I'll send you the bitstream directly.

Jonathon

On Fri, Aug 14, 2020, 16:07 cherif chibane via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I would like to use teh X300 bit file:   usrp_x310_fpga_RFNOC_XG.bit.
> Does it exist somewhere or do I need to re-create it? I used  
> uhd_images_downloader
> to download the bitfiles but it did not come with the files downloaded.
>
> Thanks,
>
> Cherif
>
>
>
> Does it exist somewhere or do I need to re-create it. I used  
> uhd_images_downloader
> but it did not come with the files downloaded.
>
>
> Thanks,
>
> Cherif
>
>
> 
> Cherif Chibane
> ___
> 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] Version for UHD, GNU radio and Gr-Ettus

[Jonathon Pendlum via USRP-users]

Hello Cherif,

Here the versions you should use:
UHD: branch UHD-3.15.LTS
GNU Radio: tag v3.7.14.0
gr-ettus: branch maint-3.7

Jonathon

On Thu, Aug 13, 2020 at 3:47 PM cherif chibane via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello folks,
>
> Following up on yesterday’s discussion, can somebody send me the right
> versions for GNU radio and gr-ettus to use with UHD 3.15.LTS.
>
> Thanks
> Cherif
> --
> 
> Cherif Chibane
> ___
> 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] Starting with FPGA USRP

[Jonathon Pendlum via USRP-users]

Hi Anthony,

You can generate an ISE project by going to the directory usrp3/top/b200
and running "make PROJECT_ONLY=1 B200". The project file will be located in
the build directory.

Jonathon

On Wed, Aug 12, 2020 at 8:51 AM Anthony B. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I recently acquired a USRP B200 and I would like to start developing
> within it. I've followed the FPGA Manual :
> https://files.ettus.com/manual/md_usrp3_build_instructions.html
>
> So I have now Xilinx ISE and the build files from the FPGA. I was
> wondering where to start with these files - can we somehow open them in the
> Xilinx Tools ? How can we have a starting view on how the USRP B200 FPGA is
> composed ?
>
> Thanks for your answers !
>
> Best,
> Anthony
> ___
> 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] CHIPSCOPE ERROR (RFNOC)

[Jonathon Pendlum via USRP-users]

You probably have old ILA probe constraints that are no longer valid. They
are written to the "x300_dram.xdc" constraints file and need to be removed.
Use "git checkout x300_dram.xdc" to reset the file. Alternatively, if using
the Vivado GUI, you can remove all the probes via the Chipscope wizard (see
"Setup Up Debug" under Synthesis -> Open Synthesized Design).

On Tue, Jul 28, 2020 at 2:18 AM Jayant Chhillar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
> I am trying to generate a bitstream for X310 board with the FFT block
> along with few other ettus provided blocks. However, at the time of logic
> optimization step I get this error
>
> ERROR: [Chipscope 16-213] The debug port 'u_ila_0/probe1' has 9
> unconnected channels (bits). This will cause errors during implementation.
>
> I’m not able to identify the source of this error. Also, before this
> bitstream generation I did create a bitstream where I used chipscope using
> the methode defined here:
>
> https://kb.ettus.com/Debugging_FPGA_images
>
> And was able to do that without any errors. However, since then I have
> been getting the above mentioned error.
>
> Thanks
> ___
> 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] Sync problem in custom DUC

[Jonathon Pendlum via USRP-users]

Hi Carlos,

Where are the sine waves coming from / how are they generated? What is
your entire flowgraph? What sampling rate are you running at?

Jonathon

On Fri, Jul 10, 2020 at 2:45 PM Carlos Alberto Ruiz Naranjo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> This is the code for the adder (between dds_timed and axi_wrapper):
>
> assign s_axis_data_tvalid2[0] = s_axis_data_tvalid[1] &
> s_axis_data_tvalid[0];
> assign s_axis_data_tvalid2[1] = s_axis_data_tvalid[1] &
> s_axis_data_tvalid[0];
>
> assign s_axis_data_tuser2 = s_axis_data_tuser;
>
> assign s_axis_data_tlast2[0] = s_axis_data_tlast[0];
> assign s_axis_data_tlast2[1] = s_axis_data_tlast[1];
>
> assign s_axis_data_tdata2[15: 0] = s_axis_data_tdata[47:32] +
> s_axis_data_tdata[15: 0];
> assign s_axis_data_tdata2[31:16] = s_axis_data_tdata[63:48] +
> s_axis_data_tdata[31:16];
>
> assign s_axis_data_tready_aux = ~|(~{s_axis_data_tready_out[0
> ],s_axis_data_tready_out[1]} & 2'b11);
> assign s_axis_data_tready[0] = s_axis_data_tvalid[0] & s_axis_data_tvalid[
> 1] & s_axis_data_tready_aux;
> assign s_axis_data_tready[1] = s_axis_data_tvalid[0] & s_axis_data_tvalid[
> 1] & s_axis_data_tready_aux;
>
> El vie., 10 jul. 2020 a las 11:59, Carlos Alberto Ruiz Naranjo (<
> carlosruiznara...@gmail.com>) escribió:
>
>> Hi,
>>
>> I'm customizing the DUC block to do it 2input:1output
>>
>> input 0  ---> DUC --->
>>   add ---> output
>> input 1  ---> DUC --->
>>
>> I have added an addsub module between dds_timed and axi_wrapper.
>> Apparently it works fine. I can see two tones in the output if the inputs
>> are 2 tones.
>>
>> But I have a synchronization problem. If input_0 is a sine and input_1 is
>> a sine with pi phase the output should be 0. And the output is 0, but after
>> a while (3 minutes) no. I think that the channels are out of sync before
>> the adder.
>>
>> Any idea about what is happening?
>>
>> Thank you :)
>>
> ___
> 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] e310, RFNOC, GNURadio Full Duplex, Custom RFNOC Block

[Jonathon Pendlum via USRP-users]

Hi Andrew,

AXI Wrapper's SIMPLE_MODE can only be used with blocks that do not perform
a rate change. Since you are using keep_one_in_n, your block is performing
a decimation of sorts, so you cannot use SIMPLE_MODE. You should manually
set up the header on tuser using noc_block_keep_one_in_n.v as an example.
This may be the cause of your problem.

Jonathon

On Wed, Jul 8, 2020 at 7:26 PM Andrew Payne via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Actually I have found a clue! In
> usrp3/lib/rfnoc/noc_block_keep_one_in_n.v, axi_wrapper simple_mode is
> set to off, instead opting to use cvita_hdr_modify.  I opted to use
> keep_one_in_n.v in my custom noc_block, BUT, I have set simple mode to
> 1.  And if I go into usrp3/lib/rfnoc/axi_wrapper.v, at the top the
> comments for SIMPLE_MODE say "Automatically handle header
> (s_axis_data_tuser), packets must be consumed / produced 1-to-1".
> What does this mean?  That the CEs installed at the crossbar are all
> beholden to the rate of this CE?  Because remember with my issue, my
> custom RFNOC block (which incorporates keep_one_in_n.v with simple
> mode enabled) works well, the TX with DUC alone works well, but TX
> with DUC and FIFO plus my custom RFNOC block seems to greatly
> attenuate TX.  Could the TX stream be slowed down by my custom RFNOC
> CE?
>
> On Wed, Jul 8, 2020 at 4:37 PM Andrew Payne  wrote:
> >
> > I have an issue with my setup I'm hoping to solve.
> >
> > I have an e310 running the UHD 3.15 LTS image.
> >
> > I have created one custom RFNOC block, which has 2 RX streams, and it
> > is composed of the following chain: complex to magnitude ---> moving
> > sum ---> keep one in n (n=2048) ---> FIFO with input parameter SIZE=5,
> > so then I don't need the RFNOC FIFO block to save space when
> > generating the FPGA image file.  The moving sum block generates a sum
> > from a power of 2 samples, then I feed the keep one in n block with a
> > resulting sum whose LSBs are truncated, effectively dividing by a
> > power of 2 to effectively generate a moving average. I am using the
> > AXI Wrapper with Simple Mode, noc shell, etc, all generated from the
> > rfnoc mod tool.
> >
> > It works great, but I also have a TX output signal, just a sine wave,
> > in my gnuradio flowgraph.  Its output, depending on the RF center
> > frequency, is greatly attenuated (the greatest I can get it is like
> > -39dBm, but it falls off to -55).  But if I just have the TX output
> > alone without my RX RFNOC block, I can get the output over 0dBm or
> > more, haven't tried going higher than that.
> >
> > My question is, how can I get the TX signal higher with my full duplex
> > RFNOC setup?  Could anything about the RX chain be affecting my TX
> > samples, like could it be somehow deleting samples?  Do I need to tag
> > the streams in GNURadio so they don't interfere or something?
> >
> > Thanks,
> > Andrew
>
> ___
> 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] uhd_image_builder_gui.py cannot select makefile.src

[Jonathon Pendlum via USRP-users]

Hi Jeff,

Are you using the rfnoc-devel branch as shown in the KB article? If so, I
would suggest switching to the UHD-3.15.LTS branch for both UHD and the
FPGA repo and using the master branch for gr-ettus. That might completely
solve your issue.

Jonathon

On Tue, May 26, 2020 at 7:02 PM Hodges, Jeff via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When I run ./uhd_image_builder_gui.py, the GUI cannot select the
> makefile.src from my OOT block. The file is grayed-out when I try to select
> it from the OOT directory:
> {USER_PREFIX}/src/{USER-OOT-moddir}/rfnoc/fpga-srcs/
>
>
>
> In addition, it gives the following warning message, which may or may not
> be related:
>
>
>
> Gtk-Message: GtkDialog mapped without a transient parent. This is
> discouraged.
>
>
>
>
>
> I’m following the guide to build the OOT gain block. I have written built
> the OOT gain block and run the test bench successfully and ran make install.
>
>
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
>
>
> Any ideas?
>
>
>
> Jeff
> ___
> 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] How to debug timed commands on FPGA side?

[Jonathon Pendlum via USRP-users]

Hi Lukas,

2.) What happens when the command queue is full? Is the command dropped,
> does USRP crash or anything else? (above link is unclear about that)
> Can we change this behavior?


UHD is aware of the size of the command FIFOs in each RFNoC block. It keeps
track of the number of commands in flight and uses the response packets to
know when those commands have been consumed. Therefore, the command FIFO
should never get full (famous last words). Of course, it is always possible
there is a bug. For example, maybe UHD doesn't properly track FIFO fullness
when using timed versus untimed commands. Here is a FPGA code tweak worth
trying that is quicker than chipscope:

In cmd_pkt_proc.v, change line 70 from:
axi_fifo #(.WIDTH(65), .SIZE(FIFO_SIZE)) axi_fifo (
to
axi_fifo #(.WIDTH(65), .SIZE(FIFO_SIZE+2)) axi_fifo (

This change will quadruple the size of the command FIFOs without UHD being
aware of it. If you still have the same issue, then it is very unlikely to
be due to the command FIFO in the radio core overflowing since there is
plenty of room for extra commands. If you want to be absolutely certain the
command FIFO is not overflowing, then you'll need to use chipscope to look
at the cmd_tvalid and cmd_tready signals in cmd_pkt_proc.v. If cmd_tvalid
== 1 and cmd_tready == 0 ever occurs, that is an overflow.

If somehow the command FIFO gets full, then a lockup might occur in the
crossbar and that would be very obvious as you'd have to hard reset to
clear it. Also, even if commands are late, they are still processed instead
of being dropped.

Jonathon

On Wed, Jun 10, 2020 at 9:00 PM Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Nick,
>
> Good point with Wireshark and coincidentially I tried exactly that today.
> Both captures were fairly identical. But what's worse, things started to
> become more unreproducible (for example, depending on which blocks I add).
>
> Again, what not works is that timed commands sometimes are not executed
> when they are supposed to be.
> I execute them periodically (e.g. every 100ms, 10ms, 1ms), then capture
> the response and slice them into equal blocks in MATLAB.
> The action of the timed commands (for example, retune or gain change)
> should always happen at the same time. Instead a few of them (maybe 3%)
> happen sometime in between and mess up verything.
>
> How would one go to debug this without having to acquire deep Verilog
> knowledge?
> I am 99.99% positive that the timed commands I issue via tx_command tag
> are correct.
>
> Are there definite answers to the questions:
>
> 1.) How many commands do the command queues have exactly on the X310? (
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
> says 5-8 but other sources say 16 or 32).
> 2.) What happens when the command queue is full? Is the command dropped,
> does USRP crash or anything else? (above link is unclear about that)
> Can we change this behavior?
> 3.) How can we figure out what is the maximum speed to issue timed
> commands reliably?
> What does this depend on and which parameters need to be tweaked?
>
> For example, what is the fastest rate I can issue timed commands (ignoring
> settling times etc) on a X310 over 10Gbe?
>
> I am thinking that maybe I am sending timed commands too fast such that
> the command queue overflows.
> However:
> a.) How can an overflowing command queue explain that timed commands not
> being executed on time?
> b.) I played around setting send_buff_size to different values, down to
> send_buff_size=10240 (10kB). If I understand correctly, that means that the
> USRP should never receive more than 10kB data at once (one chunk holds
> 10240/(10e6*2*2)=256us at 10MS/s which means the if each frame has one
> timed command that should support sending a timed command every 256us).
> Unfortunately nothing changes here.
>
> Using tx_command tag in USRP Source should ensure that the commands never
> arrive late on the FPGA (otherwise the data would also arrive late and I
> would get LLL's but I don't).
>
> I thought the most straight forward would be to debug the FPGA itself but
> that seems to open more issues that it solves.
>
> Thanks,
> Lukas
>
>
>
> Gesendet: Mittwoch, 10. Juni 2020 um 19:18 Uhr
> Von: "Nick Foster" 
> An: "Lukas Haase" 
> Betreff: Re: [USRP-users] How to debug timed commands on FPGA side?
>
> I'd start by using Wireshark. There's a dissector for CHDR packets
> included in UHD (uhd/tools/dissectors). Wireshark has excellent filtering
> and analysis tools. You should be able to see your C++-timestamped packet
> go out, and compare it to the Python generated version. This will take a
> couple of hours to set up, run, and analyze.
>
> Following that, if you still can't find a difference, recompile an FPGA
> image which includes an ILA core, hooked up to some radio signals. Try to
> avoid having to do this, because it will take a long time, and you'll get
> very deep into the radio core. On the 

Re: [USRP-users] E310 Cross-compiling UHD / GNU Radio (volk?)

[Jonathon Pendlum via USRP-users]

Hi Jeff,

I'm looking into this cross compiling issue. Using this flag with cmake:
-DCMAKE_ASM_COMPILER_ARG1:STRING="-mcpu=cortex-a9" seems to work as a
temporary workaround for the volk error.

Jonathon

On Fri, Apr 3, 2020 at 8:31 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> $ which gnuradio-config-info
> /home/user/sdr/e310/rfnoc/installs/bin/gnuradio-config-info
> $ gnuradio-config-info -v
> 3.7.14.0
>
> I used maint-3.7.  This is what I did for the non-ARM build:
>
> $ git clone --recursive https://github.com/gnuradio/gnuradio
> $ cd ~/sdr/e310/rfnoc/src/gnuradio/
> $ git checkout maint-3.7
> $ git submodule update --init --recursive
>
>
> This is from the directions located at the first build of GNU Radio
> located in the application note:
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Building_GNU_Radio
> .
>
> Jeff
>
> --
> *From:* USRP-users  on behalf of Ron
> Economos via USRP-users 
> *Sent:* Friday, April 3, 2020 7:17 AM
> *To:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] E310 Cross-compiling UHD / GNU Radio (volk?)
>
>
> What version of GNU Radio are you trying to build? If it's 3.8 or 3.9, you
> need a newer version of VOLK.
>
>
> Ron
>
>
> On 4/3/20 05:10, Jeff S wrote:
>
> Ron,
>
> I re-created my build-arm directory and tried adding this with the same
> results.
>
> Philip, in a previous email, had me looking through the Volk issues, and
> maybe there is one related that is OPEN:  "Missing NEON Implementations
> #243" (https://github.com/gnuradio/volk/issues/243).  I am still trying
> to understand it to see if there's something I can do related to it.  Just
> have been trying to follow the Ettus application notes.
>
> Jeff
>
> --
> *From:* USRP-users 
>  on behalf of Ron Economos via
> USRP-users  
> *Sent:* Thursday, April 2, 2020 6:59 PM
> *To:* usrp-users@lists.ettus.com 
> 
> *Subject:* Re: [USRP-users] E310 Cross-compiling UHD / GNU Radio (volk?)
>
>
> Try adding this to your CMake command line.
>
>
> -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon
> -mtune=cortex-a9" -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard
> -mfpu=neon -mtune=cortex-a9" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a
> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -g"
>
>
> Ron
>
>
> On 4/2/20 13:45, Jeff S via USRP-users wrote:
>
> I had a problem with the initial build environment when setting up my
> environment for the E310.  Up to now, I have been able to get the UHD
> cross-compiled, a new image for the microSD card built, and checked up to
> the *# uhd_usrp_probe* step on the E310 (from
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source)
> with success.
>
> I am now at the point where I am *Cross-Compiling GNU Radio*.  I have
> been using *e3xx_e310_sdk_default-v3.15.0.0.zip*, and at the point where
> I am building GNU Radio, I am getting an error:
>
> *Scanning dependencies of target volk_obj*
> [  3%] Building ASM object 
> volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:
>  Assembler messages:
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:9:
>  Error: selected processor does not support `pld [r1:128]' in ARM mode
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:20:
>  Error: selected processor does not support `pld [r4:128]' in ARM mode
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:44:
>  Error: selected processor does not support `sxth r6,r6' in ARM mode
> volk/lib/CMakeFiles/volk_obj.dir/build.make:1572: recipe for target 
> 'volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o'
>  failed
> make[2]: *** 
> [volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o]
>  Error 1
> CMakeFiles/Makefile2:220: recipe for target 
> 'volk/lib/CMakeFiles/volk_obj.dir/all' failed
> make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2
> Makefile:162: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> I have searched unsuccessfully for an answer to this one, and figure it's
> some sort of configuration error that I missed.  The commands I am using
> are:
>
> $ cd ~/sdr/e310/rfnoc/oe/
> $ source ./environment-setup-cortexa9t2hf-neon-oe-linux-musleabi
> $ cd ~/sdr/e310/rfnoc/src/gnuradio
> $ mkdir build-arm
> $ cd build-arm/
> $ cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=~/sdr/e310/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF 

Re: [USRP-users] rfnoc build standard image x310 failing

[Jonathon Pendlum via USRP-users]

Hi Jeff,

For UHD 3.15, I believe that issue has been fixed. Check out the
UHD-3.15.LTS branch and let me know if you still have an issue building.

For UHD 3.14, check out the UHD-3.14 branch.

Using the branches above, I was able to successfully build an image using
your uhd_image_builder command (without the -g option) for both UHD 3.15
and UHD 3.14.

Jonathon


On Wed, May 20, 2020 at 8:35 PM Hodges, Jeff via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Can someone please tell me what version of uhd and rfnoc are compatible
> for building an image on Ubuntu 18.04?
>
>
>
> I cannot get any of the UHD releases to properly build a standard rfnoc
> image.
>
>
>
> sudo ./uhd_image_builder.py fft ddc duc -g -t X310_RFNOC_HG -c -d X310
> --fill-with-fifos
>
>
>
> I installed vivado 2018.3 with uhd 3.15.0.0 and get the error:
>
>
>
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4
> has multiple drivers: radio_clk_gen/inst/clkout1_buf/O, and
> bus_clk_gen/inst/clkout4_buf/O.
>
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
> radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has
> multiple drivers:
> radio_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q,
> and
> ce_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q.
>
>
>
>
>
> I installed vivado 2017.4 with uhd 3.14.1.1 and get this error:
>
>
>
> BUILDER: Releasing IP location:
> /home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/aurora_64b66b_pcs_pma
>
> Using parser configuration from:
> /home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/dev_config.json
>
> [00:00:00] Executing command: vivado -mode batch -source
> /home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build_x300.tcl -log
> build.log -journal x300.jou
>
> CRITICAL WARNING: [filemgmt 20-1440] File
> '/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_0_tempmon.v'
> already exists in the project as a part of sub-design file
> '/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci'.
> Explicitly adding the file outside the scope of the sub-design can lead to
> unintended behaviors and is not recommended.
>
> [00:00:29] Current task: Initialization +++ Current Phase: Starting
>
> [00:00:29] Current task: Initialization +++ Current Phase: Finished
>
> [00:00:29] Executing Tcl: synth_design -top x300 -part xc7k410tffg900-2
> -verilog_define BUILD_1G=1 -verilog_define BUILD_10G=1 -verilog_define
> SFP0_1GBE=1 -verilog_define SFP1_10GBE=1 -verilog_define RFNOC=1
> -verilog_define X310=1 -verilog_define GIT_HASH=32'hfbb85bdf
>
> [00:00:29] Starting Synthesis Command
>
> ERROR: [Synth 8-439] module 'ddr3_32bit' not found
> [/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/x300.v:1191]
>
> ERROR: [Synth 8-285] failed synthesizing module 'x300'
> [/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/x300.v:20]
>
> ERROR: [Common 17-69] Command failed: Synthesis failed - please see the
> console or run log file for details
>
> [00:08:36] Current task: Synthesis +++ Current Phase: Starting
>
> [00:08:36] Current task: Synthesis +++ Current Phase: Finished
>
> [00:08:36] Process terminated. Status: Failure
>
>
>
>
>
> Any advice is greatly appreciated.
>
>
>
> Thanks,
>
>
>
> Jeff
>
>
>
>
>
>
> ___
> 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] disabling ddc duc blocks in rfnoc usrp e310

[Jonathon Pendlum via USRP-users]

Hi Ivan,

When you build a custom RFNoC image for the E310 using uhd_image_builder,
only the radio core RFNoC block is included automatically. If you did not
specifically include a DDC or DUC block, then they were not included in the
build. The E310 is based on the Zynq 7020 and has limited resources. The
Fosphor example by itself uses up almost all of the device's FPGA resources
and adding another RFNoC block without modifying the design is not possible.

One experiment you could try is modifying line 11 in noc_block_fosphor.v to
increase the MTU size from 11 to 13 or 14. That may allow you to no longer
need the AXI FIFO RFNoC blocks. Without those blocks, you might be able to
fit in the FIR filter RFNoC block.

Jonathon

On Sun, May 10, 2020 at 7:10 AM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello. I want to create an image of fosphor, window, fft, 2x AXI FIFOs,
> FIR for USRP E310. I need to change the spectral bandwidth. But with the
> samp_rate parameter this does not work out very well. Therefore, I want to
> use the FIR filter for these purposes, but when building the bit file, I do
> not have enough space on the FPGA. Therefore, I decided to turn off the DDC
> and DUC blocks, but I don’t know how to do it. I would be grateful for any
> information.
> ___
> 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] Fractional downsampling in rfnoc

[Jonathon Pendlum via USRP-users]

Hi Snehasish,

That's surprising, I didn't think it was possible to do that. How did you
re-create the EDIF file?

The noc_shell and axi_wrapper modules have both changed internally quite a
bit, but their interfaces have only minor changes. The noc_shell interface
change is simply adding the set_time, set_hase_time output signals. Those
outputs can be left unconnected. The axi_wrapper interface now has a
bus_clk and bus_rst input. To complicate things, the code uses a modified
axi_wrapper called axi_wrapper_mod. You could compare the latest
axi_wrapper with axi_wrapper_mod and merge in the differences.

Jonathon

On Tue, Apr 28, 2020 at 5:37 PM Snehasish Kar 
wrote:

> Snehasish Kar has shared a OneDrive file with you. To view it, click the
> link below.
> 
> fract_dec_filter.edf 
> 
>
> Hello
>
> > 25msps and tried dividing it into 16 channels. I should have returned
> 625kspsx2 sample rate each channel
>
> >Based on your screen shot I'm guessing you started with 10 Msps and used
> 16 channels to get 625 kHz channel spacing (with 1250 ksps per channel). Is
> that correct?
>
> Yes.
> > But you can see the snaphshots, if a tune into 955.4MHz and try to get a
> channel on index 0 ie the center freq, it works well and I am able to
> decode GSM Burst from it. But if I try to add index 2(which is 955.8MHz),
> the amplitude in the spectrum falls and also I am not able to decode any
> GSM burst
>
> >Is it correct that your "index 2" center frequency is targetting 400 kHz
> offset from the center frequency? If so, I dont expect this would work.
> Using a channel spacing of 625 kHz, the >closest channel you could receive
> next to 955.4 MHz would be 956.025 MHz. Based on your screenshot it
> actually seems like the peak energy you're looking for may be lower than
> the >channel frequency by about 200 kHz?
>
> No. The reason we found for the low energy was that the center of the
> channel was getting shifted by 100KHz, which we corrected using the
> frequency Xlating fir filter in gnuradio and also by changing the input
> sample rate.
>
> @EJ Kreinar : thanks for the support.
>
> @Jonathon Pendlum : I was able to re-create
> the EDIF file for the fractional downsampler in
> https://github.com/SynchronousLabs/rfnoc-SynchronousLabs and was able to
> build it. Though I believe I need to update the rfnoc API for the same. I
> have the attached EDIF file for your reference. Please guide me if only
> modifying the noc file work or we any other changes are to be made as per
> the new rfnoc version.
>
> Regards
> Snehasish
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel instances

[Jonathon Pendlum via USRP-users]

Hi Snehasish,

The DDC supports a wide range of sampling rates. Depending on the rates you
want, some of the DDC filters could be removed to reduce utilization or
there may be a better architecture to fit your situation. What rates do you
need to support?

Jonathon

On Thu, Apr 23, 2020 at 3:19 AM Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Brian
>
> While writing the bitstream it gave an error stung the current design
> didn’t satisfy the timing constraint.
>
> I tried creating 12 blocks of DDC 1 to 2, blocks but that failed too
> saying the placer couldnot place more than 5% of the movable instances in
> the design.
>
> Regards
> Snehasish
>
> Get Outlook for iOS 
> --
> *From:* Brian Padalino 
> *Sent:* Thursday, April 23, 2020 4:19:14 AM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel
> instances
>
> On Wed, Apr 22, 2020 at 6:17 PM Snehasish Kar 
> wrote:
>
> Hello Brian
>
> Thanks for your response, actually I tried using DDC 1 to n block as given
> here, but giving 1 to 8 channels have a timing issue, while generating the
> build. So I thought it as an alternative plan.
>
>
> https://gitlab.com/theseus-cores/theseus-cores/-/blob/master/fpga-rfnoc/README.md#dsp-utilsnoc_block_ddc_1_to_n
>
>
> What was the timing issue?  Is it possible for you to break up the logic
> to help relax timing constraints?
>
> Brian
>
> ___
> 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] Cygwin build of E310_SG3

[Jonathon Pendlum via USRP-users]

Hi Dan,

Checkout UHD-3.15.LTS, which is the long term support tag for 3.15 and uses
Vivado 2018.3. Also run "make cleanall" in the usrp3/top/e31x directory to
remove any IP that may have been built with the wrong version (i.e. 2019.1).

Jonathon

On Tue, Apr 21, 2020 at 7:32 AM Harris, Dan via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I followed the instructions here which suggest 2019.1:
> https://files.ettus.com/manual/md_usrp3_build_instructions.html.  I had
> actually tried 2019.2 at first and reverted to 2019.1 since all the IP was
> locked.  I could try 2018.3 but I don’t really understand the rules around
> the locking stuff, and whether that would work.
>
>
>
> In the master pull of (https://github.com/EttusResearch/uhd.git)
> fpga/usrp3/top/e31x/setupenv.sh seems to be looking for 2019.1.  Perhaps I
> made a poor choice in using master?  Is there a stable branch or something
> I should have chosen instead?
>
>
>
> I will give WSL a try – I haven’t used it yet but it sounds like it may be
> less painful than Cygwin.
>
>
>
> *From:* Brian Padalino 
> *Sent:* Monday, April 20, 2020 6:12 PM
> *To:* Harris, Dan (US) 
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* [EXTERNAL] Re: [USRP-users] Cygwin build of E310_SG3
>
>
>
> On Mon, Apr 20, 2020 at 2:24 PM Harris, Dan via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
>
> Is the windows Cygwin build of the E310_SG3 target being maintained?
>
>
>
> I have been following the build instructions and have Vivado 2019.1
> installed.  It is failing in multiple points in the generation of the IP.
> I had to correct some paths that should have been windows-ized but did not
> seem to be in tools/make/viv_hls_ip_builder.mak.
>
>
>
> I can build at least one of the components (IP fifo_short_2clk), so I am
> somewhat confident that Vivado is installed correctly, and that my ‘source
> setupenv.sh’ was done properly.
>
>
>
> This seems strange.  You need to have Vivado 2018.3 installed for the
> setupenv.sh to run properly.  Try installing 2018.3 and ditching 2019.1
> first.
>
>
>
> Also, just as a point of reference, I've successfully used WSL (linux on
> windows) to install Vivado and build successfully.  Running in cygwin
> sounds like a real pain, and I fully recommend linux (native or wsl) for
> building.
>
>
>
> Brian
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient and may contain material that is proprietary,
> confidential, privileged or otherwise legally protected or restricted under
> applicable government laws. Any review, disclosure, distributing or other
> use without expressed permission of the sender is strictly prohibited. If
> you are not the intended recipient, please contact the sender and delete
> all copies without reading, printing, or saving.
>
> ___
> 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] Fractional downsampling in rfnoc

[Jonathon Pendlum via USRP-users]

Hi Snehasish,

I forgot about that error. I actually made an issue about it on their repo:
https://github.com/SynchronousLabs/rfnoc-SynchronousLabs/issues/2. Unless
they provide an EDIF or their source code, you can only use their code for
simulation. Certainly a disappointing oversight on their part.

Jonathon

On Sat, Apr 18, 2020 at 6:21 PM Snehasish Kar 
wrote:

> Hello Jonathon
>
> Tried building the fractional downsampler from synchronous labs and have
> encountered the following error:
> source file was generated for simulation and is not permitted as input to
> synthesis
> [/home/snehasish/rfnoc-SynchronousLabs/rfnoc/fpga-src/fract_dec_filter.vhd:241995]
>
> Can you please help me with it.
>
> Regards
> Snehasish
> --
> *From:* Jonathon Pendlum 
> *Sent:* Friday, April 17, 2020 9:22 PM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hello Snehasish,
>
> Unfortunately, the standard library of blocks does not have a Fractional
> Decimator. Your best bet is to try to use the one made by Synchronous Labs
> a few years ago. Their code is on github here:
> https://github.com/SynchronousLabs/rfnoc-SynchronousLabs. Since it was
> built, RFNoC has had some changes that will need to be fixed, but I think
> this is your only option versus writing one from scratch.
>
> Jonathon
>
> On Thu, Apr 16, 2020 at 6:35 PM Snehasish Kar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello
>
> I am trying to use the RFNOC based M/2 channelizer from
> https://github.com/theseus-cores/theseus-cores/releases/tag/v1.1.0 . I am
> trying to divide 25 MHz spectrum into 124 subchannels each of bandwidth
> 200KHz. I am capturing the signal at 200msps and I need to decimate it to
> 25.6msps(25MHz/128 channels). Please help me in understanding how this can
> be achieved using RFNoC, is there’s any block already defined for
> fractional downsampling.
>
> Thanks & Regards
> Snehasish
>
> Get Outlook for iOS 
> ___
> 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] Fractional downsampling in rfnoc

[Jonathon Pendlum via USRP-users]

Hello Snehasish,

Unfortunately, the standard library of blocks does not have a Fractional
Decimator. Your best bet is to try to use the one made by Synchronous Labs
a few years ago. Their code is on github here:
https://github.com/SynchronousLabs/rfnoc-SynchronousLabs. Since it was
built, RFNoC has had some changes that will need to be fixed, but I think
this is your only option versus writing one from scratch.

Jonathon

On Thu, Apr 16, 2020 at 6:35 PM Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
> I am trying to use the RFNOC based M/2 channelizer from
> https://github.com/theseus-cores/theseus-cores/releases/tag/v1.1.0 . I am
> trying to divide 25 MHz spectrum into 124 subchannels each of bandwidth
> 200KHz. I am capturing the signal at 200msps and I need to decimate it to
> 25.6msps(25MHz/128 channels). Please help me in understanding how this can
> be achieved using RFNoC, is there’s any block already defined for
> fractional downsampling.
>
> Thanks & Regards
> Snehasish
>
> Get Outlook for iOS 
> ___
> 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] Polling the "sample_rx" via a user defined register (B205mini)

[Jonathon Pendlum via USRP-users]

Hi Varban,

I am now getting random 32-bit values when polling it from the UHD (instead
> of a constant that indicates a "zero" reception)


Even with the antenna disconnected you can expect some LSBs to toggle due
to inherent receiver noise.

1) How should I interpret the 32-variable?
>

It is a short complex int where the upper 16-bits are I and the lower
16-bits are Q.


> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>

Yes


> 2) Do I need new_rx_control?


No

Have I done this correctly in general, or there is something completely
> wrong in my approach?


What do you want to accomplish?

Jonathon

On Mon, Feb 17, 2020 at 5:03 AM Varban Metodiev via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> After exposing the *sample_rx* from radio_legacy.v
> 
>  to
> a user defined register and sampling it at rising edge of the *strobe_rx*,
> I am now getting random 32-bit values when polling it from the UHD (instead
> of a constant that indicates a "zero" reception). I am doing this with
> disconnected antenna using a modified rx_samples C++ example application.
>
> I have the following questions:
> 1) How should I interpret the 32-variable?
> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
> 2) Do I need new_rx_control?
>
> Have I done this correctly in general, or there is something completely
> wrong in my approach?
>
> Thanks,
> Varban
> ___
> 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] [Non-DoD Source] Re: RFNOC: 2 input/2 output block, synchronizing their outputs to GNURadio host

[Jonathon Pendlum via USRP-users]

Hello Andrew,

1.   I understand from Analog documentation that the AD9361 outputs
> 12-bit samples in two’s complement, is that right? Also I gather from
> tracing through the HDL, within e31x_core, the data is packed MSB-aligned,
> with LSBs 3…0 locked at 1’b0.  When you feed a 16-bit I, 16-bit Q sample
> into the complex_to_magphase IP block it outputs a 16-bit real, 16-bit
> phase result. So is the magnitude (16-bit real output) formatted the same
> way, i.e. {D11…D0, 4’d0}?  Does it not matter to that IP block whether it
> is MSB padded or LSB padded?  Is it also in 2’s complement?
>

Most blocks maintain the sc16 format (16-bit I and 16-bit Q 2s complement)
throughout the entire processing pipeline. The complex_to_magphase IP block
uses Xilinx's CORDIC IP and their documentation can explain how it works
internally. The CORDIC does not zero out output LSBs even if the input is a
left shifted 12-bit number. In fact, those bits will likely wiggle due to
the slight gain in the CORDIC block. Whether you choose to MSB or LSB pad
is a fixed point design decision as in where do you want to point your
decimal point at. Most blocks do not particularly care, although using full
scale signals with some blocks, such as the DUC, may degrade due to
clipping and you should shoot for using 90% of amplitude.

I would suggest testing the complex_to_magphase block by itself in a test
bench and make sure the output is monotonically increasing as you expect.


> 2.   Dynamic range of e310, if the samples are 12-bit then does this
> come out to 20*log10(4095) = 72.2 dB?  So I should be experiencing some
> abnormalities at the extremes?
>

I have not done any dynamic range testing on the E310 and there are not any
published numbers for the E310. The E310 is based on the AD0361, so you can
try looking at that part's datasheet.


> 3.   Since I have the analog bw set to 10 MHz, and I am feeding the
> SDR a CW signal which is very narrow in the spectrum, is it possible to
> actually max out the ADC with this bench setup?
>

This isn't something that I have tested, but I would expect you could. You
will have to be careful though, as too strong of an input signal will
damage the AD9361.


> 4.   Most import question, I’m using noc_block_fft as a guide for
> producing magnitude samples.  In that file mag_tdata[31:0] is assigned
> {1’b0, mag_tdata_int[15:0], 15’d0}, then that mag_tdata is fed to
> axi_round_and_clip wherein the first MSB is clipped, and truncated such
> that 16 bit data is outputted.  My question is: Does that not just clip the
> leading 0 off and round the LSB?  Then wouldn’t the host computer interpret
> this over the wire real uint16 as a two’s complement float or int, going
> negative as the MSB goes high?  How can I treat that result as an unsigned
> 16-bit int?


The easiest way is to set the over-the-wire (OTW) and CPU format to sc16 so
no conversion occurs and treat the value as uint16.

Jonathon

On Wed, Feb 19, 2020 at 3:39 PM Payne, William Andrew (Andrew) CIV USN NSWC
CD CRANE ID (USA)  wrote:

> Hello Jonathan,
>
>
>
> Fortunately, a lot of progress has been made since you mentioned some
> ideas for me, I was just hesitating to reply until I got stuck again.  I
> have been running on an e310 a 2-stream custom noc_block with axi wrappers
> set to simple mode successfully for the past few days, proving it is very
> much possible and not a difficult task.  I think the root cause of my
> problem was either:
>
> 1.   Not running make clean before make install in my rfnocmodtool
> directory
>
> 2.   Not inputting my settings registers correctly in the UHD
> nocsript.
>
> 3.   Not correctly setting up my GRC block xml file.
>
> 4.   Correcting a bug in my custom Verilog code in my noc_block.
>
>
>
> But now there is a slight issue that I hope you can help me out with.  My
> test bench is composed of the e310 receiving RF from a sig gen tuned to a
> center freq and sweeping the amplitude from noise floor to less than max
> input, running through my custom string of IP blocks that comprise my rfnoc
> block (complex to magnitude -> moving sum -> keep one in n).   Data streams
> through just fine, no timeouts, but sometimes I get odd results such as the
> magnitude going down a little when I expected it to keep rising with the
> sig gen input.
>
>
>
> I wanted to dig a little deeper into the sampling details from the rx
> front end.  Here’s my list of questions for you:
>
> 1.   I understand from Analog documentation that the AD9361 outputs
> 12-bit samples in two’s complement, is that right? Also I gather from
> tracing through the HDL, within e31x_core, the data is packed MSB-aligned,
> with LSBs 3…0 locked at 1’b0.  When you feed a 16-bit I, 16-bit Q sample
> into the complex_to_magphase IP block it outputs a 16-bit real, 16-bit
> phase result. So is the magnitude (16-bit real output) formatted the same
> way, i.e. {D11…D0, 4’d0}?  Does it not matter to that IP block 

Re: [USRP-users] Vivado IP locked issue

[Jonathon Pendlum via USRP-users]

Try removing all xml files you have in your OOT IP directory.

On Thu, Feb 20, 2020 at 10:22 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Unfortunately, I already tried that but no luck.
>
> On Thu, Feb 20, 2020 at 9:54 PM Nick Foster  wrote:
>
>>
>> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/
>>
>> Wipe that whole directory and try it again. If you want to be selective
>> and save some time you can wipe only the axi_mem_64k directory.
>>
>> On Thu, Feb 20, 2020 at 6:13 PM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>> I am having a problem with a Block Memory Generator IP that is working
>>> with 2017.4 but is giving me issues with 2018.3. I have tried to upgrade
>>> the IP as well as re-creating the IP from scratch in 2018.3, but I still
>>> get the same failure (see below).  I have attached the IP created from
>>> scratch in 2018.3.  Any suggestions?  I am not very experienced with FPGA
>>> development in general or Vivado specifically, so it is likely that I am
>>> missing something obvious.
>>>
>>> By the way, I am using the webpack (free) version of Vivado and
>>> attempting to build for the E310.
>>>
>>> Rob
>>>
>>>
>>> kossler@kossler-ThinkPad-P51:~/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb$
>>> make xsim
>>> BUILDER: Checking tools...
>>> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
>>> * Python 2.7.17
>>> * Vivado v2018.3 (64-bit)
>>> 
>>> BUILDER: Building IP axi_mem_64k
>>> 
>>> BUILDER: Staging IP in build directory...
>>> BUILDER: Reserving IP location:
>>> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k
>>> BUILDER: Retargeting IP to part kintex7/xc7z020/clg484/-3...
>>> BUILDER: Building IP...
>>> [00:00:00] Executing command: vivado -mode batch -source
>>> /home/kossler/uhd/UHD-3.15/uhd/fpga-src/usrp3/tools/scripts/viv_generate_ip.tcl
>>> -log axi_mem_64k.log -nojournal
>>> WARNING: [IP_Flow 19-2162] IP 'axi_mem_64k' is locked:
>>> CRITICAL WARNING: [filemgmt 20-1366] Unable to reset target(s) for the
>>> following file is locked:
>>> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k/axi_mem_64k.xci
>>> CRITICAL WARNING: [filemgmt 20-1365] Unable to generate target(s) for
>>> the following file is locked:
>>> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k/axi_mem_64k.xci
>>>
>> ___
>>> 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] RFNOC: 2 input/2 output block, synchronizing their outputs to GNURadio host

[Jonathon Pendlum via USRP-users]

Hi Andrew,

Are you able to run any of the in-tree RFNoC blocks on your E310 without
this error? Does your block work if you make it 1 input / 1 output? Also,
do you have access to an X310? If so, can you try running your block on
there and see if it works?

Jonathon

On Thu, Feb 13, 2020 at 7:10 AM Payne, William Andrew (Andrew) CIV USN NSWC
CD CRANE ID (USA) via USRP-users  wrote:

> Hi,
>
> I am trying to solve what I think is a timing issue with my RFNOC design.
> I have an E310 running UHD 3.15LTS/GNUradio 3.7/gr-ettus.
>
> I have created a custom RFNOC block for GNUradio without much custom
> logic, I've managed to just reuse code blocks from the uhd-fpga repo in
> lib/rfnoc.  In particular, I am using the following blocks in this order:
> complex to magphase (ISE IP in lib/rfnoc) -> moving_sum -> keep_one_in_n ->
> fifo with size 5 (so I don't have to have RFNOC:FIFO blocks taking up room
> in the FPGA).  For moving_sum I'm trying to use 511 as the sum length and
> for keep_one_in_n I am using 512.  I have made this block a permanent 2
> input/2 output block by setting those parameters in noc_shell
> instantiation.  I am using the axi_wrappers (0 and 1) with SIMPLE MODE set
> to 0, and simply utilizing the cvita_hdr_modify.v IP exactly as utilized in
> the noc_block_keep_one_in_n.v block to set the tuser headers.
>
> In Vivado behavioral simulation the data correctly flows through but what
> I am unsure about is the fact that after synthesizing and loading the FPGA
> bit file into the e310 and running my flowgraph, it just repeatedly prints
> out timeout on channel 0.   By the way this code does work on just a single
> input/single output application but I want to consolidate it into a single
> GRC block to save space on the relatively small FPGA.  What do I need to do
> to sync the 2 e310 rx2 channels so they arrive close to on-time in GRC?  Or
> is that probably not the problem?  I assume I should be looking at how it's
> done in noc_block_ddc/duc as they have implemented timed samples within
> those?
>
> Thanks,
> Andrew
>
> ___
> 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] E312 RFNOC timed command for setup gain

[Jonathon Pendlum via USRP-users]

Hi James,

The Siggen RFNoC block does not support timed commands.

Jonathon

On Wed, Jan 22, 2020 at 3:32 PM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> Is there a way to use timed command for E312 rfnoc siggen module for setup
> gain?
> I am trying something like below. Is this the right way? Thank you.
>
> uhd::time_spec_t cmd_time = time_ref +
> uhd::time_spec_t(i*256/28e6*10*2000*10);
> ctrl_siggen_ch0->set_command_time(cmd_time);
> ctrl_siggen_ch0->set_arg("gain", 3086) ;
>
> James
>
> ___
> 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] clarifications on x300_core.v

[Jonathon Pendlum via USRP-users]

Hi Dario,

I suspect this might be a bug. The ce_clk signal is an input in
x300_core.v, but it is also assigned to radio_clk. On the other hand, other
devices do not have a ce_clk input for their *_core.v implementations. Do
you run into any synth errors when building a X300 rfnoc image?

Jonathon

On Thu, Oct 31, 2019 at 11:49 PM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> looking at the generated code from the uhd_image_builder.py it declares
> ce_clk and ce_rst and assigns them to radio_clk and radio_rst. Actually
> this file is included within x300_core.v which already has the same signals
> as input ports and which are externally connected in x300.v to a different
> clock (at 214MHz).
>
> do I understand correctly that the assignments are ignored and that the
> signals stay at 214MHz rather than the 200 MHz of the radio_clk?
>
> Is there any reason why the builder script adds those
> declarations/assignments?
>
> Thanks,
>
>
>
> Dario Pennisi
>
>
> ___
> 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] Unable to Load X310 Registers

[Jonathon Pendlum via USRP-users]

Hi,

I don't see anything inherently wrong with your code. Using the waveform
viewer, do you see the settings bus writes occur? You'll need to watch for
the condition where set_stb asserts and set_addr is equal to one of your
user register addresses.

Jonathon

On Tue, Oct 22, 2019 at 8:25 PM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am running a testbench on my architecture, and all default tests pass as
> expected. This includes TEST 4 which tests writing and reading back from
> registers. The problem is - the following tests prove the registers hold
> their initial (default) value and not the value I tried writing to them in
> TEST 4.
>
> Did I miss something in the process?
> what possible reasons may cause this problem?
>
> Scripts of both Testbench code and NoC_block code given below.
>
> Thanks in advance,
> Ishai
>
> *Testbench Code:*
>
> */**
>
> ** Test 4 -- Write / readback user
> registers***
>
>
> ***/`TEST_CASE_START("Write user registers");
>   random_word = 0;tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_MIN_*
>
> *BW, random_word[21:0]);random_word = 5;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_MAX_*
>
> *BW, random_word[21:0]);random_word = 10;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_BW_*
>
> *CHANGE_RATE, random_word[21:0]);random_word = 256;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_PKT_*
> *SIZE, random_word[15:0]);`TEST_CASE_DONE(1);*
>
> *noc_block verilog code:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *localparam SR_USER_REG_BASE = 129;localparam [7:0] SR_MIN_BW = 129;
> //SR_USER_REG_BASE;  localparam [7:0] SR_MAX_BW = 130;//TeSR_USER_REG_BASE
> + 8'd1;  localparam [7:0] SR_BW_CHANGE_RATE = 131;//SR_USER_REG_BASE +
> 8'd2;  localparam [7:0] SR_PKT_SIZE   = 132; //SR_USER_REG_BASE +
> 8'd3;  wire [15:0] payload_length;  wire [21:0] min_BW;  wire [21:0]
> max_BW;  wire [21:0] BW_change_rate; cvita_hdr_encoder
> cvita_hdr_encoder (.pkt_type(2'd0), .eob(1'b0), .has_time(1'b0),
> .seqnum(12'd0), .payload_length(payload_*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *length), .dst_sid(next_dst_sid), .src_sid(src_sid),
> .vita_time(64'd0),.header(s_axis_data_tuser));  // Set packet size
> setting_reg #(.my_addr(SR_PKT_SIZE), .awidth(8), .width(16),
> .at_reset(4)) // Set a safe default packet size in case packet size is
> never set  set_payload_length (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data),.out(payload_length),
> .changed());   setting_reg #(.my_addr(SR_MIN_BW), .awidth(8),
> .width(22))  sr_min_bw (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(min_BW),
> .changed());   setting_reg #(.my_addr(SR_MAX_BW), .awidth(8),
> .width(22))  sr_max_bw (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(max_BW),
> .changed());   setting_reg #(.my_addr(SR_BW_CHANGE_RATE), .awidth(8),
> .width(22))  sr_bw_change_rate (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(BW_change_rate),
> .changed()); *
>
>
> --
> ישי אלוש
> 054-5823400
> ___
> 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] Fwd: Failing to Instantiate Blocks ("No Binding Entity")

[Jonathon Pendlum via USRP-users]

Hi,

Did you include your generic_counter VHDL source file in Makefile.inc in
the fpga-src directory?

Jonathon

On Mon, Oct 7, 2019 at 3:46 PM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> In my architecture I instantiated an FM_block.vhd, and in the FM_block I
> instantiated a generic_counter.vhd block.
>
> The problem:
>
> when I run the simulation I see that the FM_block is fine, but the
> generic_counter is unreferenced, and i get the following warning:
>
>
>
> *Starting static elaborationWARNING: [VRFC 10-122] generic_counter remains
> a black-box since it has no binding entity
> [/home/user/rfnoc_01/rfnoc-modules/rfnoc/fpga-src/FM_block.vhd:38]WARNING:
> [VRFC 10-122] generic_counter remains a black-box since it has no binding
> entity [/home/user/rfnoc_01/rfnoc-modules/rfnoc/fpga-src/FM_block.vhd:50]*
>
> I have also opened the project in Vivado and noticed the same thing: The
> file is unreferenced.
>
> Furthermore, I add the path of the two files (FM_block and
> generic_counter) to all of the Make files I could find, but to no avail.
>
> Please help!
>
> Thank in advance,
> Ish
>
> P.S. Further information:
>
> The syntax used to instantiate the FM_block is as follows (verilog):
>
>
>
> *  FM_block #(.COUNTER_WIDTH(22))  FM_block_i (.clk(ce_clk),
>  .rst(ce_rst), .en (s_axis_data_tready), .min_BW(min_BW),
>   .max_BW(max_BW), .BW_change_rate(BW_change_rate), .FM_out(data_out));*
>
> And the syntax used to instantiate the generic_counter is as follows
> (vhdl):
>
>
>
>
>
>
>
>
>
>
>
> *counter_change_rate : generic_counter  generic map(COUNTER_WIDTH =>
> COUNTER_WIDTH)  port map( clk=> clk,  rst  => rst,
> en  => en,  min_val  => (others => '0'),
>   max_val  => BW_change_rate,  new_output=>
> change_freq_en,  count_out  => open);*
>
>
>
> ___
> 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] UHD / RFNoC Versions and Flowgraph Error with X310

[Jonathon Pendlum via USRP-users]

Hi Jeff,

Try commit 4980cbef0daf from gr-ettus and please let me know if that solves
the problem.

Jonathon

On Wed, Oct 9, 2019 at 10:23 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have been trying to set up an environment for using RFNoC on an X310.
> It was running well before I tried to update the to using RFNoC according
> the the application note.  I'm wondering if I have an error relating to a
> version of UHD correlating to the other parts (gr-ettus, gnuradio, fpga).
> I feel like I cannot trust documentation I see (like the X310 product
> description calling out Vivado 2015, but a recent email calling out 2017,
> and an earlier question that caused an application note to be deprecated).
>
> I have two laptops which show the uhd (git branch) at version rfnoc-devel,
> and gr-ettus at master.  One will run a flowgraph with RFNoC blocks, and
> the other will get the error below with the same flowgraph (error on last
> line).  I'm just trying to figure out what direction to go before I delete
> everything and start over.  Similar questions about similar errors seemed
> to related to UHD versions, which I why I'm starting there.
>
> Thanks,
> Jeff
>
> [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.4.0; Boost_106501;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [32;1m[INFO] [X300] [39;0mX300 initialization sequence...
> [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
> [32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz
> [32;1m[INFO] [GPS] [39;0mFound an internal GPSDO: LC_XO, Firmware Rev
> 0.929a
> [32;1m[INFO] [0/DmaFIFO_0] [39;0mInitializing block control (NOC ID:
> 0xF1F0D000)
> [32;1m[INFO] [0/DmaFIFO_0] [39;0mBIST passed (Throughput: 1305 MB/s)
> [32;1m[INFO] [0/DmaFIFO_0] [39;0mBIST passed (Throughput: 1307 MB/s)
> [32;1m[INFO] [0/Radio_0] [39;0mInitializing block control (NOC ID:
> 0x12AD1001)
> [32;1m[INFO] [0/Radio_1] [39;0mInitializing block control (NOC ID:
> 0x12AD1001)
> [32;1m[INFO] [0/DDC_0] [39;0mInitializing block control (NOC ID:
> 0xDDC0)
> [32;1m[INFO] [0/DDC_1] [39;0mInitializing block control (NOC ID:
> 0xDDC0)
> [32;1m[INFO] [0/DUC_0] [39;0mInitializing block control (NOC ID:
> 0xD0C0)
> [32;1m[INFO] [0/DUC_1] [39;0mInitializing block control (NOC ID:
> 0xD0C0)
> Finding block for: Radio_0
> Mapped external port 0 to 0
> Mapped port 0 to 0/Radio_0
> Mapped external port 1 to 1
> Mapped port 1 to 0/Radio_0
> TX args:
> RX args:
> 0/Radio_0 has 1 input ports
> 0/Radio_0 has 2 output ports
> getting block control for port 0
> Finding block for: Radio_0
> Mapped external port 0 to 0
> Mapped port 0 to 0/Radio_0
> Mapped external port 1 to 1
> Mapped port 1 to 0/Radio_0
> TX args:
> RX args:
> 0/Radio_0 has 1 input ports
> 0/Radio_0 has 2 output ports
> getting block control for port 0
> Finding block for: DUC
> Mapped external port 0 to 0
> Mapped port 0 to 0/DUC_0
> TX args:
> RX args:
> 0/DUC_0 has 1 input ports
> 0/DUC_0 has 1 output ports
> Finding block for: DmaFIFO
> Mapped external port 0 to 0
> Mapped port 0 to 0/DmaFIFO_0
> Mapped external port 1 to 1
> Mapped port 1 to 0/DmaFIFO_0
> TX args:
> RX args:
> 0/DmaFIFO_0 has 2 input ports
> 0/DmaFIFO_0 has 2 output ports
> getting block control for port 0
> External mapped to port 0
> getting block control for port 0
> External mapped to port 0
> getting block control for port 1
> External mapped to port 1
> getting block control for port 1
> External mapped to port 1
> Finding block for: DDC
> Mapped external port 0 to 0
> Mapped port 0 to 0/DDC_0
> Mapped external port 1 to 1
> Mapped port 1 to 0/DDC_0
> TX args:
> getting block control for port 0
> getting block control for port 0
> block_port0 = 0
> block_id0 = 0/DDC_0
> RX args:
> External mapped to port 0
> getting block control for port 0
> getting block control for port 0
> block_port0 = 0
> block_id0 = 0/DDC_0
> 0/DDC_0 has 2 input ports
> 0/DDC_0 has 2 output ports
> getting block control for port 0
> External mapped to port 0
> getting block control for port 0
> External mapped to port 0
> getting block control for port 0
> External mapped to port 0
> getting block control for port 0
> External mapped to port 0
> gr::fft: can't import wisdom from /home/torchuser/.gr_fftw_wisdom
> getting block control for port 0
> getting block control for port 0
> Connecting 0/DmaFIFO_0 port 0 to 0/DUC_0 port 0
> [33;1m[WARNING] [RFNOC] [39;0mAssuming max packet size for 0/DmaFIFO_0
> getting block control for port 0
> getting block control for port 0
> Connecting 0/DUC_0 port 0 to 0/Radio_0 port 0
> [33;1m[WARNING] [RFNOC] [39;0mAssuming max packet size for 0/DUC_0
> getting block control for port 0
> getting block control for port 0
> Connecting 0/Radio_0 port 0 to 0/DDC_0 port 0
> [33;1m[WARNING] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
> getting block control for port 0
> getting block control for port 0
> getting block control for port 0
> 

Re: [USRP-users] No block_id specified for channel 0

[Jonathon Pendlum via USRP-users]

Hi Jason,

Could you try reverting gr-ettus back one commit to 4980cbef and let me
know if that works?

Jonathon

On Tue, Sep 10, 2019 at 5:23 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have an RFNoC  flowgraph and bitfile combo that used to work but is
> erroring out now. I've been using the code successfully on the E320 and
> E310 and decided to re-build for the X310 (and XG flowgraph).  When I run
> my flowgraph, I am see a lot of addition debug that I am not used to seeing
> (which is fine) and then my block in particular seems to cause problems and
> I get the error in the subject.  I am guessing that since I just rebuilt
> everything, some change needs to be made in my impl for my block due to
> some UHD update, but I can't quite figure out anywhere where something
> changes.  The beginning of the output when I run my flowgraph is:
>
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
> Boost_105300; UHD_3.14.1.1-0-g98c7c986
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1323 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
> [INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC1)
> [INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC1)
> [INFO] [0/keepMinN_0] Initializing block control (NOC ID:
> 0x229C30C919275220)
> [INFO] [0/keepMinN_1] Initializing block control (NOC ID:
> 0x229C30C919275220)
> [WARNING] [RFNOC] Can't find a block controller for key SplitStream, using
> default block controller!
> [INFO] [0/SplitStream_0] Initializing block control (NOC ID:
> 0x5757)
> [WARNING] [RFNOC] Can't find a block controller for key SplitStream, using
> default block controller!
> [INFO] [0/SplitStream_1] Initializing block control (NOC ID:
> 0x5757)
> Finding block for: Radio_1
> Mapped external port 0 to 0
> Mapped port 0 to 0/Radio_1
> Mapped external port 1 to 1
> Mapped port 1 to 0/Radio_1
> TX args:
> RX args:
> 0/Radio_1 has 1 input ports
> 0/Radio_1 has 2 output ports
> getting block control for port 0
> Finding block for: DDC_0
> Mapped external port 0 to 0
> Mapped port 0 to 0/DDC_0
> TX args:
> getting block control for port 0
> getting block control for port 0
>
>
> And the ehnd of that blob shows:
>
> getting block control for port 0
> getting block control for port 0
> thread[thread-per-block[2]: ]: RuntimeError: Cannot
> create streamers: No block_id specified for channel 0.
>
>
> And finally, if I let it sit there, the X310 must get into a wonky state
> because I start to get:
>
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #2
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #2
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [X300] 192.168.80.2: x300 fw communication failure #3
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> [ERROR] [UHD] An unexpected exception was caught in a task loop.The task
> loop will now exit, things may not work.EnvironmentError: IOError:
> 192.168.80.2: x300 fw communication failure #3
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
>
>
> What am I missing here?
> ___
> 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] RFNoC packet sizes

[Jonathon Pendlum via USRP-users]

Hi Sebastian,

Try also setting the spp via the stream args with stream_args.args["spp"].
You can see an example in rfnoc_rx_to_file.cpp around line 403.

Jonathon

On Fri, Sep 6, 2019 at 3:54 PM Sebastian Bräuer 
wrote:

> Hi Jonathon,
>
> thanks for the quick response. It is a UHD application and I set the
> radios spp via radio->set_arg before creating the streamers.
>
>
> Sebastian
>
> On 06.09.19 03:52, Jonathon Pendlum wrote:
> > Hi Sebastian
> >
> > Is this a UHD app or a GNU Radio flowgraph? Are you setting the spp via
> > stream args?
> >
> > Jonathon
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC packet sizes

[Jonathon Pendlum via USRP-users]

Hi Sebastian

Is this a UHD app or a GNU Radio flowgraph? Are you setting the spp via
stream args?

Jonathon
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC OFDM FPGA Build error on X310

[Jonathon Pendlum via USRP-users]

Hi Huacheng,

Unfortunately, the Schmidl Cox and Equalizer block's code has gotten out of
date. I would suggest looking at the blocks as a good starting point for
making your own version.

Jonathon

On Thu, Aug 29, 2019 at 4:57 AM Huacheng Zeng via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have been trying to build FPGA image for the RFNoC OFDM blocks -
> schmidl_cox, eq and ofdm_constellation demapper.
>
> I have tried different combination of build with just schimdl_cox or eq or
> ofdm_constellation_demapper:
>
> 1) For eq build, I always got the following error:
> ERROR: [Opt 31-2] SRLC32E
> x300_core/inst_eq/inst_axi_wrapper/header_fifo/fifo_short/gen_srlc32e[64].srlc32e
> is missing a connection on D pin.
>
> 2) For schmidl_cox or ofdm_constellation_demapper, I got the following
> problem:
> ERROR: [Builder 0-0] The design did not satisfy timing constraints.
> (Implementation outputs were still generated)
>
> Can anyone help with these issues?
>
> Thanks,
> Huacheng
>
> ___
> 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] RFNoc Testbench / EOB

[Jonathon Pendlum via USRP-users]

Hi Tim,

My mistake on my original reply, you should use push_pkt()/pull_pkt(). You
provide the header to that function (along with the payload), which is how
you will be able to set EOB and a packet size with an odd number of 16-bit
samples. If you really dig into sim_rfnoc_lib.svh, sim_cvita_lib.svh, and
noc_block_export_io.v, you'll see that push_pkt() interfaces with noc_shell
not axi_wrapper. Even though cvita_payload_t is a 64-bit wide queue, the
packet size in the header is what matters. You'll also need to remove or
modify line 236 in push_pkt() in sim_cvita_lib.svh, as that assertion
checks if the header's packet size is a multiple of 4 bytes.

Jonathon

On Wed, Aug 28, 2019 at 1:07 AM Timothy Kurp  wrote:

> Hi Jon,
>
> This doesn't answer my question, perhaps I didn't convey the problem
> clearly. I am trying to test the case where TLAST occurs on an odd sample,
> at the same time as EOB. Push word provides access to tlast, but not EOB.
> To throw eob I need to use send() which takes in pkt.payload and
> pkt.header. I can manipulate eob in the metadata there.  pkt.payload is of
> type cvita_payload_t, which is 64 bits wide. Send() will throw tlast at the
> end of the packet, which will always contain a multiple of 2 complex
> samples since the payload is defined at 64 bits. That is my problem.  There
> is no way to throw eob and tlast on a packet that contains an odd number of
> i/q samples.
>
> Tim
>
> On Tue, Aug 27, 2019 at 12:21 AM Timothy Kurp 
> wrote:
>
>> Thanks! I will look at that example.
>>
>> Tim
>>
>> On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum <
>> jonathon.pend...@ettus.com> wrote:
>>
>>> Hi Tim,
>>>
>>> Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit
>>> sample by sample basis. Unfortunately, if you want to do sizes smaller than
>>> 32-bit, you'll need to write your own version of send()/recv() or
>>> push_word()/pull_word() from sim_rfnoc_lib.svh.
>>>
>>> Jonathon
>>>
>>> On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hey Users!

 I think this may be a possible deficiency in the test bench
 architecture, or perhaps I just don't know how to instrument it properly. I
 have a custom block that performs a 2:1 rate change roughly, performing
 compression of the 16 bit I/Q from the radio down to a 16 bit word that is
 compressed, I won't describe how. There is a corner case if EOB occurs when
 there is an odd number of samples received from the radio. I have handled
 this by using simple mode = 0, manipulating cvita header manually and
 throwing tlast to make packets, with success. The noc block works, but I am
 struggling with how to exercise the corner case in the testbench.

 From what I have seen, the testbench only allows for EOB to be
 manipulated on sample counts that are a multiple of 2 (send() operates on
 64 bits, or 2 samples of 16 bit I/Q). We have looked at the source and
 there doesn't seem to be an easy way to throw EOB/TLAST on odd samples.We
 also think it is not guaranteed that this will never happen from the radio.
 Thoughts?

 Tim
 ___
 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] RFNoc Testbench / EOB

[Jonathon Pendlum via USRP-users]

Hi Tim,

Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit
sample by sample basis. Unfortunately, if you want to do sizes smaller than
32-bit, you'll need to write your own version of send()/recv() or
push_word()/pull_word() from sim_rfnoc_lib.svh.

Jonathon

On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Users!
>
> I think this may be a possible deficiency in the test bench architecture,
> or perhaps I just don't know how to instrument it properly. I have a custom
> block that performs a 2:1 rate change roughly, performing compression of
> the 16 bit I/Q from the radio down to a 16 bit word that is compressed, I
> won't describe how. There is a corner case if EOB occurs when there is an
> odd number of samples received from the radio. I have handled this by using
> simple mode = 0, manipulating cvita header manually and throwing tlast to
> make packets, with success. The noc block works, but I am struggling with
> how to exercise the corner case in the testbench.
>
> From what I have seen, the testbench only allows for EOB to be manipulated
> on sample counts that are a multiple of 2 (send() operates on 64 bits, or 2
> samples of 16 bit I/Q). We have looked at the source and there doesn't seem
> to be an easy way to throw EOB/TLAST on odd samples.We also think it is not
> guaranteed that this will never happen from the radio. Thoughts?
>
> Tim
> ___
> 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] RFNoC ce_rst and clear_tx_seqnum

[Jonathon Pendlum via USRP-users]

Calling device3->clear() will strobe clear_tx_seqnum, but it is not a
direct mapping. It also resets the upstream and downstream node
connections, If you need trigger the reset at specific times, it would
probably be easier to add your own reset settings register.

On Tue, Aug 27, 2019 at 10:55 AM Rob Kossler  wrote:

> Thanks Jonathon.  How about if I re-wire an rfnoc graph?  Does that assert
> clear_tx_seqnum?  Does the UHD device3->clear() function map directly or
> indirectly to this signal?
> Rob
>
> On Mon, Aug 26, 2019 at 9:49 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Rob,
>>
>> Originally clear_tx_seqnum was only for resetting AXI Wrapper, but it
>> evolved into a user reset as well since it is asserted every time your UHD
>> app starts. ce_rst is only asserted at power up.
>>
>> Jonathon
>>
>> On Tue, Aug 27, 2019 at 2:29 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Can anyone explain the meaning of the signals ce_rst and
>>> clear_tx_seqnum?  It is not clear to me what would cause either of them to
>>> go High.  Should I expect ce_rst to be strobed each time I launch my C++
>>> app that calls UHD?  I had previously thought so, but now I have reason to
>>> doubt.
>>>
>>> Thanks.
>>> Rob
>>> ___
>>> 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] RFNoC ce_rst and clear_tx_seqnum

[Jonathon Pendlum via USRP-users]

Hi Rob,

Originally clear_tx_seqnum was only for resetting AXI Wrapper, but it
evolved into a user reset as well since it is asserted every time your UHD
app starts. ce_rst is only asserted at power up.

Jonathon

On Tue, Aug 27, 2019 at 2:29 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Can anyone explain the meaning of the signals ce_rst and clear_tx_seqnum?
> It is not clear to me what would cause either of them to go High.  Should I
> expect ce_rst to be strobed each time I launch my C++ app that calls UHD?
> I had previously thought so, but now I have reason to doubt.
>
> Thanks.
> Rob
> ___
> 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] Error 'Timeout on Chan 0'

[Jonathon Pendlum via USRP-users]

Hi Kirsten,

That warning means you did not provide a custom C++ block controller for
your RFNoC block. If you are only using the Nocscript xml to describe your
block (most blocks do this), then you can ignore the warning.

Jonathon

On Mon, Aug 5, 2019 at 10:49 PM Leong, Kirsten - 0551 - MITLL via
USRP-users  wrote:

> Could this be because I get the warning ‘can’t find a block controller for
> key fmdemod, using default block controller!’ or is this a separate problem?
>
>
>
> Thanks,
>
> Kirsten
>
>
>
> *From: *USRP-users  on behalf of
> "Leong, Kirsten - 0551 - MITLL via USRP-users"  >
> *Reply-To: *"Leong, Kirsten - 0551 - MITLL" 
> *Date: *Friday, August 2, 2019 at 12:25 PM
> *To: *Lars Kuger , "usrp-users@lists.ettus.com"
> 
> *Subject: *Re: [USRP-users] Error 'Timeout on Chan 0'
>
>
>
> I tried reformatting the xml file based off the uhd_rfnoc_adder.xml file;
> however, I still get the same error. I’m not trying to throw any packets
> away so I cannot ignore the error. My block is expecting to take in a
> complex 32bit floats and output a 32 bit float.
>
>
>
> *From: *USRP-users  on behalf of Lars
> Kuger via USRP-users 
> *Reply-To: *Lars Kuger 
> *Date: *Friday, August 2, 2019 at 10:14 AM
> *To: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Error 'Timeout on Chan 0'
>
>
>
> Hello Kirsten,
>
> I remember getting the same error message while developing a custom RFNoC
> block. I found the problem to be caused by the corresponding xml file which
> is located in the grc folder. I am not sure what part of the file exactly
> caused the error message (maybe the ordering of the parameters or tags
> within the parameters) but I eventually solved it by replacing the file
> with the xml file from a working block and modifying that one.
>
> Best regards,
> Lars
>
>
>
> On 02.08.19 15:50, Leong, Kirsten - 0551 - MITLL via USRP-users wrote:
>
> Hello,
>
>
>
> I am using a USRP X310 and am using gnuradio companion to test a custom
> block. The current diagram flows as follows: File Source->RFNoC
> FIFO->custom block->complex to image->frequency sink. However, when I try
> to execute, I get the error ‘timeout on chan 0’. My testbench passes all 5
> cases; I can read signals on the inputs and outputs of the noc block and
> the flow graph works once I remove my custom block. Where else should I be
> looking?
>
>
>
> Thanks,
>
> Kirsten
>
>
>
>
> ___
>
> 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] Error 'Timeout on Chan 0'

[Jonathon Pendlum via USRP-users]

Hi Kirsten,

Have you used chipscope on your block and checked that it is sending out
samples? If not, I would suggest at minimum looking at the status of the
m_data and s_data AXI stream buses on AXI wrapper. Here is a guide on how
to setup chipscope: https://kb.ettus.com/Debugging_FPGA_images

Jonathon

On Sat, Aug 3, 2019 at 1:24 AM Leong, Kirsten - 0551 - MITLL via USRP-users
 wrote:

> I tried reformatting the xml file based off the uhd_rfnoc_adder.xml file;
> however, I still get the same error. I’m not trying to throw any packets
> away so I cannot ignore the error. My block is expecting to take in a
> complex 32bit floats and output a 32 bit float.
>
>
>
> *From: *USRP-users  on behalf of Lars
> Kuger via USRP-users 
> *Reply-To: *Lars Kuger 
> *Date: *Friday, August 2, 2019 at 10:14 AM
> *To: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Error 'Timeout on Chan 0'
>
>
>
> Hello Kirsten,
>
> I remember getting the same error message while developing a custom RFNoC
> block. I found the problem to be caused by the corresponding xml file which
> is located in the grc folder. I am not sure what part of the file exactly
> caused the error message (maybe the ordering of the parameters or tags
> within the parameters) but I eventually solved it by replacing the file
> with the xml file from a working block and modifying that one.
>
> Best regards,
> Lars
>
>
>
> On 02.08.19 15:50, Leong, Kirsten - 0551 - MITLL via USRP-users wrote:
>
> Hello,
>
>
>
> I am using a USRP X310 and am using gnuradio companion to test a custom
> block. The current diagram flows as follows: File Source->RFNoC
> FIFO->custom block->complex to image->frequency sink. However, when I try
> to execute, I get the error ‘timeout on chan 0’. My testbench passes all 5
> cases; I can read signals on the inputs and outputs of the noc block and
> the flow graph works once I remove my custom block. Where else should I be
> looking?
>
>
>
> Thanks,
>
> Kirsten
>
>
>
> ___
>
> 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] [X310] RFNoC block tready is deasserted unexpectedly

[Jonathon Pendlum via USRP-users]

Hi,

Assuming you are using ce_clk, the signal generators run at 214 MHz and
generate one sample per clock cycle, so they produce samples at 214 MSPS.
The radios consume samples at 200 MSPS. The back pressure is due to the
signal generator producing samples faster than the radio can consume. This
is expected behavior.

Jonathon

On Fri, Aug 2, 2019 at 12:15 AM Adrià Amézaga via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I have an application where two RFNoC signal generators transmit samples
> to two TX radios at full 200MSPS rate.
>
> I need these samples to be contiguously transmitted in time.
>
> It is my understanding that the RFNoC crossbar can handle both streams.
> However, after some tests and debugging with ChipScope I have seen that
> the AXI wrapper s_axis_data_tready  signal goes low for some time at
> some point before sample generation has ended. The moment when tready
> goes low depends on the packet size.
>
> I cannot see why the TX stream is back-pressuring, so I'm obviously
> missing something. Any clarification would be appreciated.
>
> Thanks in advance!
>
>
> ___
> 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] N310 RFNOC tutorial block "gain" not found in synthesis

[Jonathon Pendlum via USRP-users]

Hi,

Could you try generating the image with uhd_image_builder_gui.py and see if
you get the same error?

Jonathon

On Wed, Jul 31, 2019 at 8:29 AM 汤 飞 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I am studying the application note "Getting Started with RFNoC Development".
> I was able to complete the simulation of custom noc_block_gain, but failed in 
> the final stage of the synthesis.
> The custom block "gain" cannot be found.
> I use the following command,  "./uhd_image_builder.py gain ddc fft -I 
> ~/rfnoc/src/rfnoc-mesh/ -d n310 -t N310_RFNOC_HG -m 6 --fill-with-fifos -c".
> I did specify the OOT directory during image building. I am certain I have 
> made all settings correct.
> So far I have no clue what causes this. How to solve this problem?
>
>
> PS, I use uhd 3.14.0.0, and post of imaging buiding,
>
> ** Vivado v2018.3_AR71898 (64-bit)
>    SW Build 2405991 on Thu Dec  6 23:36:41 MST 2018
>    IP Build 2404404 on Fri Dec  7 01:43:56 MST 2018
> ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
>
> source run_ippack.tcl -notrace
> INFO: [IP_Flow 19-234] Refreshing IP repositories
> INFO: [IP_Flow 19-1704] No user IP repositories specified
> INFO: [IP_Flow 19-2313] Loaded Vivado IP repository 
> '/opt/Xilinx/Vivado/2018.3/data/ip'.
> INFO: [Common 17-206] Exiting Vivado at Tue Jul 30 20:41:13 2019...
> INFO: [HLS 200-112] Total elapsed time: 17.38 seconds; peak allocated memory: 
> 66.934 MB.
> INFO: [Common 17-206] Exiting vivado_hls at Tue Jul 30 20:41:13 2019...
> BUILDER: Releasing IP location: 
> /home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/addsub_hls
> Using parser configuration from: 
> /home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/dev_config.json*[00:00:00] 
> Executing command: vivado -mode batch -source 
> /home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build_n3xx.tcl -log build.log 
> -journal n3xx.jou*CRITICAL WARNING: [filemgmt 20-1440] File 
> '/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_2_tempmon.v'
>  already exists in the project as a part of sub-design file 
> '/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/ddr3_32bit/ddr3_32bit.xci'.
>  Explicitly adding the file outside the scope of the sub-design can lead to 
> unintended behaviors and is not recommended.
> [00:00:14] Current task: Initialization +++ Current Phase: Starting
> [00:00:14] Current task: Initialization +++ Current Phase: 
> Finished*[00:00:14] Executing Tcl: synth_design -top n3xx -part 
> xc7z100ffg900-2 -verilog_define SFP0_1GBE=1 -verilog_define SFP1_10GBE=1 
> -verilog_define USE_REPLAY=1 -verilog_define BUILD_1G=1 -verilog_define 
> BUILD_10G=1 -verilog_define RFNOC=1 -verilog_define N310=1 -verilog_define 
> GIT_HASH=32'hfb615a5a*[00:00:14] Starting Synthesis Command*ERROR: [Synth 
> 8-439] module 'noc_block_gain' not found 
> [/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v:22]**ERROR:
>  [Synth 8-6156] failed synthesizing module 'n3xx_core' 
> [/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/n3xx_core.v:17]**ERROR: [Synth 
> 8-6156] failed synthesizing module 'n3xx' 
> [/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx/dboards/mg/n3xx.v:13]**ERROR: 
> [Common 17-69] Command failed: Synthesis failed - please see the console or 
> run log file for details*
> [00:03:48] Current task: Synthesis +++ Current Phase: Starting
> [00:03:49] Current task: Synthesis +++ Current Phase: Finished*[00:03:49] 
> Process terminated. Status: Failure*
>
> 
> Warnings:   407
> Critical Warnings:  1
> Errors: 4
>
> Makefile.n3xx.inc:149: recipe for target 'bin' failed
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory '/home/wtt/rfnoc/src/uhd-fpga/usrp3/top/n3xx'
> Makefile:133: recipe for target 'N310_RFNOC_HG' failed
> make: *** [N310_RFNOC_HG] Error 2
>
> ___
> 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] noc_block_threshold.v ram issue

[Jonathon Pendlum via USRP-users]

Scott and I determined off list that the STR_SINK_FIFOSIZE parameter on
noc_shell was misconfigured.

On Thu, Jul 25, 2019 at 9:32 PM Jonathon Pendlum 
wrote:

> Hey Scott,
>
> Have you tried building an image with an unmodified noc_block_threshold.v?
> Do you get the same BRAM usage?
>
> Jonathon
>
> On Thu, Jul 25, 2019 at 9:28 PM Scott Mullin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello All,
>>
>> I am trying to use the threshold block on two streams of rf data by using
>> a common tkeep signal to the two axi_async_stream modules. I used the
>> noc_block_threshold.v code and added a generate statement to create two
>> axi_wrappers and two axi_async_stream modules. Plus added some simple code
>> to trigger the tkeep signal when either rf stream breaks the threshold.
>> However when I try to build the image I get a block ram error (shown
>> below).  I assume it has something to do with the fifo in the
>> axi_async_stream module, but I am not sure?
>>
>> I am building this for an X310.
>>
>> Any help would be appreciated.
>>
>> Thank you
>> Scott.
>>
>> [00:05:12] Current task: Synthesis +++ Current Phase: RTL Component
>> Statistics
>> [00:05:12] Current task: Synthesis +++ Current Phase: RTL Hierarchical
>> Component Statistics
>> [00:05:13] Current task: Synthesis +++ Current Phase: Part Resource
>> Summary
>> ERROR: [Synth 8-5834] Design needs 17067 RAMB18 which is more than device
>> capacity of 1590
>> ERROR: [Common 17-69] Command failed: Vivado Synthesis failed
>> [00:06:46] Current task: Synthesis +++ Current Phase: Cross Boundary and
>> Area Optimization
>> [00:06:47] Current task: Synthesis +++ Current Phase: Finished
>> [00:06:47] Process terminated. Status: Failure
>>
>> 
>> Warnings:   814
>> Critical Warnings:  31
>> Errors: 2
>>
>> Makefile.x300.inc:106: recipe for target 'bin' failed
>> make[1]: *** [bin] Error 1
>> make[1]: Leaving directory
>> '/home/irisheyes5/rfnoc_2/src/uhd-fpga/usrp3/top/x300'
>> Makefile:112: recipe for target 'X310_RFNOC_HG' failed
>> make: *** [X310_RFNOC_HG] Error 2
>>
>> ___
>> 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] noc_block_threshold.v ram issue

[Jonathon Pendlum via USRP-users]

Hey Scott,

Have you tried building an image with an unmodified noc_block_threshold.v?
Do you get the same BRAM usage?

Jonathon

On Thu, Jul 25, 2019 at 9:28 PM Scott Mullin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello All,
>
> I am trying to use the threshold block on two streams of rf data by using
> a common tkeep signal to the two axi_async_stream modules. I used the
> noc_block_threshold.v code and added a generate statement to create two
> axi_wrappers and two axi_async_stream modules. Plus added some simple code
> to trigger the tkeep signal when either rf stream breaks the threshold.
> However when I try to build the image I get a block ram error (shown
> below).  I assume it has something to do with the fifo in the
> axi_async_stream module, but I am not sure?
>
> I am building this for an X310.
>
> Any help would be appreciated.
>
> Thank you
> Scott.
>
> [00:05:12] Current task: Synthesis +++ Current Phase: RTL Component
> Statistics
> [00:05:12] Current task: Synthesis +++ Current Phase: RTL Hierarchical
> Component Statistics
> [00:05:13] Current task: Synthesis +++ Current Phase: Part Resource Summary
> ERROR: [Synth 8-5834] Design needs 17067 RAMB18 which is more than device
> capacity of 1590
> ERROR: [Common 17-69] Command failed: Vivado Synthesis failed
> [00:06:46] Current task: Synthesis +++ Current Phase: Cross Boundary and
> Area Optimization
> [00:06:47] Current task: Synthesis +++ Current Phase: Finished
> [00:06:47] Process terminated. Status: Failure
>
> 
> Warnings:   814
> Critical Warnings:  31
> Errors: 2
>
> Makefile.x300.inc:106: recipe for target 'bin' failed
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory
> '/home/irisheyes5/rfnoc_2/src/uhd-fpga/usrp3/top/x300'
> Makefile:112: recipe for target 'X310_RFNOC_HG' failed
> make: *** [X310_RFNOC_HG] Error 2
>
> ___
> 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] Noc_block_Schmidl_cox Timing error

[Jonathon Pendlum via USRP-users]

Hi Scott,

The CORDIC Xilinx IP is breaking timing. The CORDIC's bit width could be
better optimized, but changing it would require editing of other parts of
the code too.

One simple thing you could try is hand editing
fpga/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v and changing
noc_block_schmidl_cox's input from ".ce_clk(ce_clk)," to
".ce_clk(bus_clk),". Note that the file is overwritten when running
uhd_image_builder, so you'll need to run the FPGA build Makefile manually
(i.e. make X310_HG_RFNOC).

If you are still failing timing using bus_clk, you can also try
bus_clk_div2.

Jonathon

On Thu, Jul 18, 2019 at 9:34 PM Scott Mullin  wrote:

> Jonathan,
> Thanks for the heads up on this block.Full disclosure, I am fairly new to
> this so I am not sure how to tell. Here are the build.rpt and timing
> reports from the build I did this morning.
>
> Hope that helps.
>
> Scott
>
> On Wed, Jul 17, 2019 at 11:50 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Scott,
>>
>> What paths are failing timing? Also, the Schmidl Cox block has some
>> design issues that need fixed before it can be useful again. If I remember
>> correctly, I think there is an issue with the peak detection logic.
>>
>> Jonathon
>>
>> On Wed, Jul 17, 2019 at 2:28 AM Scott Mullin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> I am trying to use the schmidl_cox noc block but when I build an fpga
>>> image for an x310 with uhd_image_builder I get a timing error.  I have
>>> tried building an fpga image with only one CE, the scmidl_cox noc block,
>>> and it still gives me a timing error, so its not due to resource
>>> utilization, which is when I typically get a timing error.
>>>
>>> Has anyone else had this issue? Any help would be appreciated.
>>>
>>> --
>>> Scott Mullin
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>
> --
> Scott Mullin
> University of Notre Dame
> Engineering and Design Core Facility
> 204D Nieuwland Science Hall
> University of Notre Dame
> IN 46556
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] custom block and data rate in x310

[Jonathon Pendlum via USRP-users]

Hi,

I would suggest reading the RFNoC getting started guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_Development) and making
your correlator into a RFNoC block. Then it will be easy to include your
correlator in a GNU Radio flow graph.

1) Where exactly in the code is the ddc chain instantiated *? Should I
> do it myself ?
>

The DDC code is in the RFNoC DDC block, noc_block_ddc.v. The default X310
image includes two DDCs, so you don't need to instantiate anything.


> 2) Is it possible to have a decimation rate of 200 or should it be a
> power of 2 ?
>

You can have a decimation rate of 200. The DDC has a CIC filter along with
3 half band filters, so the decimation rate is fairly flexible.


> 3) How is the decimation rate controlled ? From what I understand it's
> from the sampling rate parameter in GnuRadio. Am I right ?


 If using the USRP Source block in GNU Radio, setting the sample rate will
setup the DDC. If using Device 3 (i.e. a RFNoC flow graph) in GNU radio,
you will need to set the decimation rate on the RFNoC: DDC block.

Jonathon

On Wed, Jul 17, 2019 at 5:30 PM fbarras via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I developed a custom correlation module in Verilog and I would like to
> insert it in the usrp x310 fpga image. My goal is to send a  signal
> (with a usrp b205 mini) at a sampling rate of 1M and to receive it with
> the usrp x310. Inside the fpga, my block will look for a certain
> sequence inside the received signal.
>
> My block is working with a 200M clock and can support data rate up to
> 2M.
>  From what I've read, it seems that the adc of the x310 is working at
> 200M and that this can't be changed. So my module should be placed after
> the ddc chain. But this rises a few questions:
>
> 1) Where exactly in the code is the ddc chain instantiated *? Should I
> do it myself ?
>
> 2) Is it possible to have a decimation rate of 200 or should it be a
> power of 2 ?
>
> 3) How is the decimation rate controlled ? From what I understand it's
> from the sampling rate parameter in GnuRadio. Am I right ?
>
> Thanks !
>
> * For some reasons, I'm working with uhd  3.10.3
>
> ___
> 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] Noc_block_Schmidl_cox Timing error

[Jonathon Pendlum via USRP-users]

Hi Scott,

What paths are failing timing? Also, the Schmidl Cox block has some design
issues that need fixed before it can be useful again. If I remember
correctly, I think there is an issue with the peak detection logic.

Jonathon

On Wed, Jul 17, 2019 at 2:28 AM Scott Mullin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I am trying to use the schmidl_cox noc block but when I build an fpga
> image for an x310 with uhd_image_builder I get a timing error.  I have
> tried building an fpga image with only one CE, the scmidl_cox noc block,
> and it still gives me a timing error, so its not due to resource
> utilization, which is when I typically get a timing error.
>
> Has anyone else had this issue? Any help would be appreciated.
>
> --
> Scott Mullin
>
> ___
> 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] RFNoC Utilisation

[Jonathon Pendlum via USRP-users]

Hi,

You are building an image with 1 x DDC and 7 x FIFO RFNoC blocks due to the
arg "--fill-with-fifos". Remove that arg and your utilization should be
significantly lower.

Jonathon

On Mon, Jul 1, 2019 at 1:42 AM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> According to this link (https://kb.ettus.com/X300/X310) the baselink
> RFNoC X310 image should use <25% of the available LUTs. However, my build
> uses more than 50% with a single DDC using the same UHD release:
>
> ./uhd_image_builder.py ddc -d x310 -t X310_RFNOC_HG -m 8 --fill-with-fifos.
>
> The DDC should not require >25% of the available LUTS, so am i missing
> something? Should I be using an alternative to the X310_RFNOC_HG base
> image to achieve this utilisation.
> I really need that 25% of LUTS for my design so any guidance would be
> gratefully received.
>
> Thanks,
>
> Andy
> X300/X310 - Ettus Knowledge Base 
> Device Overview. The Ettus Research USRP X310 is a high-performance,
> scalable software defined radio (SDR) platform for designing and deploying
> next generation wireless communications systems.
> kb.ettus.com
>
>
> Sent from Outlook 
> ___
> 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] X310 RFNoC transmission issues

[Jonathon Pendlum via USRP-users]

Hello Leon,

Did you check to see if your custom image failed timing?

Jonathon

On Thu, May 9, 2019 at 12:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block diagram is:
>
>
>  Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in
> TX mode).
>
>
> I run the block diagram by calling "python top_block.py" from the
> command line and I'm not getting any errors while it's running .
> However, I'm unable to quit it properly without having to close the
> terminal window and power-cycle the USRP. When connecting the USRP to a
> spectrum analyzer I see no signal whatsoever (I expect to see a peak at
> 2.4 GHz).
>
>
> Removing the DmaFIFO does not seem to make any difference. My FPGA image
> is a custom image with some of my CEs, but it was built smoothly using
> the "uhd_image_builder.py" script. I've also experienced similar
> problems while having a RFNoC: DUC between the DmaFIFO and the Radio
> block, also with a custom FPGA image. With the stock FPGA image I was
> able to get a signal with more or less the same Gnuradio block diagram.
>
>
> Why am I not seeing any output with my custom FPGA images? All
> suggestions appreciated.
>
>
> I'll happily provide more info if needed, so don't hesitate to ask. For
> know, I'll just provide the basics:
>
>
>  OS: Ubuntu 18.04
>
>  uhd: rfnoc-devel, eec24d7b0
>
>  gnuradio: maint-3.7, c6c575309
>
>  gr-ettus: master, a909447
>
>
> Thanks in advance!
>
> //
>
> Leon
>
>
> ___
> 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] vita_time in noc_shell and axi_wrapper

[Jonathon Pendlum via USRP-users]

Hi,

The vita_time input should be ignored. It is meant to be used with the
Radio Core. For timed commands, you should instead compare the vita time
from the header of incoming CHDR packets with the "set_time" signal of the
settings bus. You can see an example of this with the DDC / DUC blocks,
where the module axi_tag_time is used to tag samples to trigger commands at
a specific vita time.

Jonathon

On Wed, Apr 10, 2019 at 8:49 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>  What is the difference for vita_time between the vita_time in noc_shell
> and axi_wrapper in a RFNOC module?
> I noticed that there is vita_time input for noc_shell, but also a
> vita_time can be included in the axi_wrapper input s_axis_data_tuser. I
> guess that for noc_shell, the vita_time input is for the universal
> synchronization time between modules. And the vita_time in the axi_wrapper
> input s_axis_data_tuser is for schedule a future command. For example, I
> can add a delay time for transmission in the header in s_axis_data_tuser in
> siggen rfnoc example.
> ___
> 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] Maximal number of RFNoC-blocks

[Jonathon Pendlum via USRP-users]

Hi Rob,

Yes it is possible. All of these modifications require editing the core
FPGA code and UHD. Removing the DmaFIFO is not too difficult. Althought it
can be done, I would not suggest modifying the Eth or PCIe interfaces.

Jonathon

On Tue, Apr 9, 2019 at 6:35 AM Rob Kossler  wrote:

> Hi Jonathon,
> Is it possible to increase the 10 available to 13 by:
> - building an HG image that only needs one 10GigE
> - excluding the DmaFIFO (assuming underruns not an issue w/o this block)
> - building without PCIe support (is this even possible?)
>
> Rob
>
>
> On Thu, Apr 4, 2019 at 10:12 AM Jonathon Pendlum via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> On the X310, the crossbar is limited to 16 ports. Of the 16 ports, only
>> 10 are available because the other 6 are already occupied: 2x 10GigE, 1x
>> PCIe, 2x Radio Core RFNoC blocks, 1x DmaFIFO RFNoC block.
>>
>> Jonathon
>>
>> On Thu, Apr 4, 2019 at 11:03 PM Jason Matusiak via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I don't know why this would be, but it almost feels like a hex issue
>>> somewhere.  Where are you setting the block size to 10?  It feels like
>>> something is interpreting that as 0x10, and I think 16 is a magic number
>>> that is too large.
>>>
>>> --
>>> *From:* USRP-users  on behalf of
>>> Armin Schmidt via USRP-users 
>>> *Sent:* Thursday, April 4, 2019 4:13 AM
>>> *To:* USRP-users@lists.ettus.com
>>> *Subject:* [USRP-users] Maximal number of RFNoC-blocks
>>>
>>> Hallo everyone and Ettus development team,
>>>
>>> We use uhd 3.14 rc1 and we have the strange behaviour, that after the
>>> magic number of 10 RFNoC-blocks on the FPGA, we get the following error:
>>>
>>> [ERROR] [UHD] Exception caught in safe-call.
>>>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
>>> uhd::endianness_t _endianness = (uhd::endianness_t)0u]
>>>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
>>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
>>> (CE_13_Port_00) no response packet - AssertionError: bool(buff)
>>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
>>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t =
>>> long unsigned int]
>>>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>>>
>>> terminate called after throwing an instance of 'uhd::io_error'
>>>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet
>>> parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00
>>> Received SID: 00:12>02:00
>>> Aborted (core dumped)
>>>
>>> It is not a problem of the FPGA-Capacity and also not a timing issue. So
>>> it seems to be somehow a hardcoded limit from ettus. Does someone know how
>>> to stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we
>>> get this error! It is also not dependant of the type of blocks, we put on
>>> the FPGA.
>>>
>>> Many thanks for your help!
>>>
>>> Armin Schmidt
>>> ___
>>> 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] What is the best way to trigger rfnoc receiver radio?

[Jonathon Pendlum via USRP-users]

Hi James,

I suggest taking a look at rx_control_gen3.v. RX is started by issuing
commands to the state machine in that file. You could modify it to instead
accept a trigger signal.

Jonathon

On Thu, Apr 4, 2019 at 3:20 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
> I have some questions about how to trigger RFNOC receiver. I have a module
> detecting the rising edge of a fixed clock. I used that clock to trigger Tx
> and Rx modules. Now the transmit RFNOC module is working properly but the
> receive module gives me non-deterministic m_axis_data_tvalid such that I
> cannot determine when the Rx radio started recording. I am wondering if
> anyone know how to use a clock or any trigger to let RFNOC Rx radio
> starting to record signal? The USRP I am using now is E312. Thank you!
>
> James
> ___
> 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] Maximal number of RFNoC-blocks

[Jonathon Pendlum via USRP-users]

Hi,

On the X310, the crossbar is limited to 16 ports. Of the 16 ports, only 10
are available because the other 6 are already occupied: 2x 10GigE, 1x PCIe,
2x Radio Core RFNoC blocks, 1x DmaFIFO RFNoC block.

Jonathon

On Thu, Apr 4, 2019 at 11:03 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I don't know why this would be, but it almost feels like a hex issue
> somewhere.  Where are you setting the block size to 10?  It feels like
> something is interpreting that as 0x10, and I think 16 is a magic number
> that is too large.
>
> --
> *From:* USRP-users  on behalf of
> Armin Schmidt via USRP-users 
> *Sent:* Thursday, April 4, 2019 4:13 AM
> *To:* USRP-users@lists.ettus.com
> *Subject:* [USRP-users] Maximal number of RFNoC-blocks
>
> Hallo everyone and Ettus development team,
>
> We use uhd 3.14 rc1 and we have the strange behaviour, that after the
> magic number of 10 RFNoC-blocks on the FPGA, we get the following error:
>
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0u]
>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_13_Port_00) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t =
> long unsigned int]
>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet
> parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00
> Received SID: 00:12>02:00
> Aborted (core dumped)
>
> It is not a problem of the FPGA-Capacity and also not a timing issue. So
> it seems to be somehow a hardcoded limit from ettus. Does someone know how
> to stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we
> get this error! It is also not dependant of the type of blocks, we put on
> the FPGA.
>
> Many thanks for your help!
>
> Armin Schmidt
> ___
> 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] RFNoC FFT size > 1024

[Jonathon Pendlum via USRP-users]

Hey Rob,

Regarding overflows or dropped packets, is this something that might
> occur inside the FPGA (CE to CE) or is it just a concern on the
> transfer to the host CPU (which is my only experience with overflows
> or dropped packets)?  If on the FPGA, what would be the cause of
> overflows / dropped packets in the following scenario:
> rx_radio->DDC->FFT->host?


Overflow generally only occurs due to the host being unable to consume
samples quickly enough. It is possible for overflows to occur due to a
RFNoC block not consuming samples quickly enough, but all in-tree blocks
are designed to avoid that situation. Drops only occur between the device
and host.

Regarding the header, is the concern the following? Assume packet size
> of 1024 and FFT size of 4096 such that there would be 4 packets for
> each FFT; Now assume that EOB occurs on the 3rd packet such that the
> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
> in a bad state.  Is this the issue?  If not, please explain.  If so,
> is the fix to reset the FFT on any incoming EOB? Without any fix, does
> this issue correct itself in some way during the subsequent stream or
> is the input frame mismatch issue going to remain until the FFT is
> manually reset?


Correct, resetting the FFT on EOB is a possible solution. If you reset on
EOB though, you'll need to figure out a way to still send that final packet
with EOB set to the host. Maybe zero fill the missing samples to complete
the FFT? The issue will also fix itself on the next burst assuming you
don't care that the first FFT might be corrupt.

Jonathon

On Sun, Mar 3, 2019 at 1:16 AM Rob Kossler  wrote:

> Thanks Jonathon,
>
> > I'm glad you found those options useful. Unfortunately, there are a
> number of corner cases that those options do not handle. You can run into
> synchronization issues when overflows and dropped packets occur. In the
> overflow case, if one occurs while the FFT is being filled then the next
> FFT output will be incorrect. In the dropped packet case, the received FFT
> frames could end up shifted between two FFT frames. The dropped packet case
> is by the far worse of the two.
>
> Regarding overflows or dropped packets, is this something that might
> occur inside the FPGA (CE to CE) or is it just a concern on the
> transfer to the host CPU (which is my only experience with overflows
> or dropped packets)?  If on the FPGA, what would be the cause of
> overflows / dropped packets in the following scenario:
> rx_radio->DDC->FFT->host?
>
> > The block also does not handle the packet header correctly when FFTs are
> split between multiple packets. For example, EOBs will not cause the FFT
> core to reset, so the next burst could have an incorrect FFT output at the
> beginning. Most of these issues can be worked around or even ignored, but I
> think for general usage the block will need to be updated to handle them
> properly.
>
> Regarding the header, is the concern the following? Assume packet size
> of 1024 and FFT size of 4096 such that there would be 4 packets for
> each FFT; Now assume that EOB occurs on the 3rd packet such that the
> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
> in a bad state.  Is this the issue?  If not, please explain.  If so,
> is the fix to reset the FFT on any incoming EOB? Without any fix, does
> this issue correct itself in some way during the subsequent stream or
> is the input frame mismatch issue going to remain until the FFT is
> manually reset?
>
> Thanks for your help.
> Rob
>
>
> > On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >>
> >> Turns out there was a surprisingly simple modification to allow FFTs
> longer than 1024.  The axi_wrapper will automatically resize packets for
> you if you configure it to do so.  All I had to do was set
> RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output
> packets to be resized to match the input packet size.  I was able to then
> run 2048 and 4096 pt FFTs successfully (& producing the expected results)
> and I could use any packet size I wanted going in and out of the overall
> noc block.
> >>
> >> I did not even have to resize the packets going into the FFT because
> the FFT doesn't care about input packet size with the caveat that it
> generates various "bad size" events if it detects mismatches.  Since I am
> not monitoring such events, it doesn't really matter. And, if I did care
> about these bad size events, the fix is simply to add
> RESIZE_INPUT_PACKET(1) and set the desired resize value (i.e., the FFT
> length) using the axi_wrapper "m_axis_pkt_len_t*" inputs.
> >>
> >> With such a simple fix, it seems that Ettus should permanently change
> noc_block_fft.v to incorporate this.  Another change would be to modify
> this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting
> of 11 in order to match the axi_fft IP core set for a max FFT of 4096.
> >>
> >> Rob

Re: [USRP-users] Sending very short bursts with RFNoC on X310

[Jonathon Pendlum via USRP-users]

Hey Nick,

The DDC and the DUC (or any other block using axi_rate_change) will not
modify the packet size. Very small packets can cause underruns once the
header becomes a large percentage of the overall packet size. I'm surprised
that you are running into underruns at 20 samples per packet as that is
less than 10% header overhead. The theoretical crossbar throughput is 375
MSPS. Noc_shell's throughput is similar to the crossbar's since it also
operates on the packet line by line. Flow control packets and crossbar
switching add to the overhead as well, but there should still be plenty of
throughput left.

What version/branch of UHD are you using? If you are using UHD-3.13, try
setting your MTU to something closer to your actual packet size or try
using UHD-3.14.

As for the EOB issue, when the radio core encounters an underrun it will
stop transmitting and wait for an EOB. I wonder if the EOB never comes for
some reason, such as the DUC is not outputting it. Have you tried testing
in loopback and seeing if the DUC actually outputs an EOB on the last
packet?

Jonathon

On Sat, Mar 9, 2019 at 8:36 AM Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to write an RFNoC application which generates very short bursts
> -- 20 samples or less -- which are then upsampled. I'm running into
> problems with the radio underflowing which I believe has to do with the DUC.
>
> I can reduce the problem to the following -- create an RFNoC graph (UHD
> only, no gr-ettus) with a radio and a DUC. Wire the DUC to the radio and
> get a tx_streamer pointing to the DUC. Set the DUC to interp=1024. Start
> the streamer via calling the radio's set_tx_streamer().
>
> Now send a packet to the DUC, a short one. Try 20 samples. You'll see a
> bunch of underflows come back, and if you set EOB then the radio will stop
> transmitting. (Incidentally, why is that? If I set EOB and the transmission
> results in an underflow, subsequent bursts won't transmit at all.)
>
> If I pull the radio out of the loop and gather the DUC output on the host,
> Wireshark shows I'm receiving a whole slew of length-88 packets. That's 20
> samples after the 64-bit header. So, it looks to me like axi_rate_change
> inside the DUC isn't resizing the output packets, it's just sending out *lots
> of them* -- in this case, 1024 20-sample packets for every input packet.
> This doesn't make a whole lot of sense to me as it's inefficient, and I can
> fully believe the radio is underflowing while trying to swallow a whole
> mess of short packets at full radio rate.
>
> So: is this intended behavior, and is there anything I can do to change
> that behavior besides padding my bursts?
>
> Nick
> ___
> 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] RFNoC FFT size > 1024

[Jonathon Pendlum via USRP-users]

Hi Rob,

I'm glad you found those options useful. Unfortunately, there are a number
of corner cases that those options do not handle. You can run into
synchronization issues when overflows and dropped packets occur. In the
overflow case, if one occurs while the FFT is being filled then the next
FFT output will be incorrect. In the dropped packet case, the received FFT
frames could end up shifted between two FFT frames. The dropped packet case
is by the far worse of the two. The block also does not handle the packet
header correctly when FFTs are split between multiple packets. For example,
EOBs will not cause the FFT core to reset, so the next burst could have an
incorrect FFT output at the beginning. Most of these issues can be worked
around or even ignored, but I think for general usage the block will need
to be updated to handle them properly.

Jonathon




On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Turns out there was a surprisingly simple modification to allow FFTs
> longer than 1024.  The axi_wrapper will automatically resize packets for
> you if you configure it to do so.  All I had to do was set
> RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output
> packets to be resized to match the input packet size.  I was able to then
> run 2048 and 4096 pt FFTs successfully (& producing the expected results)
> and I could use any packet size I wanted going in and out of the overall
> noc block.
>
> I did not even have to resize the packets going into the FFT because the
> FFT doesn't care about input packet size with the caveat that it generates
> various "bad size" events if it detects mismatches.  Since I am not
> monitoring such events, it doesn't really matter. And, if I did care about
> these bad size events, the fix is simply to add RESIZE_INPUT_PACKET(1) and
> set the desired resize value (i.e., the FFT length) using the axi_wrapper
> "m_axis_pkt_len_t*" inputs.
>
> With such a simple fix, it seems that Ettus should permanently change
> noc_block_fft.v to incorporate this.  Another change would be to modify
> this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting
> of 11 in order to match the axi_fft IP core set for a max FFT of 4096.
>
> Rob
>
> On Fri, Mar 1, 2019 at 11:24 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> Probably not the approved way, but I made an FFT 2048 block a while
>> back.  I didn't much with packet sizes or anything, I just sucked in two
>> 1024 packets, did the FFT, and then sent two 1024 packets back out.  It
>> seemed to work fine.  The only issue is that you have to remember
>> downstream that you need 2 vectors in a row to get your data.
>>
>> --
>> *From:* USRP-users  on behalf of Rob
>> Kossler via USRP-users 
>> *Sent:* Thursday, February 28, 2019 4:08 PM
>> *To:* usrp-users
>> *Subject:* [USRP-users] RFNoC FFT size > 1024
>>
>> Hi,
>> I would like to implement an RFNoC FFT that can work for lengths > 1024.
>> Here's what I think I know:
>>
>>- Current size for CE-to-CE packets is restricted to 8000 bytes (2000
>>samples)
>>- Current RFNoC FFT size is tied to packet size and thus 1024 is the
>>max FFT size that can fit in a packet
>>
>> After reviewing previous posts and Xilinx FFT IP core documentation, it
>> seems that all I need to do is add packet resize logic at the input and
>> output of the block.  Specifically, I am thinking of using
>> "packet_resizer.v" at both input and output (but only modifying tuser in
>> the output instance).
>>
>> Questions
>>
>>- Is this a good approach?
>>- Anything special that I need to take care of?
>>- Does the selection of FFT architecture (pipelined, radix-4, etc)
>>have any relevance concerning this issue?
>>
>> Rob
>>
> ___
> 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] Passing arguments to an RFNOC block

[Jonathon Pendlum via USRP-users]

Hi Paul,

Your Nocscript has an error on line 47, you are a missing a comma:
LE($config 1) should be LE($config, 1). That may not be the source of your
issue, but try fixing that first.

Jonathon

On Thu, Feb 28, 2019 at 1:14 AM Paul Boven via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> As part of the VLBI[1] backend that I'm making in RFNOC, my first step
> is to make a rational resampler. It takes the 100MS/s signal from a
> TwinRX, and reduces it to 80MS/s. This can be done with a 5:4 resampler.
> In order to make this work, I'm using the axi_rate_change block.
>
> Although the block works in simulation, I keep running into problems
> with the GRC integration, in particular SWIG throwing run-time errors.
>
> The problem seems to be in the way that the arguments (N, M, config) are
> passed around, but studying other blocks like the DDC block hasn't
> provided the clues for me to get past this hurdle.
>
> The resampler itself does work, which I tested by having it emit zeroes
> instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC itself.
>
> At the moment, the block exits in VLBI_swig.py in set_arg:
> return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args)
> RuntimeError: SyntaxError: Parsing Stopped at: $N, 5)
>
> If you're familiar with RFNOC, can you please have a look at:
>
> http://www.jive.nl/~boven/rfnoc-VLBI
>
> It contains the source, and also a compiled bitfile for the X310 for
> your convenience (but use at your own risk, of course).
>
> Regards, Paul Boven.
>
> [1] Very Long Baseline Interferometry
>
> ___
> 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] USRP x310 with multi_usrp and RFNoC

[Jonathon Pendlum via USRP-users]

Hi Armin,

You can reset X3x0 series devices via a register write with the following
command (this is in to your UHD src directory):
firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
--data=1.

When you kill your app and resume, how long do you wait before restarting?
Can you try waiting a minute or two and see if that fixes the issue? If
that works, then it points to some internal buffering in the USRP not being
cleared before restarting streaming.

Jonathon

On Wed, Feb 20, 2019 at 6:27 PM Armin Schmidt via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hm, does someone know if it is possible somehow to reset the FPGA over a
> register? We see, that there exists a registers for resets of different
> modules (SR_SW_RST), but don't know, if we could use this over the API.
> Does somewhere exist a register-map? I think that should be the basis of
> every documentation.
>
> Would be quite sad, if Ettus don't prioritize the possible to use the
> hardware for real operation and not only for tinker-projects. We are
> operating at the moment three systems, each with five x310 and
> ubx-160-doughterboards and in the next several months/years it will be a
> lot more. So I hope Ettus will see this conversation and respond, otherwise
> we will be forced to move on to other vendors! The Ettus-support is quite
> painful and slow from my experiences and the documentation even worse!
>
> Am Di., 19. Feb. 2019 um 20:45 Uhr schrieb Brian Padalino <
> bpadal...@gmail.com>:
>
>> On Tue, Feb 19, 2019 at 12:07 PM Armin Schmidt  wrote:
>>
>>> Thanks for your replay! Hm, yes I've thought also about to use
>>> STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
>>> also after a crash. Ok, it should never happen, but one can never guarantee
>>> that case. Do you have an idea, how to deal with such cases? I think it's a
>>> bug in UHD, because in the version 3.9 was that never a problem.
>>>
>>
>> From my conversations with Ettus, getting the radios to a known good
>> state after a crash is not something they are prioritizing.
>>
>> My recommendation to you is that you reload the FPGA over JTAG every time
>> before starting your application such that it is always in a known
>> good/initial state.
>>
>> Brian
>>
>>> ___
> 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] E310 RFNoC FFT Overrun Issue

[Jonathon Pendlum via USRP-users]

Ramazan,

As Sylvain said, RFNoC Fosphor is another great choice. There already
exists flowgraphs in gr-ettus/examples/rfnoc for the E310 as well (see
rfnoc_fosphor_network_host.grc and rfnoc_fosphor_network_usrp.grc).

Jonathon

On Wed, Feb 20, 2019 at 12:22 AM Sylvain Munaut <246...@gmail.com> wrote:

> Just throwing it out there, but have you looked at rfnoc-fosphor ?
>
> I mean capturing and processing large bandwidth spectrum and
> decimating it to low bandwidth data is kind of exactly what it does.
>
> Cheers,
>
> Sylvain
>
> On Tue, Feb 19, 2019 at 4:19 PM Jonathon Pendlum via USRP-users
>  wrote:
> >
> > Hi Ramazan,
> >
> > The VectorIIR RFNoC block implements a vector of low pass single-pole
> IIR filters. The idea is that the spectral content of each FFT bin in the
> time direction is low frequency enough that you can low pass filter
> (VectorIIR) and decimate (Keep one in N) without significant loss of
> information.
> >
> > Jonathon
> >
> > On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
> >>
> >> Ramazan,
> >>
> >> The timeout channel 0 error is using a timeout that RFNoC is throwing.
> There is a timeout built in that can be ignored if you are purposely
> dropping a bunch of samples in the RFNoC domain (which I do in a few
> flowgraphs).  If you dig through the mailing list, someone pointed to where
> in the code this gets printed; they comment it out so they don't have to
> see it.  It is pretty annoying to me when I am trying to drop samples on
> purpose, but I haven't commented it out since I want to see it if I wasn't
> trying to drop samples.  My money is on your keep-1-in-n tripping this up.
> >>
> >>
> >>
> >>
> >>
> >> 
> >> From: USRP-users  on behalf of
> Ramazan Çetin via USRP-users 
> >> Sent: Tuesday, February 19, 2019 7:11 AM
> >> To: Jonathon Pendlum; usrp-users@lists.ettus.com
> >> Subject: Re: [USRP-users] E310 RFNoC FFT Overrun Issue
> >>
> >>
> >> Hi Jonathon,
> >>
> >> Thanks you for your suggestions. I have achieved getting 60 MHz
> spectrum samples to file on ARM processor using;
> >>
> >> RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N
> -> File Sink
> >>
> >> It just getting overflows after 4-5 seconds such as "overrun on chan
> 0". Is this because of RFNoC side or processor side ?
> >>
> >> Also, Keep 1 in B block works as using packets not samples this is also
> perfect for me. I will not lose FFT bins.
> >>
> >> But i can not much understand Vector IIR part. Why is it used and good
> for FFT outputs? Is it for averaging results ?
> >>
> >> Thank you for your time. Best regards.
> >>
> >> Ramazan
> >>
> >> On 11.02.2019 08:09, Jonathon Pendlum wrote:
> >>
> >> Hi Ramazan,
> >>
> >> I would suggest first testing with a signal generated with GNU Radio.
> For example, use a Fast Noise Source + Low Pass Filter to crudely simulate
> receiving a wide band signal. See what it looks like without running it
> through RFNoC. Then replace the RFNoC radio block with those blocks and
> look at the result.
> >>
> >> You should also consider using the ZeroMQ blocks to forward data over
> Ethernet to a host PC to view your data in real time. Look at the gr-ettus
> example flowgraphs rfnoc_fft_network_usrp (runs on E310) and
> rfnoc_fft_network_host (runs on host PC).
> >>
> >> One guess I can make is try increasing the FFT RFNoC block gain. By
> default, it is set to a very conservative value, so try changing it to 21.
> That gain value sets the Xilinx's FFT IP core scaling schedule, which you
> can read about here:
> https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf
> (see SCALE_SCH on page 15, the core uses Radix-4). You can also try
> adjusting it with a slider in real time. Note that it may behave a bit odd
> as it is not a linear mapping due to the scaling schedule format.
> >>
> >> The overflows are due to either the ARM processors cannot keep up with
> the processing load or the SD card write speed is too slow. Try increasing
> N in Keep One in N.
> >>
> >> Jonathon
> >>
> > ___
> > 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] E310 RFNoC FFT Overrun Issue

[Jonathon Pendlum via USRP-users]

Hi Ramazan,

The VectorIIR RFNoC block implements a vector of low pass single-pole IIR
filters. The idea is that the spectral content of each FFT bin in the time
direction is low frequency enough that you can low pass filter (VectorIIR)
and decimate (Keep one in N) without significant loss of information.

Jonathon

On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Ramazan,
>
> The timeout channel 0 error is using a timeout that RFNoC is throwing.
> There is a timeout built in that can be ignored if you are purposely
> dropping a bunch of samples in the RFNoC domain (which I do in a few
> flowgraphs).  If you dig through the mailing list, someone pointed to where
> in the code this gets printed; they comment it out so they don't have to
> see it.  It is pretty annoying to me when I am trying to drop samples on
> purpose, but I haven't commented it out since I want to see it if I wasn't
> trying to drop samples.  My money is on your keep-1-in-n tripping this up.
>
>
>
>
>
> --
> *From:* USRP-users  on behalf of
> Ramazan Çetin via USRP-users 
> *Sent:* Tuesday, February 19, 2019 7:11 AM
> *To:* Jonathon Pendlum; usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] E310 RFNoC FFT Overrun Issue
>
>
> Hi Jonathon,
>
> Thanks you for your suggestions. I have achieved getting 60 MHz spectrum
> samples to file on ARM processor using;
>
> RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N ->
> File Sink
>
> It just getting overflows after 4-5 seconds such as "*overrun on chan 0*".
> Is this because of *RFNoC* side or *processor* side ?
>
> Also, Keep 1 in B block works as using packets not samples this is also
> perfect for me. I will not lose FFT bins.
>
> But i can not much understand Vector IIR part. Why is it used and good for
> FFT outputs? Is it for averaging results ?
>
> Thank you for your time. Best regards.
>
> Ramazan
> On 11.02.2019 08:09, Jonathon Pendlum wrote:
>
> Hi Ramazan,
>
> I would suggest first testing with a signal generated with GNU Radio. For
> example, use a Fast Noise Source + Low Pass Filter to crudely simulate
> receiving a wide band signal. See what it looks like without running it
> through RFNoC. Then replace the RFNoC radio block with those blocks and
> look at the result.
>
> You should also consider using the ZeroMQ blocks to forward data over
> Ethernet to a host PC to view your data in real time. Look at the gr-ettus
> example flowgraphs rfnoc_fft_network_usrp (runs on E310) and
> rfnoc_fft_network_host (runs on host PC).
>
> One guess I can make is try increasing the FFT RFNoC block gain. By
> default, it is set to a very conservative value, so try changing it to 21.
> That gain value sets the Xilinx's FFT IP core scaling schedule, which you
> can read about here:
> https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf
> (see SCALE_SCH on page 15, the core uses Radix-4). You can also try
> adjusting it with a slider in real time. Note that it may behave a bit odd
> as it is not a linear mapping due to the scaling schedule format.
>
> The overflows are due to either the ARM processors cannot keep up with the
> processing load or the SD card write speed is too slow. Try increasing N in
> Keep One in N.
>
> Jonathon
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 RFNoC FFT Overrun Issue

[Jonathon Pendlum via USRP-users]

Hi Ramazan,

I would suggest first testing with a signal generated with GNU Radio. For
example, use a Fast Noise Source + Low Pass Filter to crudely simulate
receiving a wide band signal. See what it looks like without running it
through RFNoC. Then replace the RFNoC radio block with those blocks and
look at the result.

You should also consider using the ZeroMQ blocks to forward data over
Ethernet to a host PC to view your data in real time. Look at the gr-ettus
example flowgraphs rfnoc_fft_network_usrp (runs on E310) and
rfnoc_fft_network_host (runs on host PC).

One guess I can make is try increasing the FFT RFNoC block gain. By
default, it is set to a very conservative value, so try changing it to 21.
That gain value sets the Xilinx's FFT IP core scaling schedule, which you
can read about here:
https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf
(see SCALE_SCH on page 15, the core uses Radix-4). You can also try
adjusting it with a slider in real time. Note that it may behave a bit odd
as it is not a linear mapping due to the scaling schedule format.

The overflows are due to either the ARM processors cannot keep up with the
processing load or the SD card write speed is too slow. Try increasing N in
Keep One in N.

Jonathon

On Mon, Feb 11, 2019 at 5:51 AM Ramazan Çetin 
wrote:

> Hi Jonathon,
>
> I fixed the RFNOC: Vector IIR issue with changing its coefficients. Now i
> can get samples using Vector IIR and keep 1 in N. I just tried to get Wifi
> samples using this;
>
> RFNOC: radio(56Mhz) -> RFNOC: FFT -> RFNOC: Vector_iir -> RFNOC: keep 1 in
> N(N = 14) -> FileSink
>
> I am receiving samples from CPU as 4M. But i am sampling signal with 56Mhz
> and decimate it after FFT. So, i should get 56Mhz bandwidth signal. But
> when i look my signal on CPU, it looks small bandwidth. Wifi is 20 or 40MHz
> bandwidth so i should see some gap on frequency axis, but i cannot. I have
> attached my flowgraph and wifi spectrogram.
>
> Q1. Is it related with keep 1 in N? Is it keeping first N samples from FFT
> bins? or i am missing something else. Is it possible to see 56 MHz
> bandwidth signal on host?
>
> Q2. I am getting "Ooverrun on chan 0" after 3 or 4 seconds. Is it CPU's
> capacity for processing? After some time it cannot catch that speed. Maybe
> i need some FIFO. Is it right?
>
> Thank you so much for your answers. Best regards.
>
> Ramazan
> On 10.02.2019 15:54, Ramazan Çetin wrote:
>
> Hi Jonathon,
>
> Thank you for your reply. I just tried what you said and investigated
> gr-ettus/examples/rfnoc/rfnoc_vector_iir.grc. I firstly tried without using
> keep 1 in N block. I just sampled 2MHz and try to get FM radio samples of
> spectrum. My flowgraph is attached.
>
> My problem is when i used RFNOC: radio -> RFNOC: FFT -> VecToStr ->
> IIR_filter(not RFNOC) -> StrToVect -> CompToMag -> Log10 -> FileSink
>
> with same coefficients it is working good. I can get spectrum samples.
>
> But when i use RFNOC: radio -> RFNOC: FFT -> RFNOC: Vector_iir ->
> CompToMag -> Log10 -> FileSink
>
> it gives all zeros after its output. Coefficients are same. I just changed
> IIR filter with RFNOC Vector IIR. Do you know why it is happening?
>
> Best regards.
> On 10.02.2019 10:21, Jonathon Pendlum wrote:
>
> Hi Ramazan,
>
> Q1. So, do you know any method to minimize signal distortion while
>> downsampling in frequency domain? or How can i get wifi signal frequency
>> spectrum in E310 ?
>>
>
> You want to filter the vector of FFT bins individually, which is not what
> the DDC block is designed to do. Instead, you should use the VectorIIR and
> Keep 1 in N RFNoC blocks in this configuration: RFNoC Radio -> RFNoC FFT ->
> RFNoC VectorIIR -> RFNoC Keep 1 in N -> Host. For an example, look at the
> gr-ettus flowgraph in gr-ettus/examples/rfnoc/rfnoc_vector_iir.grc.
>
>
>> Q2. When i try compiling FPGA image with 4 blocks, it gives "Placer
>> could not place all instances" error. But in guide, it says user can put
>> up to 6 blocks. Why it give that error after 3 blocks?
>>
>
> The FPGA fabric has a finite amount of resources (LUTs, Registers, BRAMs,
> DSP48s) and your configuration required more resources than available. The
> 6 block limit is more of a rule of thumb, especially when using small
> blocks like the RFNoC FIFO blocks. You can certainly use up all the FPGA
> resources with less than 6 RFNoC blocks. In your case, a build with just
> the FFT, VectorIIR, and Keep One in N RFNoC blocks should fit.
>
> Jonathon
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 RFNoC FFT Overrun Issue

[Jonathon Pendlum via USRP-users]

Hi Ramazan,

Q1. So, do you know any method to minimize signal distortion while
> downsampling in frequency domain? or How can i get wifi signal frequency
> spectrum in E310 ?
>

You want to filter the vector of FFT bins individually, which is not what
the DDC block is designed to do. Instead, you should use the VectorIIR and
Keep 1 in N RFNoC blocks in this configuration: RFNoC Radio -> RFNoC FFT ->
RFNoC VectorIIR -> RFNoC Keep 1 in N -> Host. For an example, look at the
gr-ettus flowgraph in gr-ettus/examples/rfnoc/rfnoc_vector_iir.grc.


> Q2. When i try compiling FPGA image with 4 blocks, it gives "Placer
> could not place all instances" error. But in guide, it says user can put
> up to 6 blocks. Why it give that error after 3 blocks?
>

The FPGA fabric has a finite amount of resources (LUTs, Registers, BRAMs,
DSP48s) and your configuration required more resources than available. The
6 block limit is more of a rule of thumb, especially when using small
blocks like the RFNoC FIFO blocks. You can certainly use up all the FPGA
resources with less than 6 RFNoC blocks. In your case, a build with just
the FFT, VectorIIR, and Keep One in N RFNoC blocks should fit.

Jonathon
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP X310 uhd 4.0 fpga rfnoc img download

[Jonathon Pendlum via USRP-users]

Hi Paul,

The rfnoc-devel branch is deprecated. You should build off the master
branch or UHD-3.13 branch with the cmake flag "-DENABLE_RFNOC=ON". You can
then use uhd_image_downloader. The image package only includes images with
the default RFNoC blocks. For the X310, the default image has two DDC and
two DUC RFNoC blocks. You'll need to build a custom image if you want to
use other blocks.

Jonathon

On Tue, Feb 5, 2019 at 8:35 AM Paul Marian Stoica via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I succesfully installed UHD 4.0.0.rfnoc-devel-702-geec24d7b from source on
> Ubuntu 16.04 and when I launched uhd_images_downloader it doesn't download
> the rfnoc images.
>
> In /usr/local/share/uhd/images I can only see regular images, nothing with
> RFNOC in it's name. Is there somewhere else where I can download the rfnoc
> images for X310?
>
> Thank you!
>
> ___
> 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] NOC Shell config ports

[Jonathon Pendlum via USRP-users]

Hi Samuel,

1) Block ports are considered independent of each other. That is why each
one has dedicated sink/source sample streams, settings register bus, noc
shell registers, etc.
2) Set INPUT_PORTS and OUTPUT_PORTS to the number of each you want (up to
16 per direction). See noc_block_ddc.v and noc_block_duc.v for examples on
using a parameterized number of block ports.
3) Take a look at the RFNoC Getting Started Guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_Development) and the RFNoC
Virginia Tech video starting at 01:05:00 (
https://www.youtube.com/watch?v=8cPd3t88djE).

Jonathon

On Sat, Feb 9, 2019 at 12:06 AM Kranz Samuel Josef via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey
>
>
>
> The last few days I was working on a multi-port rfnoc block (2 inputs, 2
> outputs). By analyzing the ADD/SUB (noc_block_addsub.v) and the NOC Shell
> modules, I understood how packet handling works.
>
> However, I’m not quite sure why the control ports (especially the control
> sink – set_data, set_addr, … ) also scale with the number of BLOCK_PORTS
> (noc_shell).
>
> To my understanding parameters configured in gr are provided through
> these.
>
>
>
> So I came up with these questions.
>
> 1)  Why does every stream has their own set of signals?
>
> 2)  How are these ports properly used in multi stream blocks?
>
> 3)  Is there any useful information (documentation, code file) which
> explains the functionality of these ports?
>
>
>
> Thanks in advance.
>
>
>
> Samuel
> ___
> 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] X310 LookupError CORDIC_FREQ

[Jonathon Pendlum via USRP-users]

Hi Alex,

It looks like your DDC / DUC block controller XML file is from a newer
version of UHD. I would suggest checking that your UHD source does not have
any changes, especially ddc.xml and duc.xml. You should also uninstall UHD
and do a new build: (from the build dir) 'make uninstall; make clean; make
install'.

Jonathon

On Wed, Feb 6, 2019 at 6:46 AM Alexander Olihovik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm getting the following LookupError after making/installing
> UHD_003.010.003 and building/writing the bitstream for the X310_HG project:
> -
> linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_003.010.003.HEAD-0-gef157678
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929a
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1305.3MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1305.2MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> Error: LookupError: KeyError: Unknown settings register name: CORDIC_FREQ
> -
>
> I also get the same results when attempting the following:
> uhd_images_downloader
> uhd_image_loader --args type=x300,add=192.168.10.2
> Powercycled the X310
> uhd_usrp_probe
>
>
> Is there a solution to this? Did I miss something when building UHD or the
> bitstream?
>
>
> Best,
> Alex
> ___
> 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