[USRP-users] IOError: x300 fw poke32 - reply timed out

[Stefan van der Linden via USRP-users]

Hi,

We are in the process of prototyping a setup using an X300 with two 
UBX-40 daughterboards to be used in the validation of an externally 
provided signal source. The daughterboards are each dedicated to one of 
two tasks: transmitting a pre-recorded reference signal in a loop at 50 
MSps, and capturing that same signal again after passing through a chain 
of devices under test at 25MSps. This is to run continuously up to 24 hours.


The X300 is connected to the (dedicated) host computer via a 10Gbps 
connection to an Intel X520-DA2 NAC over SFP+. On the host, we are 
currently using the /kitchen_sink/ utility included with UHD to run the 
system in multi-channel mode. We are using UHD 3.11.0.1.


The system works flawlessly when performing short measurements (say, up 
to an hour or so). However, having recently started setting up the 
system for long 24 hour tests, we are seeing timeouts from which UHD is 
unable to recover. These timeouts occur randomly: sometimes they occur 
after ~1 hours, other times they occur after ~18 hours and everywhere in 
between. Naturally, this random behaviour makes it difficult to debug.


The error message retrieved from UHD is as follows:

[ERROR] [X300] 192.168.50.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
UUU[ERROR] [UHD] An unexpected exception was caught in a task loop.The task 
loop will now exit, things may not work.AssertionError: reply.sequence == 
request.sequence
 in virtual void x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, 
uint32_t)
 at /usr/uhd/uhd-release_003_011_000_001/host/lib/usrp/x300/x300_fw_ctrl.cpp:134

[ERROR] [X300] 192.168.50.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw peek32 - reply timed out
[ERROR] [X300] 192.168.50.2: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw peek32 - reply timed out
UDOterminate 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 /usr/uhd/uhd-release_003_011_000_001/host/lib/usrp/x300/x300_fw_ctrl.cpp:163

As previous messages on this list have mentioned varying the MTU 
settings (for example: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html), 
this was the first thing we tried. Unfortunately, these timeouts occur 
more often at lower MTU values.


Hopefully someone is able to point us in the right direction. Perhaps we 
are dealing with hardware issues here, but I'd I hope we are able to 
solve this through software.


Thanks,
Stefan van der Linden
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IOError: x300 fw poke32 - reply timed out

[Marcus Müller via USRP-users]

Hi Stefan,

I know it's not of great comfort when an engineer finds a problem to be
/interesting/, but yours certainly is.
So, first things first: if the computational power and memory of the
host that your USRP is connected to allows, it might be good to have a
packet capture in some kind of a ring buffer, so that you can infer a
bit on the state at the point where things go wrong:

