Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: LFRX daughterboard with radio block (Jonathon Pendlum)
2. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
3. How to solve command timeout error? (Haile Berhe)
4. Using B210 TX/RX in TDD mode (Sumit Kumar)
5. Signal generator and antenna using GNU radio receiving power
(Jahnavendra Mattipa)
6. Re: Signal generator and antenna using GNU radio receiving
power (Marcus M?ller)
7. Support (Pasquale For)
8. half-duplex, single antenna, on the B200 mini? (Jason Matusiak)
9. Re: Using B210 TX/RX in TDD mode (Gilad Beeri (ApolloShield))
10. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
11. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
12. Re: LFRX daughterboard with radio block (Jason Matusiak)
13. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
14. Re: LFRX daughterboard with radio block (Jason Matusiak)
15. E310 filter configuration (Yake Li)
16. Re: E310 filter configuration (Julian Arnold)
17. Re: E310 filter configuration ([email protected])
18. Re: E310 filter configuration (Rob Kossler)
19. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
20. Re: E310 filter configuration (Rob Kossler)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 May 2017 12:24:10 -0500
From: Jonathon Pendlum <[email protected]>
To: "Barker, Douglas W." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID:
<cagdo0ur8ezu3tuhsfisrqlf04pj+tcvcf9cz9zwhtmacgcy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not
something like rfnoc-devel-predo right? What is ce_clk hooked up to in your
custom block? Is your flowgraph Radio Block -> Custom Block or Radio Block
-> DDC -> Custom Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users <
[email protected]> wrote:
> Hello,
>
>
>
> I?m using the LFRX daughterboard on the X310. In gnuradio I connect the
> rfnoc radio block to my custom rfnoc block and from there to the host. The
> sample rate of the radio block is set to 200M. In my custom noc block I
> connect the output of noc_shell -> chdr_deframer. On the output of the
> chdr_deframer I?m expecting 200 Msps data, thus the ?o_tvalid? signal
> should be continuously high (I?ve got the ?o_tready? tied high).
>
>
>
> That?s not what I get though. The rate coming in is only a small fraction
> of 200 Msps. When I monitor the transactions at the input to the noc block
> (i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all
> in sequence so none are discarded. Can anyone tell me what is going on??
>
>
>
> Thanks
>
> Doug
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/d14b29c6/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 8 May 2017 18:37:32 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs ??
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
?[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports?
I don?t know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I?m putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I?ve included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I?m using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I?m
expecting 200 Msps data, thus the ?o_tvalid? signal should be continuously high
(I?ve got the ?o_tready? tied high).
That?s not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/eef32a5d/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 9 May 2017 11:36:37 +0300
From: Haile Berhe <[email protected]>
To: [email protected]
Subject: [USRP-users] How to solve command timeout error?
Message-ID:
<CAHr+hkEgHvBg6=Wr5UEik1jc1XNve0TAZ=iweqogf4subd3...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear all,
I have been working on my X310 USRP just fine. But after I have
installed rfnoc modules and reload fpga images , the behavior of the
device becomes unpredictable. It sometimes throws the following error
message even if I run non rfnoc application:
?RuntimeError: EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
no response packet - AssertionError: bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /home/haile/prefix/default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197?
I have observed that the above error is not thrown in the first run
after I power cycle the device. [1] seems to discuss the issue but the
proposed solution is not clear. It says, check ce_clk/ce_rst are
connected in the rfnoc_ce_auto_inst_<device>.v., etc .. How am I
supposed to check?
Thanks,
[1] https://kb.ettus.com/RFNoC
------------------------------
Message: 4
Date: Tue, 9 May 2017 12:32:45 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Using B210 TX/RX in TDD mode
Message-ID:
<CAOExtcRLzA54_Xr=r=VNr82MGzKMzehiq65PD7ydM+8x7z=r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Are there examples/ discussion where I can see TX/RX port is used in a TDD
fashion.
I want to pause my 802.11 receiver thread on some condition, transmit the
acknowledgment frame and then wake up the receiver thread again. And I want
to do this using single antenna port i.e. TX/RX.
Is there some internal switch which is required to be controlled for this ?
Regards
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/75db5d34/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 9 May 2017 16:21:51 +0530
From: Jahnavendra Mattipa <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: [USRP-users] Signal generator and antenna using GNU radio
receiving power
Message-ID:
<cah5ne-bkmkgp8njjpt_5qwokhym5gsteamujnjht5fl05vs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I am facing a small issue while running the signal generator and
antenna signal using USRP. When i am using the signal generator for the
-63.80 gain i am getting the -33.47dB but with same flowgraph i tried to
run with antenna i am getting the -42dB. Can anybody have idea about this
issue kindly let me know why i am unable to getting the same values with
signal generator and antenna. I think the whatever the signal we are
receiving with the SG and the same values also i have to get with antenna.
I attached the screenshots of flowgraphs and 'grc' file. If anyone has
advices and comments, they would be greatly appreciated.
Best Regards,
M.Jahnavendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/744fbfc1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-04-25 14_36_36.png
Type: image/png
Size: 239966 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/744fbfc1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-04-25 15_10_48.png
Type: image/png
Size: 261264 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/744fbfc1/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-05-08 16_47_53.png
Type: image/png
Size: 134996 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/744fbfc1/attachment-0005.png>
------------------------------
Message: 6
Date: Tue, 9 May 2017 13:01:54 +0200
From: Marcus M?ller <[email protected]>
To: Jahnavendra Mattipa <[email protected]>,
[email protected], [email protected],
[email protected], [email protected]
Subject: Re: [USRP-users] Signal generator and antenna using GNU radio
receiving power
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jahnavendra,
you **must** read the output you're getting in the console window:
The sampling rate you're trying to use is impossible. So, all relative
baseband frequencies are incorrect. However, that is irrelevant for the
amplitude considerations:
> When i am using the signal generator for the -63.80 gain i am getting the
> -33.47dB but with same flowgraph i tried to run with antenna i am getting the
> -42dB.
And what's wrong with that? An antenna-air-antenna channel is not the
same as a cable; personally, I think that's kind of obvious, and that
means you might be wondering about something more complicated that I
simply don't understand. Could you elaborate on why this surprises you?
Best regards,
Marcus
------------------------------
Message: 7
Date: Mon, 8 May 2017 14:13:38 +0000
From: Pasquale For <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Support
Message-ID:
<vi1pr1001mb0861bf90699fd43b0b84915eaf...@vi1pr1001mb0861.eurprd10.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear Ettus-Users-Support
I have installed on SO-Linux (Ubuntu), the SDK(UHD) to use with USRP-E310
(following this guide: https:
//kb.ettus.com/Software_Development_on_the_E310_and_E312); The installation
steps have all gone well.
Now I'm going to run two Sources Examples
(src/uhd/host/examples/rx_samples_c.c) and
(src/uhd/host/examples/rx_samples_to_file.cpp) , in freq= 150MHz , rate =20 KHz
, nsamp= 2000.
The Examples provided by Ettus was been run correctly, but I have tried to read
the acquired samples data (Data from rx-channel), but I have obtainded only a
data stream that with don't konw how to decode :
1) how to interpret the output File.dat (binary file)? It has headers?
2) If the samples in Rx are present in File.dat, are they spaced of
"T_sampling" , chosen in the "Rate" parameter ?
3) In the example "rx_samples_c.c", the API "uhd_rx_streamer_recv ()" is point
to Memory Area with dimension "N_Samples * 2 * float" , so I ask you, why used
2 floats to rappresent 1 data sampled ?
3) In the example "rx_samples_to_file.cpp", the API "rx_stream :: recv ()" is
point to Buffer (buff), but when print value of buffer (with cout << buff[i]
), this is equal to a couple of values "(n1, n2)" , why two values , the first
value is time of sampling?
If possible , attachment the examples.
Thank you so much.
Best Regards.
Pako.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/6b566587/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 9 May 2017 08:56:42 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] half-duplex, single antenna, on the B200 mini?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
We were investigating using the single TX/RX port on a B200 mini and
hitting up against a wall figuring out how to make the transition
between TX and RX within a single flowgraph. When I did a little
research, I found an app note
(https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf)
that said the following in the "Transceiver Antenna Selection -
Half-Duplex vs. Full Duplex" section:
"If the application requires the USRP device to operate in half-duplex
mode with a single antenna (per USRP), the TX/RX connector can be used
for transmission and reception. In this mode, automatic transmit-receive
(ATR) logic switches the TX/RX port to the transmit path when the host
is streaming samples. When transmit streaming stops, a state-machine in
the FPGA will automatically switch the TX/RX port to the receive path.
This functionality can be overridden with UHD API calls to control the
transmit/receive switches through GPIO."
This sounds a lot like what I need, but then when I look at:
https://files.ettus.com/manual/page_gpio_api.html#xgpio_fpanel_atr
It looks like they only explain how to do this on the E3x0 and X3x0
series, not the B2xx. Is there a way to do this on the mini? And if
so, are there examples out there showing this? Thanks!
------------------------------
Message: 9
Date: Tue, 09 May 2017 13:14:34 +0000
From: "Gilad Beeri (ApolloShield)" <[email protected]>
To: Sumit Kumar <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Using B210 TX/RX in TDD mode
Message-ID:
<caf4uvpc4qn7vod6uvx3t6k4s+kr6hnkw3x69qxpnbbuuyjf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I think that the recent post
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-May/024831.html
references what you're asking about
On Tue, May 9, 2017 at 1:34 PM Sumit Kumar via USRP-users <
[email protected]> wrote:
>
> Hi,
>
> Are there examples/ discussion where I can see TX/RX port is used in a
> TDD fashion.
>
> I want to pause my 802.11 receiver thread on some condition, transmit the
> acknowledgment frame and then wake up the receiver thread again. And I want
> to do this using single antenna port i.e. TX/RX.
>
> Is there some internal switch which is required to be controlled for this
> ?
>
> Regards
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/90d79a5c/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 9 May 2017 13:16:04 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Here?s some more information. Firstly, when I connect the radio block to my
custom block in gnu radio I get a dashed line. I get a dashed line also when
connecting the custom block to a frequency sink block in gnu radio. I put some
debug in the FPGA and I can see the radio block turn on and start sending
packets out the AXI bus at the correct rate, but the packets that arrive at my
custom block have the time stamps stripped, and have different sequence numbers
and different source and destination SID?s. It seems as though the packets
from the radio block are routed to the host and then some subset of them are
routed back to the custom noc block with no time stamps. To me this points to
a problem with the xml files, but I?ve followed the examples that I have and I
can only guess as to the purpose of some of the tags and keywords. Can anyone
give me some pointers?
Thanks
Doug
From: Barker, Douglas W.
Sent: Monday, May 08, 2017 2:38 PM
To: 'Jonathon Pendlum'
Cc: [email protected]
Subject: RE: [USRP-users] LFRX daughterboard with radio block
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs ??
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
?[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports?
I don?t know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I?m putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I?ve included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I?m using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I?m
expecting 200 Msps data, thus the ?o_tvalid? signal should be continuously high
(I?ve got the ?o_tready? tied high).
That?s not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/a146d297/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 9 May 2017 13:24:55 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Ok, I think I fixed the problem ? I didn?t have <domain>rfnoc</domain>
specified for the input to the custom block. Moving on ?.
Doug
From: Barker, Douglas W.
Sent: Monday, May 08, 2017 2:38 PM
To: 'Jonathon Pendlum'
Cc: [email protected]
Subject: RE: [USRP-users] LFRX daughterboard with radio block
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs ??
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
?[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports?
I don?t know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I?m putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I?ve included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I?m using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I?m
expecting 200 Msps data, thus the ?o_tvalid? signal should be continuously high
(I?ve got the ?o_tready? tied high).
That?s not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/78306f24/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 9 May 2017 10:19:30 -0400
From: Jason Matusiak <[email protected]>
To: "Barker, Douglas W." <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Doug, were you able to get rid of the "?[WARNING] [RFNOC] [0/xxx_0]
defines 9 input buffer sizes, but 1 input ports?" warning? I get it
too, but last I saw it was a pseudo-bug and we just need to ignore it
for now.
~Jason
On 05/08/2017 02:37 PM, Barker, Douglas W. via USRP-users wrote:
>
> Hi Jonathon,
>
> Thanks for the reply. uhd_usrp_probe outputs ??
> UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block ->
> Custom Block -> host. Actually, the custom block has 9 output ports,
> each of which connect to the host. I do get a warning when I run the
> uhd_usrp_probe that indicates the following:
>
> ?[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input
> ports?
>
> I don?t know why I get this warning or how to make it go away. Could
> this be a problem with the xml files? I?m putting some debug in the
> noc_block_radio_core to see if I can track down where the data is
> being lost. I?ve included the Verilog for the noc_block below if
> anyone is so inclined to look it over.
>
> Thanks
>
> Doug
>
> module noc_block_xxx
>
> #(
>
> parameter NOC_ID = 64'h0930_1997_0000_0000,
>
> parameter STR_SINK_FIFOSIZE = 11,
>
> parameter NUM_OUTPUTS = 9
>
> )
>
> (
>
> input bus_clk,
>
> input bus_rst,
>
> input ce_clk,
>
> input ce_rst,
>
> input [63:0] i_tdata,
>
> input i_tlast,
>
> input i_tvalid,
>
> output i_tready,
>
> output [63:0] o_tdata,
>
> output o_tlast,
>
> output o_tvalid,
>
> input o_tready,
>
> output [63:0] debug
>
> );
>
> // Block Configuration
>
> localparam NUM_DDC = 8; // Number of receiver DDC channels to
> instantiate
>
> localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of
> detector channels
>
> localparam SR_BASE = 128; // Settings register
> address base
>
> // Interconnect
>
> wire [32*NUM_OUTPUTS-1:0] set_data;
>
> wire [8*NUM_OUTPUTS-1:0] set_addr;
>
> wire [NUM_OUTPUTS-1:0] set_stb;
>
> wire [64*NUM_OUTPUTS-1:0] rb_data;
>
> wire [63:0] str_sink_tdata;
>
> wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
>
> wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
>
> wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
>
> wire [31:0] in_tdata;
>
> wire [127:0] in_tuser;
>
> wire in_tvalid;
>
> wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
>
> wire [32*NUM_OUTPUTS-1:0] out_tdata;
>
> wire [128*NUM_OUTPUTS-1:0] out_tuser;
>
> wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
>
> wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
>
> // RFNoC Shell
>
> noc_shell #(
>
> .NOC_ID(NOC_ID),
>
> .STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
>
> .INPUT_PORTS(1),
>
> .OUTPUT_PORTS(NUM_OUTPUTS))
>
> noc_shell (
>
> .bus_clk(bus_clk), .bus_rst(bus_rst),
>
> .i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
> .i_tready(i_tready),
>
> .o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
> .o_tready(o_tready),
>
> // Compute Engine Clock Domain
>
> .clk(ce_clk), .reset(ce_rst),
>
> // Control Sink
>
> .set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
>
> .set_time(), .set_has_time(),
>
> .rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
>
> // Control Source
>
> .cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
> .cmdout_tready(),
>
> .ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
>
> // Stream Sink
>
> .str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
> .str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
>
> // Stream Source
>
> .str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
>
> .str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
>
> .vita_time(64'd0),
>
> .clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
> .next_dst_sid(nxt_dst_sid),
>
> .resp_in_dst_sid(), .resp_out_dst_sid(),
>
> .debug(debug));
>
> // CHDR deframer for incomming packets from the radio front end at 200
> Msps. The output signal
>
> // here is a steady stream sampled at 200 Msps with no gaps in the
> 'valid' signal. The AXI
>
> // framing signals can be ignored.
>
> chdr_deframer chdr_deframer (
>
> .clk(ce_clk), .reset(ce_rst), .clear(1'b0),
>
> .i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
> .i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
>
> .o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(),
> .o_tvalid(in_tvalid), .o_tready(1'b1));
>
> // xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
>
> xxx_core
>
> #(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
>
> xxx_core_inst
>
> (.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
>
> .set_data(set_data), .rb_data(rb_data),
>
> .valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
>
> .out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
>
> .out_tdata(out_tdata));
>
> // Prepend the CHDR header to all packets, and connect these streams
> to block output ports
>
> localparam MTU = 10;
>
> genvar m;
>
> generate
>
> for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
>
> assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
> src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
>
> chdr_framer #(.SIZE(MTU)) chdr_framer (
>
> .clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
>
> .i_tdata(out_tdata[32*(m+1)-1:32*m]),
> .i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
> .i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
>
> .o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
> .o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
>
> end
>
> endgenerate
>
> endmodule // noc_block_xxx
>
> *From:*Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Monday, May 08, 2017 1:24 PM
> *To:* Barker, Douglas W.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] LFRX daughterboard with radio block
>
> Hi Doug,
>
> That is very odd. Are you using the latest rfnoc-devel commit and not
> something like rfnoc-devel-predo right? What is ce_clk hooked up to in
> your custom block? Is your flowgraph Radio Block -> Custom Block or
> Radio Block -> DDC -> Custom Block?
>
> Jonathon
>
> On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
>
> I?m using the LFRX daughterboard on the X310. In gnuradio I connect
> the rfnoc radio block to my custom rfnoc block and from there to the
> host. The sample rate of the radio block is set to 200M. In my
> custom noc block I connect the output of noc_shell -> chdr_deframer.
> On the output of the chdr_deframer I?m expecting 200 Msps data, thus
> the ?o_tvalid? signal should be continuously high (I?ve got the
> ?o_tready? tied high).
>
> That?s not what I get though. The rate coming in is only a small
> fraction of 200 Msps. When I monitor the transactions at the input to
> the noc block (i_tdata, i_tvalid, etc) I see the same behavior. The
> AXI packets are all in sequence so none are discarded. Can anyone tell
> me what is going on??
>
> Thanks
>
> Doug
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/17d66940/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 9 May 2017 14:24:32 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jason Matusiak <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Jason,
No, that warning is still there. I don't think it affects anything though. I
suspect it may come from the way noc_shell is configured with INPUT_PORTS, and
OUTPUT_PORTS and BLOCK_PORTS parameters.
Doug
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 09, 2017 10:20 AM
To: Barker, Douglas W.; Jonathon Pendlum
Cc: [email protected]
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Doug, were you able to get rid of the ""[WARNING] [RFNOC] [0/xxx_0] defines 9
input buffer sizes, but 1 input ports"" warning? I get it too, but last I saw
it was a pseudo-bug and we just need to ignore it for now.
~Jason
On 05/08/2017 02:37 PM, Barker, Douglas W. via USRP-users wrote:
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs "...
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
"[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports"
I don't know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I'm putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I've included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I'm using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I'm
expecting 200 Msps data, thus the 'o_tvalid' signal should be continuously high
(I've got the 'o_tready' tied high).
That's not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/9d702fcf/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 9 May 2017 10:47:57 -0400
From: Jason Matusiak <[email protected]>
To: "Barker, Douglas W." <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Agreed (on thinking it doesn't actually affect anything). In fact, I
know I've seen it show up on some of the ettus's designed blocks (like
fosphor). I was just hoping you figured out how to make it happy so I
could get it to stop popping up :).
~Jason
On 05/09/2017 10:24 AM, Barker, Douglas W. wrote:
>
> Jason,
>
> No, that warning is still there. I don?t think it affects anything
> though. I suspect it may come from the way noc_shell is configured
> with INPUT_PORTS, and OUTPUT_PORTS and BLOCK_PORTS parameters.
>
> Doug
>
> *From:*Jason Matusiak [mailto:[email protected]]
> *Sent:* Tuesday, May 09, 2017 10:20 AM
> *To:* Barker, Douglas W.; Jonathon Pendlum
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] LFRX daughterboard with radio block
>
> Doug, were you able to get rid of the "?[WARNING] [RFNOC] [0/xxx_0]
> defines 9 input buffer sizes, but 1 input ports?" warning? I get it
> too, but last I saw it was a pseudo-bug and we just need to ignore it
> for now.
>
>
> ~Jason
>
> On 05/08/2017 02:37 PM, Barker, Douglas W. via USRP-users wrote:
>
> Hi Jonathon,
>
> Thanks for the reply. uhd_usrp_probe outputs ??
> UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block ->
> Custom Block -> host. Actually, the custom block has 9 output
> ports, each of which connect to the host. I do get a warning when
> I run the uhd_usrp_probe that indicates the following:
>
> ?[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1
> input ports?
>
> I don?t know why I get this warning or how to make it go away.
> Could this be a problem with the xml files? I?m putting some
> debug in the noc_block_radio_core to see if I can track down where
> the data is being lost. I?ve included the Verilog for the
> noc_block below if anyone is so inclined to look it over.
>
> Thanks
>
> Doug
>
> module noc_block_xxx
>
> #(
>
> parameter NOC_ID = 64'h0930_1997_0000_0000,
>
> parameter STR_SINK_FIFOSIZE = 11,
>
> parameter NUM_OUTPUTS = 9
>
> )
>
> (
>
> input bus_clk,
>
> input bus_rst,
>
> input ce_clk,
>
> input ce_rst,
>
> input [63:0] i_tdata,
>
> input i_tlast,
>
> input i_tvalid,
>
> output i_tready,
>
> output [63:0] o_tdata,
>
> output o_tlast,
>
> output o_tvalid,
>
> input o_tready,
>
> output [63:0] debug
>
> );
>
> // Block Configuration
>
> localparam NUM_DDC = 8; // Number of receiver DDC channels
> to instantiate
>
> localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of
> detector channels
>
> localparam SR_BASE = 128; // Settings
> register address base
>
> // Interconnect
>
> wire [32*NUM_OUTPUTS-1:0] set_data;
>
> wire [8*NUM_OUTPUTS-1:0] set_addr;
>
> wire [NUM_OUTPUTS-1:0] set_stb;
>
> wire [64*NUM_OUTPUTS-1:0] rb_data;
>
> wire [63:0] str_sink_tdata;
>
> wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
>
> wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
>
> wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid,
> str_src_tready;
>
> wire [31:0] in_tdata;
>
> wire [127:0] in_tuser;
>
> wire in_tvalid;
>
> wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
>
> wire [32*NUM_OUTPUTS-1:0] out_tdata;
>
> wire [128*NUM_OUTPUTS-1:0] out_tuser;
>
> wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
>
> wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
>
> // RFNoC Shell
>
> noc_shell #(
>
> .NOC_ID(NOC_ID),
>
> .STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
>
> .INPUT_PORTS(1),
>
> .OUTPUT_PORTS(NUM_OUTPUTS))
>
> noc_shell (
>
> .bus_clk(bus_clk), .bus_rst(bus_rst),
>
> .i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
> .i_tready(i_tready),
>
> .o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
> .o_tready(o_tready),
>
> // Compute Engine Clock Domain
>
> .clk(ce_clk), .reset(ce_rst),
>
> // Control Sink
>
> .set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
>
> .set_time(), .set_has_time(),
>
> .rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
>
> // Control Source
>
> .cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
> .cmdout_tready(),
>
> .ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
>
> // Stream Sink
>
> .str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
> .str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
>
> // Stream Source
>
> .str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
>
> .str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
>
> .vita_time(64'd0),
>
> .clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
> .next_dst_sid(nxt_dst_sid),
>
> .resp_in_dst_sid(), .resp_out_dst_sid(),
>
> .debug(debug));
>
> // CHDR deframer for incomming packets from the radio front end at
> 200 Msps. The output signal
>
> // here is a steady stream sampled at 200 Msps with no gaps in the
> 'valid' signal. The AXI
>
> // framing signals can be ignored.
>
> chdr_deframer chdr_deframer (
>
> .clk(ce_clk), .reset(ce_rst), .clear(1'b0),
>
> .i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
> .i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
>
> .o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(),
> .o_tvalid(in_tvalid), .o_tready(1'b1));
>
> // xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1
> !!!!!!!
>
> xxx_core
>
> #(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
>
> xxx_core_inst
>
> (.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb),
> .set_addr(set_addr),
>
> .set_data(set_data), .rb_data(rb_data),
>
> .valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
>
> .out_tvalid(out_tvalid), .out_tlast(out_tlast),
> .out_tready(out_tready),
>
> .out_tdata(out_tdata));
>
> // Prepend the CHDR header to all packets, and connect these
> streams to block output ports
>
> localparam MTU = 10;
>
> genvar m;
>
> generate
>
> for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
>
> assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
> src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m],
> in_tuser[63:0]};
>
> chdr_framer #(.SIZE(MTU)) chdr_framer (
>
> .clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
>
> .i_tdata(out_tdata[32*(m+1)-1:32*m]),
> .i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
> .i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
>
> .o_tdata(str_src_tdata[64*(m+1)-1:64*m]),
> .o_tlast(str_src_tlast[m]), .o_tvalid(str_src_tvalid[m]),
> .o_tready(str_src_tready[m]));
>
> end
>
> endgenerate
>
> endmodule // noc_block_xxx
>
> *From:*Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Monday, May 08, 2017 1:24 PM
> *To:* Barker, Douglas W.
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] LFRX daughterboard with radio block
>
> Hi Doug,
>
> That is very odd. Are you using the latest rfnoc-devel commit and
> not something like rfnoc-devel-predo right? What is ce_clk hooked
> up to in your custom block? Is your flowgraph Radio Block ->
> Custom Block or Radio Block -> DDC -> Custom Block?
>
> Jonathon
>
> On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hello,
>
> I?m using the LFRX daughterboard on the X310. In gnuradio I
> connect the rfnoc radio block to my custom rfnoc block and from
> there to the host. The sample rate of the radio block is set to
> 200M. In my custom noc block I connect the output of noc_shell ->
> chdr_deframer. On the output of the chdr_deframer I?m expecting
> 200 Msps data, thus the ?o_tvalid? signal should be continuously
> high (I?ve got the ?o_tready? tied high).
>
> That?s not what I get though. The rate coming in is only a small
> fraction of 200 Msps. When I monitor the transactions at the
> input to the noc block (i_tdata, i_tvalid, etc) I see the same
> behavior. The AXI packets are all in sequence so none are
> discarded. Can anyone tell me what is going on??
>
> Thanks
>
> Doug
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected] <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/fef61346/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 9 May 2017 12:20:03 -0230
From: "Yake Li" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] E310 filter configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
My question is could I set the filters separately in Ettus E310? I
noticed there are different filters in E310. First, there are filter banks
right after the receiving antenna. Second, the AD9361 has Rx low pass
filters before ADC (please refer to "Rx SIGNAL PATH" of
http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only one
command "set_bandwidth" in gnuradio (or "set_rx_bandwidth" in UHD) to set
the RF bandwidth of front end. What is the response of each filters
mentioned above after using this command? Could I set separately the
response of different filters?
I am asking because I want to, for example, sample a signal centered at 2.03
GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to sample
this signal with 6 MHz sampling rate. What I did is that I use
"set_center_freq (2e9,0)", "set_bandwidth (3e6,0)" and "set_samp_rate
(6e6,0)". The result seems to be incorrect. I tried different bandwidth, and
under no settings I got the right result. Is there something wrong with my
settings?
Thanks!
Yake
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/835dc453/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 9 May 2017 17:01:52 +0200
From: Julian Arnold <[email protected]>
To: Yake Li <[email protected]>, [email protected]
Subject: Re: [USRP-users] E310 filter configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey Yake,
I'm not sure in which way your results are incorrect but if you want to
get more information on the active filters in the RX chain you can use
UHD's filter API:
- uhd::usrp::multi_usrp::get_filter_names to list all available filters
- uhd::usrp::multi_usrp::get_filter to get information on each filter
This should work for all the filters in the AD9361. However, I don't
think that the filter-bank of the E310 is reflected here.
Cheers,
On 05/09/2017 04:50 PM, Yake Li via USRP-users wrote:
>
> Hello,
>
>
>
> My question is could I set the filters separately in Ettus E310? I
> noticed there are different filters in E310. First, there are filter
> banks right after the receiving antenna. Second, the AD9361 has Rx low
> pass filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is
> only one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in
> UHD) to set the RF bandwidth of front end. What is the response of
> each filters mentioned above after using this command? Could I set
> separately the response of different filters?
>
>
>
> I am asking because I want to, for example, sample a signal centered
> at 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I
> want to sample this signal with 6 MHz sampling rate. What I did is
> that I use ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and
> ?set_samp_rate (6e6,0)?. The result seems to be incorrect. I tried
> different bandwidth, and under no settings I got the right result. Is
> there something wrong with my settings?
>
>
>
> Thanks!
>
>
>
> Yake
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 17
Date: Tue, 09 May 2017 11:05:55 -0400
From: [email protected]
To: Yake Li <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E310 filter configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The "set_bandwidth" method sets the analog bandwidth in front of the
ADC.
The RF filters are selected automatically based on your desired tuning
frequency.
It would help us if you describe how the result is "incorrect" --
perhaps an FFT plot?
On 2017-05-09 10:50, Yake Li via USRP-users wrote:
> Hello,
>
> My question is could I set the filters separately in Ettus E310? I noticed
> there are different filters in E310. First, there are filter banks right
> after the receiving antenna. Second, the AD9361 has Rx low pass filters
> before ADC (please refer to "RX SIGNAL PATH" of
> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only one
> command "set_bandwidth" in gnuradio (or "set_rx_bandwidth" in UHD) to set the
> RF bandwidth of front end. What is the response of each filters mentioned
> above after using this command? Could I set separately the response of
> different filters?
>
> I am asking because I want to, for example, sample a signal centered at 2.03
> GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to sample
> this signal with 6 MHz sampling rate. What I did is that I use
> "set_center_freq (2e9,0)", "set_bandwidth (3e6,0)" and "set_samp_rate
> (6e6,0)". The result seems to be incorrect. I tried different bandwidth, and
> under no settings I got the right result. Is there something wrong with my
> settings?
>
> Thanks!
>
> Yake
>
> [1]
> Virus-free. www.avast.com [1]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1]
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/03ec49e0/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 9 May 2017 11:14:45 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Yake Li <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID:
<CAB__hTRyw1pHXFH5DV-02MP=95+gWCoT8_Kza9XAof_j1B=m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ignoring the set_bandwidth() command, if you set the center freq to 2e9 and
the sample rate to 3e6, your results will show signals in the range
1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
which is 30 MHz away from 2 GHz.
Rob
On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> The "set_bandwidth" method sets the analog bandwidth in front of the ADC.
>
> The RF filters are selected automatically based on your desired tuning
> frequency.
>
> It would help us if you describe how the result is "incorrect" -- perhaps
> an FFT plot?
>
>
>
>
>
>
> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>
> Hello,
>
>
>
> My question is could I set the filters separately in Ettus E310? I
> noticed there are different filters in E310. First, there are filter banks
> right after the receiving antenna. Second, the AD9361 has Rx low pass
> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only
> one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD) to
> set the RF bandwidth of front end. What is the response of each filters
> mentioned above after using this command? Could I set separately the
> response of different filters?
>
>
>
> I am asking because I want to, for example, sample a signal centered at
> 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to
> sample this signal with 6 MHz sampling rate. What I did is that I use
> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
> and under no settings I got the right result. Is there something wrong with
> my settings?
>
>
>
> Thanks!
>
>
>
> Yake
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/e3a42fda/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 9 May 2017 15:20:22 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jason Matusiak <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ok, now I get a new error (from gnuradio console output):
...
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=0
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=1
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=2
Thread[thread-per-block(0):<block_uhd_rfnoc_xxx(2)>]:LookupError:keyError:-0/Radio_0[
sr_write():No such port: 2
>>>Done
Does this have something to do with the fact that the software thinks there are
9 input ports?? Is it another xml error?
Doug
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 09, 2017 10:48 AM
To: Barker, Douglas W.; Jonathon Pendlum
Cc: [email protected]
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Agreed (on thinking it doesn't actually affect anything). In fact, I know I've
seen it show up on some of the ettus's designed blocks (like fosphor). I was
just hoping you figured out how to make it happy so I could get it to stop
popping up :).
~Jason
On 05/09/2017 10:24 AM, Barker, Douglas W. wrote:
Jason,
No, that warning is still there. I don't think it affects anything though. I
suspect it may come from the way noc_shell is configured with INPUT_PORTS, and
OUTPUT_PORTS and BLOCK_PORTS parameters.
Doug
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 09, 2017 10:20 AM
To: Barker, Douglas W.; Jonathon Pendlum
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Doug, were you able to get rid of the ""[WARNING] [RFNOC] [0/xxx_0] defines 9
input buffer sizes, but 1 input ports"" warning? I get it too, but last I saw
it was a pseudo-bug and we just need to ignore it for now.
~Jason
On 05/08/2017 02:37 PM, Barker, Douglas W. via USRP-users wrote:
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs "...
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
"[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports"
I don't know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I'm putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I've included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I'm using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I'm
expecting 200 Msps data, thus the 'o_tvalid' signal should be continuously high
(I've got the 'o_tready' tied high).
That's not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/373c101d/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 9 May 2017 11:52:54 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Yake Li <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID:
<cab__htsdmxn3e7boi3zwpuss0pauv52grvfq+sf54+0m4wb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Typo in my message. I meant to say set the sample rate to 6e6 as you
indicated originally...
On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <[email protected]> wrote:
> Ignoring the set_bandwidth() command, if you set the center freq to 2e9
> and the sample rate to 3e6, your results will show signals in the range
> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
> which is 30 MHz away from 2 GHz.
>
> Rob
>
>
> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> The "set_bandwidth" method sets the analog bandwidth in front of the ADC.
>>
>> The RF filters are selected automatically based on your desired tuning
>> frequency.
>>
>> It would help us if you describe how the result is "incorrect" -- perhaps
>> an FFT plot?
>>
>>
>>
>>
>>
>>
>> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>>
>> Hello,
>>
>>
>>
>> My question is could I set the filters separately in Ettus E310? I
>> noticed there are different filters in E310. First, there are filter banks
>> right after the receiving antenna. Second, the AD9361 has Rx low pass
>> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
>> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only
>> one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD) to
>> set the RF bandwidth of front end. What is the response of each filters
>> mentioned above after using this command? Could I set separately the
>> response of different filters?
>>
>>
>>
>> I am asking because I want to, for example, sample a signal centered at
>> 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to
>> sample this signal with 6 MHz sampling rate. What I did is that I use
>> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
>> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
>> and under no settings I got the right result. Is there something wrong with
>> my settings?
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Yake
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/56cd5647/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 9
*****************************************
