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 whether it is MSB padded or LSB
padded? Is it also in 2’s complement?
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?
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?
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?
Thank you,
Andrew
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
Sent: Thursday, February 13, 2020 14:07
To: Payne, William Andrew (Andrew) CIV USN NSWC CD CRANE ID (USA)
<andrew.pay...@navy.mil>
Cc: usrp-users@lists.ettus.com; matt.peg...@ni.com
Subject: [Non-DoD Source] Re: [USRP-users] RFNOC: 2 input/2 output block,
synchronizing their outputs to GNURadio host
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 <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com> > 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 <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.noclick_com/mailman/listinfo/usrp-users_lists.ettus.com>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