tcpdump -n # no DNS lookups 
-i  
-s 0 # don't stop after a finite amount of packets
-C 400 # 400 million bytes per capture file
-W 2 # rotate through three files of capturs
-w /tmp/rotate.pcap # make sure that you're using a file that's on an
RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs /path`

So, yes, using an MTU of 8000 would be the first thing that the Ettus
hivemind would recommend, too, but if you say things still go wrong, we
might need to dig deeper.

I do know that we've improved the bus clocking, and that had impact on
the X300 firmware. Is trying the last 3.10 release an option for you?

Best regards,
Marcus

On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-users 
wrote:
> Hi,
> 
> We are in the process of prototyping a setup using an X300 with two
> UBX-40 daughterboards to be used in the validation of an externally
> provided signal source. The daughterboards are each dedicated to one
> of two tasks: transmitting a pre-recorded reference signal in a loop
> at 50 MSps, and capturing that same signal again after passing
> through a chain of devices under test at 25MSps. This is to run
> continuously up to 24 hours.
> 
> The X300 is connected to the (dedicated) host computer via a 10Gbps
> connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
> currently using the kitchen_sink utility included with UHD to run the
> system in multi-channel mode. We are using UHD 3.11.0.1.
> 
> The system works flawlessly when performing short measurements (say,
> up to an hour or so). However, having recently started setting up the
> system for long 24 hour tests, we are seeing timeouts from which UHD
> is unable to recover. These timeouts occur randomly: sometimes they
> occur after ~1 hours, other times they occur after ~18 hours and
> everywhere in between. Naturally, this random behaviour makes it
> difficult to debug.
> 
> The error message retrieved from UHD is as follows:
> 
> As previous messages on this list have mentioned varying the MTU
> settings (for example: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
> ), this was the first thing we tried. Unfortunately, these timeouts
> occur more often at lower MTU values.
> 
> Hopefully someone is able to point us in the right direction. Perhaps
> we are dealing with hardware issues here, but I'd I hope we are able
> to solve this through software.
> 
> Thanks,
> Stefan van der Linden
> ___
> 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 E313 | WBFM Issues

[Marcus Müller via USRP-users]

Hi Ryan,

hm, there's honestly quite a few things that can simply go wrong on a
demodulation/DSP/signal side of things without nothing misbehaving or
you doing any mistakes. Your single-tone test hence was very clever to
do!

So, my recommendation is this:
First of all, verify that the reception strength / SNR is actually
reasonably good. You said you saw the signal in a frequency plot – so
how many dB were between signal and noise floor? If it's worse than
let's say 20 dB, you might need more RX gain or a better antenna (FM in
cities typically is pretty strong).

If that is fine, *make a raw recording* (using either GNU Radio with a
file sink directly attached through a head block to the USRP source, or
with the rx_samples_to_file tool) of a few seconds worth of samples,
and try to demodulate them on your PC – if that doesn't work, we know
there's something else to fix.

Best regards,
Marcus
  
On Fri, 2018-09-21 at 15:28 -0400, Ryan Campiz via USRP-users wrote:
> 
> Ryan Campiz  
> Thu, Sep 20, 5:21 PM (21 hours ago)
> 
> to support 
> Greetings,
> 
> I'm having trouble with a basic Wide-Band FM (WBFM) demodulation
> tutorial. I am using the Ettus USRP E313. The Ettus USRP E313 is
> basically an enclosure with an Ettus E310 and Power/Ethernet PCB with
> the RF, DC Power, Ethernet, and USB ports.
> 
> FM DEMODULATION TUTORIAL
> In my application, as the host machine, I am using a Virtual Machine
> with Ubuntu 16.04 (64-bit). I downloaded all of the software as
> instructed in the AN-445 Ettus Application Note.
> 
> In my application, the tutorial that I am following is from the AN-
> 335 Application Note from Ettus. The tutorial is not complicated. I
> downloaded the Flowgraph files that the tutorial comes with. When I
> generate both python files and run them respectively on the E310 and
> the Host Machine, all I hear is static. I can see evidence of a
> received signal on the Frequency Spectrum graph, but I only hear
> static. What’s more, as I vary the radio frequency, I do see the
> Frequency Spectrum graph change, but I see no evidence of any FM
> Radio Stations.
> 
> DETOUR: DEMONSTRATING I COULD AT LEAST HEAR A 1KHZ TONE FROM THE E310
> Just to make sure that it was possible to hear anything from the
> E310, I created a simple flowgraph for the E310. All it did was
> generate a Signal Source: a tone of 1kHz. On the other end, with the
> VM, I had an Audio Sink and a Time Graph and Waterfall Diagram. I was
> able to hear the tune. But it was choppy. And there was latency with
> the controls. A system block diagram of this set-up can be seen
> below. 
> 
> 
> LAST EFFORTS AND SPECULATION
> After demonstrating that I could hear at least a tone, I moved back
> to the FM Demodulation Tutorial. I tried for a day to get it to run.
> After no success, I used other resources to try to find where the
> process could be going wrong. Once such resource is the YouTube video
> "How To Build an FM Receiver with the USRP in Less Than 10 Minutes".
> That YouTube video is made by Ettus Research.  It was well-produced
> and easy to follow. However, even after watching it several times I
> could not locate what could be going wrong in the RF Demodulation
> flowgraph.
> 
> I am so uncertain at this point that I am starting to wonder if
> either:
> 
> A.  the RF Front End is not working, or
> B.  the OS image on the Ettus E310 is very slightly corrupted, or
> C.  the FPGA is not programmed (built?) correctly.
> 
> What could be going wrong?
> 
> 
> 
> 
> 
> Ryan Campiz
> Electrical/RF Engineer
> AREA-I
> where ideas take flight
> 
> 1590 N. Roberts Rd., Ste 102
> Kennesaw, GA 30144
> 1590 N. Roberts Rd., Ste 102
> Kennesaw, GA 30144
> Direct: 470-481-4054
> Fax: 678-594-5228
> 
> PROPRIETARY AND CONFIDENTIAL: This message, including any attachment,
> is confidential information of Area-I, Inc. This message may contain
> information that is privileged and exempt from disclosure under
> applicable law and is intended only for the individual or entity to
> which it is addressed. If the reader of this message is not the
> intended recipient, or the employee or agent responsible for
> delivering the message to the intended recipient, you are notified
> that any use, dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please contact the sender immediately by e-
> mail and destroy all copies of the original message and any
> attachment.
> INTERNATIONAL TRAFFIC IN ARMS REGULATIONS (ITAR) NOTICE: Any
> drawings, specifications, or other proprietary data contained within,
> or associated with this correspondence, or any subsequent
> correspondence including, but not limited to U.S. Post, faxes, etc.,
> are considered controlled data. As such, this data/information is
> subject to U.S. Export Control under the Department of State,
> International Traffic in Arms Regulation (ITAR). These
> drawings/specifications may not be exported o

[USRP-users] How to transmit different signals simultaneously?

[ge wang via USRP-users]

Hi,

I write to ask some questions about USRP X310. I use two SBX daughter
boards, but I do not know how to control them separately. For example, how
to let them transmit different signals simultaneously?  Is there any
published project that I can learn from?

Best regard!

Ge
-- 
Ge Wang
Ph.D Candidate of Xi'an Jiaotong University
Visiting student at University of California, Santa Cruz
___
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 transmit different signals simultaneously?

[Marcus Müller via USRP-users]

Hi Ge,

so, the UHD API lets you define streamers with multiple channels. Then
it's just a matter of calling send() with a list of multiple buffers to
be sent.

But: if you're new to all this, or want to use GNU Radio anyways, or
rather build DSP than writing driver interfacing C++ code:
GNU Radio's USRP sink can be set to two channels and will give you
exactly the ability you want: to stream two different signals to the
device.

If you want to learn about GNU Radio, the tutorials are pretty
certainly the way to go:

https://tutorials.gnuradio.org

Best regards,
Marcus

On Mon, 2018-09-24 at 11:29 -0700, ge wang via USRP-users wrote:
> Hi,
> 
> I write to ask some questions about USRP X310. I use two SBX daughter
> boards, but I do not know how to control them separately. For
> example, how to let them transmit different signals simultaneously? 
> Is there any published project that I can learn from? 
> 
> Best regard!
> 
> Ge
> -- 
> Ge Wang
> Ph.D Candidate of Xi'an Jiaotong University
> Visiting student at University of California, Santa Cruz
> ___
> 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] PCIe driver frame size

[Marcus Müller via USRP-users]

Hi Eugene,

I'm not an expert on the PCIe transport, but as far as I can tell from
3.11.0.1's

uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport

the PCIe frame sizes seem to be immutable (4 kB, in fact, which,
subtracting header and dividing by sample bitwidth, leads to 1020
samples per frame).

Best regards,
Marcus

On Fri, 2018-09-21 at 18:32 +, Eugene Grayver via USRP-users wrote:
> Is there  a way to specify the frame size on the PCIe interface?  I
> tried using the same keywords as for the NIC, but it had no effect. 
> I need low-latency and the default frame size is 5000 bytes (much too
> large for my needs).
>  
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Eng.
> Tel: 310.336.1274
> 
>  
> ___
> 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] general RFNoC timing question

[Jason Matusiak via USRP-users]

I have a flowgraph I am running on an E310 using all stock RFNoC blocks.  It 
looks a lot like this:
 
 
RFNoC:Radio ---> RFNoC: Split Stream ---> RFNoC: FFT ---> RFNoC: Keep 1 in N 
---> RFNoC: Log Power > GR: complex to float  ---> GR:Raster Sink
  |
  |
  ---> 
RFNOC: Keep 1 in N ---> GR: log Power FFT ---> GR: custom block ---> GR: Raster 
sink
 
So no DDC in the flowgraph.  If I run the master_clock_rate at 56MHz, the 
sample rate should be the same (I have SPP=512, and that is the size of the FFT 
as well).  I would then think that the pair of Keep 1 in Ns should basically 
divide down the rate by N.  So if I have them set to 56e3, that means I should 
get a sample rate that averages out to be 1KHz out each of the two streams to 
host for a total of 2KHz.  I know that the E310 can stream 10MHz no problem to 
the ARM, so I am not sure why in this scenario I get a ton of:

 Ooverrun on chan 0
Ooverrun on chan 0
Ooverrun on chan 0
Ooverrun on chan 0
Ooverrun on chan 0
Ooverrun on chan 0
Ooverrun on chan 0
 Now why would that be?  I have no idea.
  
 I set my downstream sample rate (on the GR host) to be sample_rate/keep1inN.  
I bring this up because in the case about sample_rate is the same as 
master_clock_rate.  If I reduce the sample_rate to be 40MHz (which gets ignored 
by the E310 since I don't have a DDC, but gets used in the down stream sample 
rate for the raster guis, I can set the keep1inN up to the max of 65535 and 
there are no overflows.  There are "timeout on chan 0" errors, but I think that 
is because RFNoC must be timing out somewhere du to the throughput being so 
slow.
 Does this make sense?  Does anyone have an idea what I am doing stupidly 
wrong?  I have a feeling I am violating timing somewhere, but I can't figure 
out where
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] DMA FIFO Resizing

[Brian Padalino via USRP-users]

I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
installation of UHD as of current master:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt

It seems like this is just a simple oversight, so I modified it locally.
I've been running doing some latency experiments and modifying the size of
the DMA FIFO using the resize() method:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65

And it seems there's a bit of a restriction on the sizing associated with
the FIFO:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263

I see it currently says that the FIFO needs to be >8k, and it has to be a
power of 2.  If either of those criteria fails, an exception is thrown.

A few requests:

(1) Can you not throw an exception, but print a warning and resolve the
criteria?  For example, if I ask for < 8k, up it to 8k and print a warning
it's been upped.  If I ask for a non-power of 2, can you print a warning
and up to to the next supported power of 2?  Think of this like a request
for a sample rate - if you can't get the exact one, you get what's close
and the user can query the actual value?

(2) Speaking of powers of 2, why is this a requirement?  Can it be any
value that is a multiple of a 4k page boundary?  Is there something inside
the FPGA logic that doesn't allow this to happen?  Powers of 2 can be a
large buffer size changes.

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

Re: [USRP-users] PCIe driver frame size

[Eugene Grayver via USRP-users]

Yep, that's what seems to be the case.  The whole point of PCIe is lower 
latency -- with a frame size that large I can get lower latency w/ 10 GbE and 
500B frame size.  I can't imagine it is a large effort to get that fixed :)


___
Eugene Grayver, Ph.D.
Aerospace Corp., Principal Eng.
Tel: 310.336.1274


-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Monday, September 24, 2018 11:41 AM
To: Eugene Grayver ; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] PCIe driver frame size

Hi Eugene,

I'm not an expert on the PCIe transport, but as far as I can tell from 
3.11.0.1's

uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport

the PCIe frame sizes seem to be immutable (4 kB, in fact, which, subtracting 
header and dividing by sample bitwidth, leads to 1020 samples per frame).

Best regards,
Marcus

On Fri, 2018-09-21 at 18:32 +, Eugene Grayver via USRP-users wrote:
> Is there  a way to specify the frame size on the PCIe interface?  I 
> tried using the same keywords as for the NIC, but it had no effect.
> I need low-latency and the default frame size is 5000 bytes (much too 
> large for my needs).
>  
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Eng.
> Tel: 310.336.1274
> 
>  
> ___
> 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] IOError: x300 fw poke32 - reply timed out

[Marcus Müller via USRP-users]

Hi Stefan,

so I've talked to our main software sustainance hero, and we rather
quickly came to the conclusion that it's pretty likely you should move
on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you
building from source, or are you using binary packages?

Best regards,
Marcus

On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:
> Hi Stefan,
> 
> I know it's not of great comfort when an engineer finds a problem to
> be
> /interesting/, but yours certainly is.
> So, first things first: if the computational power and memory of the
> host that your USRP is connected to allows, it might be good to have
> a
> packet capture in some kind of a ring buffer, so that you can infer a
> bit on the state at the point where things go wrong:
> 
> tcpdump -n # no DNS lookups 
> -i  
> -s 0 # don't stop after a finite amount of packets
> -C 400 # 400 million bytes per capture file
> -W 2 # rotate through three files of capturs
> -w /tmp/rotate.pcap # make sure that you're using a file that's on an
> RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs
> /path`
> 
> So, yes, using an MTU of 8000 would be the first thing that the Ettus
> hivemind would recommend, too, but if you say things still go wrong,
> we
> might need to dig deeper.
> 
> I do know that we've improved the bus clocking, and that had impact
> on
> the X300 firmware. Is trying the last 3.10 release an option for you?
> 
> Best regards,
> Marcus
> 
> On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-
> users 
> wrote:
> > Hi,
> > 
> > We are in the process of prototyping a setup using an X300 with two
> > UBX-40 daughterboards to be used in the validation of an externally
> > provided signal source. The daughterboards are each dedicated to
> > one
> > of two tasks: transmitting a pre-recorded reference signal in a
> > loop
> > at 50 MSps, and capturing that same signal again after passing
> > through a chain of devices under test at 25MSps. This is to run
> > continuously up to 24 hours.
> > 
> > The X300 is connected to the (dedicated) host computer via a 10Gbps
> > connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
> > currently using the kitchen_sink utility included with UHD to run
> > the
> > system in multi-channel mode. We are using UHD 3.11.0.1.
> > 
> > The system works flawlessly when performing short measurements
> > (say,
> > up to an hour or so). However, having recently started setting up
> > the
> > system for long 24 hour tests, we are seeing timeouts from which
> > UHD
> > is unable to recover. These timeouts occur randomly: sometimes they
> > occur after ~1 hours, other times they occur after ~18 hours and
> > everywhere in between. Naturally, this random behaviour makes it
> > difficult to debug.
> > 
> > The error message retrieved from UHD is as follows:
> > 
> > As previous messages on this list have mentioned varying the MTU
> > settings (for example: 
> > 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
> > ), this was the first thing we tried. Unfortunately, these timeouts
> > occur more often at lower MTU values.
> > 
> > Hopefully someone is able to point us in the right direction.
> > Perhaps
> > we are dealing with hardware issues here, but I'd I hope we are
> > able
> > to solve this through software.
> > 
> > Thanks,
> > Stefan van der Linden
> > ___
> > 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] PCIe driver frame size

