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) <andrew.pay...@navy.mil> 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 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> 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
> <http://lists.ettus.noclick_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