[Marcus Müller via USRP-users]

Well, there *is* a bit of history on these package sizes. Now, having
had frequent communication with you: 4kB is an effect of system page
sizes. For more detail, see x300_impl.hpp's comments on
X300_PCIE_RX_DATA_FRAME_SIZE. But: you're right, this is a communicated
transport property, but since you basically know what you're doing (and
know what to revert when things break), go ahead and modify things
within the limits of what's stated in said comment.

Best regards,
Marcus

On Mon, 2018-09-24 at 20:20 +, Eugene Grayver wrote:
> Yep, that's what seems to be the case.  The whole point of PCIe is
> lower latency -- with a frame size that large I can get lower latency
> w/ 10 GbE and 500B frame size.  I can't imagine it is a large effort
> to get that fixed :)
> 
> 
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Eng.
> Tel: 310.336.1274
> 
> 
> -Original Message-
> From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
> Sent: Monday, September 24, 2018 11:41 AM
> To: Eugene Grayver ; 
> usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] PCIe driver frame size
> 
> Hi Eugene,
> 
> I'm not an expert on the PCIe transport, but as far as I can tell
> from 3.11.0.1's
> 
> uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport
> 
> the PCIe frame sizes seem to be immutable (4 kB, in fact, which,
> subtracting header and dividing by sample bitwidth, leads to 1020
> samples per frame).
> 
> Best regards,
> Marcus
> 
> On Fri, 2018-09-21 at 18:32 +, Eugene Grayver via USRP-users
> wrote:
> > Is there  a way to specify the frame size on the PCIe
> > interface?  I 
> > tried using the same keywords as for the NIC, but it had no effect.
> > I need low-latency and the default frame size is 5000 bytes (much
> > too 
> > large for my needs).
> >  
> > ___
> > Eugene Grayver, Ph.D.
> > Aerospace Corp., Principal Eng.
> > Tel: 310.336.1274
> > 
> >  
> > ___
> > 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] DMA FIFO Resizing

[Marcus Müller via USRP-users]

Hi Brian,

thanks! Quick update first: raised the CMakeLists omission internally,
should be fixed soon, far as I can tell.

Best regards,
Marcus
On Mon, 2018-09-24 at 14:52 -0400, Brian Padalino via USRP-users wrote:
> I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
> installation of UHD as of current master:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt
> 
> It seems like this is just a simple oversight, so I modified it
> locally.  I've been running doing some latency experiments and
> modifying the size of the DMA FIFO using the resize() method:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65
> 
> And it seems there's a bit of a restriction on the sizing associated
> with the FIFO:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263
> 
> I see it currently says that the FIFO needs to be >8k, and it has to
> be a power of 2.  If either of those criteria fails, an exception is
> thrown.
> 
> A few requests:
> 
> (1) Can you not throw an exception, but print a warning and resolve
> the criteria?  For example, if I ask for < 8k, up it to 8k and print
> a warning it's been upped.  If I ask for a non-power of 2, can you
> print a warning and up to to the next supported power of 2?  Think of
> this like a request for a sample rate - if you can't get the exact
> one, you get what's close and the user can query the actual value?
> 
> (2) Speaking of powers of 2, why is this a requirement?  Can it be
> any value that is a multiple of a 4k page boundary?  Is there
> something inside the FPGA logic that doesn't allow this to happen? 
> Powers of 2 can be a large buffer size changes.
> 
> Thanks,
> 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] DMA FIFO Resizing

[Marcus Müller via USRP-users]

Hello Brian,

so, the power-of-two FIFO sizes pretty much happen because you can only
divide addresses by full bit prefixes. That seems to be reflected in
noc_shell.v; not quite sure how deep the changes would have to go to
get rid of that restriction.

Best regards,
Marcus

On Mon, 2018-09-24 at 14:52 -0400, Brian Padalino via USRP-users wrote:
> I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
> installation of UHD as of current master:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt
> 
> It seems like this is just a simple oversight, so I modified it
> locally.  I've been running doing some latency experiments and
> modifying the size of the DMA FIFO using the resize() method:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65
> 
> And it seems there's a bit of a restriction on the sizing associated
> with the FIFO:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263
> 
> I see it currently says that the FIFO needs to be >8k, and it has to
> be a power of 2.  If either of those criteria fails, an exception is
> thrown.
> 
> A few requests:
> 
> (1) Can you not throw an exception, but print a warning and resolve
> the criteria?  For example, if I ask for < 8k, up it to 8k and print
> a warning it's been upped.  If I ask for a non-power of 2, can you
> print a warning and up to to the next supported power of 2?  Think of
> this like a request for a sample rate - if you can't get the exact
> one, you get what's close and the user can query the actual value?
> 
> (2) Speaking of powers of 2, why is this a requirement?  Can it be
> any value that is a multiple of a 4k page boundary?  Is there
> something inside the FPGA logic that doesn't allow this to happen? 
> Powers of 2 can be a large buffer size changes.
> 
> Thanks,
> 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

[USRP-users] Can't find a block controller for key FFT, using default block controller!

[Rich Maes via USRP-users]

Re-pining this question   

> On Sep 2, 2018, at 10:48 PM, Rich Maes  wrote:
> 
> I am running a cross-compiled UHD environment on a E310.  I have a couple 
> warning that appear when I am running my uhd_usrp_probe with a custom FPGA 
> image.  The image I have created has 2 FFT’s and 2 Windows in it.  The 
> warning indicate that the controller blocks cannot be found for the FFT’s. 
> 
> Later, at the bottom of the run, I get some errors like the following
> [ERROR] [UHD] Exception caught in safe-call.
> 
> I would like to confirm that the lack of a controller for the FFT is a real 
> problem that needs to be resolved. 
>  
> Relative to the exceptions at the end, I have read that although this is an 
> error, it does not prevent running applications
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/051914.html
>  
> 
> 
> 
> 
> root@ettus-e3xx-sg3:~/localinstall/usr/share/uhd/images# uhd_usrp_probe 
> --args='fpga=usrp_e310_fpga_RFNOC_sg3.bit' 
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; 
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
> 
> [INFO] [E300] Performing register loopback test... 
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053)
> [INFO] [0/Window_1] Initializing block control (NOC ID: 0xD053)
> [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)
> [WARNING] [RFNOC] Can't find a block controller for key FFT, using default 
> block controller!
> [INFO] [0/FFT_1] Initializing block control (NOC ID: 0xFF70)
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX SG3
> |   |   product: 30675
> |   |   revision: 7
> |   |   serial: 3150D1D
> |   |   mac-addr: 00:80:2f:19:10:70
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: 1b40696-dirty
> |   |   RFNoC capable: Yes
> |   |   
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 314E574
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |   
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX DSP: 1
> |   |   |   
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 314E574
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: A
> |   |   |   |   Name: FE-TX2
> |   |   |   |   Antennas: TX/RX
> |   |   |   |   Sensors: 

Re: [USRP-users] DMA FIFO Resizing

[Brian Padalino via USRP-users]

Hey Marcus,

On Mon, Sep 24, 2018 at 5:22 PM Marcus Müller 
wrote:

> Hello Brian,
>
> so, the power-of-two FIFO sizes pretty much happen because you can only
> divide addresses by full bit prefixes. That seems to be reflected in
> noc_shell.v; not quite sure how deep the changes would have to go to
> get rid of that restriction.
>

Can you point me to the appropriate lines of code for this restriction?

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

Re: [USRP-users] Can't find a block controller for key FFT, using default block controller!

[EJ Kreinar via USRP-users]

Hi Rich,

This all looks OK to me.

1) the block controller warning just indicates there's no *custom* block
controller for a particular block. By default the XML noc block definition
will typically populate read/write registers in a default block controller
just fine.

2) the errors at the end are expected for the e310, as you have indicated.
I've suppressed these myself; perhaps I'll write this up and provide an out
of tree fix for those of us who dont want to always see the errors output
to console.

EJ

On Mon, Sep 24, 2018, 5:35 PM Rich Maes via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Re-pining this question
>
> On Sep 2, 2018, at 10:48 PM, Rich Maes  wrote:
>
> I am running a cross-compiled UHD environment on a E310.  I have a couple
> warning that appear when I am running my uhd_usrp_probe with a custom FPGA
> image.  The image I have created has 2 FFT’s and 2 Windows in it.  The
> warning indicate that the controller blocks cannot be found for the FFT’s.
>
> Later, at the bottom of the run, I get some errors like the following
> [ERROR] [UHD] Exception caught in safe-call.
>
> I would like to confirm that the lack of a controller for the FFT is a
> real problem that needs to be resolved.
>
> Relative to the exceptions at the end, I have read that although this is
> an error, it does not prevent running applications
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/051914.html
>
>
>
> root@ettus-e3xx-sg3:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args='fpga=usrp_e310_fpga_RFNOC_sg3.bit'
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [INFO] [0/Window_0] Initializing block control (NOC ID:
> 0xD053)
> [INFO] [0/Window_1] Initializing block control (NOC ID:
> 0xD053)
> [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)
> [WARNING] [RFNOC] Can't find a block controller for key FFT, using
> default block controller!
> [INFO] [0/FFT_1] Initializing block control (NOC ID: 0xFF70)
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX SG3
> |   |   product: 30675
> |   |   revision: 7
> |   |   serial: 3150D1D
> |   |   mac-addr: 00:80:2f:19:10:70
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: 1b40696-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 314E574
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/

Re: [USRP-users] DMA FIFO Resizing

[Marcus D. Leech via USRP-users]

On 09/24/2018 02:52 PM, Brian Padalino via USRP-users wrote:
I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the 
installation of UHD as of current master:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt

It seems like this is just a simple oversight, so I modified it 
locally.  I've been running doing some latency experiments and 
modifying the size of the DMA FIFO using the resize() method:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65

And it seems there's a bit of a restriction on the sizing associated 
with the FIFO:


https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263

I see it currently says that the FIFO needs to be >8k, and it has to 
be a power of 2.  If either of those criteria fails, an exception is 
thrown.


A few requests:

(1) Can you not throw an exception, but print a warning and resolve 
the criteria?  For example, if I ask for < 8k, up it to 8k and print a 
warning it's been upped.  If I ask for a non-power of 2, can you print 
a warning and up to to the next supported power of 2? Think of this 
like a request for a sample rate - if you can't get the exact one, you 
get what's close and the user can query the actual value?
I'll comment that I've found UHD to be more "throwy" than it needs to 
be, and comparison to sample-rate is apt.Seems like a good policy

  should be "if it make sense to proceed, do so, and issue a warning".





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