Re: [USRP-users] Creating RFNOC block that changes stream rate

[Jon Pendlum via USRP-users]

Hi Andrew,

You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
works too), purchase this kit https://www.ettus.com/product/details/E-JTAG-4,
and follow these instructions:
https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
For setting up the ILA and debugging, see:
https://kb.ettus.com/Debugging_FPGA_images.

Jonathon

On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz 
wrote:

> Hi John,
>
> Is there any documentation on using the ILA on an e310 that's running
> gnuradio directly?
>
> Thanks,
> Andrew
>
> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:
>
>> Hi Andrew,
>>
>> Have you tried using Chipscope to see where the issue is at in your code?
>> You want to look at the tvalid and tready AXI stream control signals to
>> pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
>> you know where the stall is located, I can provide more advice.
>>
>> Jonathon
>>
>> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Thanks for the reply. I do set simple_mode and I propagate tuser into
>>> and out of axi_rate_change the same way noc_block_ddc does. I also have my
>>> block running properly in Vivado simulation. Is there anything else I
>>> should check? I also included axi_tag_time. Could that be causing an issue?
>>>
>>> Thanks!
>>> Andrew
>>>
>>> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>>>
 Hi Andrew,

 Quick thoughts:
 - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
 - Are you propagating tuser into and out of the axi_rate_change block?

 The axi_rate_change block updates tuser, which the axi_wrapper uses to
 create output packets when SIMPLE_MODE is disabled.

 Also, have you run in a simulation testbench? Simulation should be able
 to expose these issues before targetting hardware to make debugging a bit
 easier.

 EJ



 On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all
> verbal communications from WhiteFox Defense to your entity in the prior 30
> days constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in 
> error,
> please promptly notify i...@whitefoxdefense.com and destroy all
> copies of the message and any attachments. This email and attachments may
> contain technical data as defined in the International Traffic In Arms
> Regulations (ITAR) 22 CFR 120.10 or the Export Administration Regulations
> (EAR) 15 CFR Parts 730 – 780.  Export of this material may be controlled 
> by
> these regulations and may not be exported or transferred to non-U.S.
> persons without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Jon Pendlum via USRP-users]

Hi Andrew,

Have you tried using Chipscope to see where the issue is at in your code?
You want to look at the tvalid and tready AXI stream control signals to
pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
you know where the stall is located, I can provide more advice.

Jonathon

On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Jon Pendlum via USRP-users]

Hey Jason,

Do you need to be able to run the block at 200 MSPS? If not, I would
suggest changing all instances of ce_clk to bus_clk in your block. bus_clk
runs at ~187.5 MHz versus ~214 MHz for ce_clk, so it could give you the
extra margin you need to make timing.

You can also make the change by editing rfnoc_ce_auto_inst_x310.v and
setting your block's ce_clk input to bus_clk. I mention this, because if
you still fail timing, you can try setting ce_clk to ddr3_axi_clk (150 MHz)
or bus_clk_div2 (~93 MHz). The downside is your block's throughput will
decrease accordingly and any changes to rfnoc_ce_auto_inst_x310.v are
overwritten the next time you run uhd_image_builder.

Jonathon

On Fri, Nov 9, 2018 at 12:03 AM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> First, it's really not failing by much -- you got under 7 ns, so it's
> *almost* there.
>
> Two suggestions:
>
> 1. If the input/output of the block does not go directly into axi_wrapper,
> try adding an axi_flop at the end to insert a one-cycle delay. This could
> break up a critical path if you have a few "0-delay" blocks in a row. If
> this goes into axi_wrapper, it should probably be fine
>
> 2. This is a smoking gun:
>
> `(vector_cnt == (of_n-1)*keep_m)`
>
> See if you can find a way around the multiply operation and I expect it
> will work just fine.
>
> EJ
>
>
>
> On Thu, Nov 8, 2018 at 9:47 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> Gents, thanks for the input.  I actually found the section I needed in
>> the timing report just before you guys wrote (I hate trying to sift through
>> those).  It is indeed my block that is causing issues.  I was getting ready
>> to try to break out my testbench and start playing with it by adding some
>> registers to see if that helps (the testbench worked before, so I won't
>> know if this helps timing, but I could at least make sure I didn't break
>> anything.
>>
>> Excellent point on the clock differences.  I was stuck down a rabbit hole
>> as to why the E310 would be fine, but not the X310, but that makes sense.
>> I was just getting lucky I guess at the slower clock rates.
>>
>> Here is the relevant timing issue:
>>
>>
>> ---
>> From Clock: ce_clk
>> To Clock: ce_clk
>>
>> Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation
>> -4376.156ns
>> Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
>> PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
>>
>> ---
>>
>>
>> Max Delay Paths
>>
>> --
>> Slack (VIOLATED) : -2.711ns (required time - arrival time)
>> Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
>> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
>> fall@2.333ns period=4.667ns})
>> Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
>> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
>> fall@2.333ns period=4.667ns})
>> Path Group: ce_clk
>> Path Type: Setup (Max at Slow Process Corner)
>> Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
>> Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
>> Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
>> Clock Path Skew: -0.053ns (DCD - SCD + CPR)
>> Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
>> Source Clock Delay (SCD): -2.028ns
>> Clock Pessimism Removal (CPR): -0.422ns
>> Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
>> Total System Jitter (TSJ): 0.071ns
>> Discrete Jitter (DJ): 0.082ns
>> Phase Error (PE): 0.000ns
>>
>> (and it continues with more stuff that I don't think is particularly
>> useful).
>>
>>
>>
>> So, it is plain to see that something I am doing inside my block is very
>> stupid (though accomplishes what I wanted.  I can post the code, so maybe
>> someone can spot the issue (I really think it is a registering problem that
>> I need to do on the output side).  Please excuse the simplicity of the
>> code, I needed to through something together VERY fast, and instead of
>> being elegant, I went with easy to code up.
>>
>>
>>
>> The block's title is a little misleading, it basically keeps M vectors
>> out of N vectors.  So if the vector size is 512, and M==2 and N==10.  I
>> will pass through 1024 samples, and then dump the next 4096 samples.  Then
>> wash, rinse, repeat.  The verilog is attached since I was having trouble
>> keeping formatting when I pasted it here.
>>
>>
>>
>>
>>
>>
>> - Original Message -
>> Subject: Re: [USRP-users] rfnoc build works for E310, doesn't meet timing
>> with X310
>> From: "EJ Kreinar" 
>> Date: 11/8/18 9:09 am
>> To: "Jason Matusiak" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>> Hi Jason,
>>
>> That 

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

Hey Sam,

There have been some changes to noc_shell, maybe they are related to your
issue. If you want to try to debug this on the FPGA, I suggest using
chipscope on the file cmd_pkt_proc.v. That is the state machine that
receives command packets and issues settings bus writes. You should be able
to see your command packets come in and get processed by the state machine.
You can double check the command packet / timed command vita time versus
the radio core's vita time. You can also see if the state machine gets
stuck in a certain state.

Jonathon

On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager  wrote:

> Hi Jonathan,
>
> Just following up on this. I have switched to the UHD 3.13 release + FPGA
> version 5.2. This issue still persists.
>
> Is it possible that a change to UHD could be causing this to not work?
>
> If anyone can confirm that they are able to send commands to the radio
> block from an rfnoc block in recent versions of UHD it would help a lot.
>
> Thanks,
>
> Sam
>
> On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , wrote:
>
> Hi Jonathan,
>
> Yes I add my block and the radio block, connect them and tell my block to
> send commands to radio block. I have confirmed today that the simulation
> still works correctly in Vivado 2017.4 — the settings registers are written
> as expected, an rx command is generated in the radio and the correct number
> of samples are streamed back into the tb_streamer.
>
> Sam
> On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum ,
> wrote:
>
> How does your testbench work? Do you add the radio core block, send timed
> commands to it, and see the outputs toggle?
>
> On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  wrote:
>
>> Hi Jonathon,
>>
>> Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for
>> sharing your code — the only real difference I see is that you increment
>> the seq_num. I am leaving it as 12’b0 — could this be causing an issue?
>>
>> I should also say that In my case, the command packets are being sent to
>> the radio block to trigger timed receive commands in order to reduce the
>> number of software sr_writes.
>>
>> Here’s my code just in case: https://pastebin.com/Asgj7Jw2
>> 
>> .
>>
>> This is something that was simulated/verified and worked in the past, but
>> perhaps a change has been made that prevents this from working?
>>
>> I will try a release tag as soon as possible — however this is something
>> I’ve been seeing for a couple of months now that has kept me on pre-2017.4
>> releases.
>>
>> Sam
>> On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum ,
>> wrote:
>>
>> Hi Sam,
>>
>> I am using command packets to tune the DDC block's DSP frequency. Are you
>> using ce_clk and ce_rst for clock and reset? Here is my code if you want to
>> take a look: https://pastebin.com/1AeHFb0J
>> .
>> Also, it might be worth trying your code on a release tag like v3.13.0.2 in
>> case master has a regression.
>>
>> Jonathon
>>
>> On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> I have an RFNoC block that generates command packets to write settings
>>> registers of the downstream connected block using the Control Source
>>> (cmdout_tdata) of the noc_shell . Previously this had worked perfectly
>>> (prior to approximately d6b2283 on rfnoc-devel), for both the X300 and
>>> E310, but this functionality appears to perhaps be broken in the more
>>> recent FPGA releases — since around the switch to Vivado 2017.4 and the
>>> move of the noc block clock domain crossing to axi_wrapper.v). I have tried
>>> the latest master branch (4f25ed1) with no success.
>>>
>>> Is this a known issue? Can anyone shed light on what might have caused
>>> this?
>>>
>>> The control packets are generated in my block as follows:
>>>
>>> *wire eob = 1’b0;*
>>>
>>> *wire [1:0] pkt_type = 2'b10;*
>>>
>>> *wire [11:0] seqnum = 12'd0; // don't care*
>>>
>>> *wire [15:0] payload_length = 16'd16; //don't care (payload length in
>>> bytes)*
>>>
>>> *assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};*
>>>
>>> *cvita_hdr_encoder cvita_hdr_encoder(*
>>> *.pkt_type(pkt_type),.eob(eob), .has_time(1'b0),*
>>> *.seqnum(seqnum),*
>>> *.payload_length(payload_length),*
>>> *.src_sid(src_sid), .dst_sid(dst_sid),*
>>> *.vita_time(vita_time),*
>>> *.header(cmd_tuser)*
>>> *);*
>>>
>>> *chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (*
>>> *.clk(clk), .reset(reset), .clear(clear),*
>>> *.i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast),

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

How does your testbench work? Do you add the radio core block, send timed
commands to it, and see the outputs toggle?

On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  wrote:

> Hi Jonathon,
>
> Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for
> sharing your code — the only real difference I see is that you increment
> the seq_num. I am leaving it as 12’b0 — could this be causing an issue?
>
> I should also say that In my case, the command packets are being sent to
> the radio block to trigger timed receive commands in order to reduce the
> number of software sr_writes.
>
> Here’s my code just in case: https://pastebin.com/Asgj7Jw2.
>
> This is something that was simulated/verified and worked in the past, but
> perhaps a change has been made that prevents this from working?
>
> I will try a release tag as soon as possible — however this is something
> I’ve been seeing for a couple of months now that has kept me on pre-2017.4
> releases.
>
> Sam
> On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum ,
> wrote:
>
> Hi Sam,
>
> I am using command packets to tune the DDC block's DSP frequency. Are you
> using ce_clk and ce_rst for clock and reset? Here is my code if you want to
> take a look: https://pastebin.com/1AeHFb0J
> .
> Also, it might be worth trying your code on a release tag like v3.13.0.2 in
> case master has a regression.
>
> Jonathon
>
> On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> I have an RFNoC block that generates command packets to write settings
>> registers of the downstream connected block using the Control Source
>> (cmdout_tdata) of the noc_shell . Previously this had worked perfectly
>> (prior to approximately d6b2283 on rfnoc-devel), for both the X300 and
>> E310, but this functionality appears to perhaps be broken in the more
>> recent FPGA releases — since around the switch to Vivado 2017.4 and the
>> move of the noc block clock domain crossing to axi_wrapper.v). I have tried
>> the latest master branch (4f25ed1) with no success.
>>
>> Is this a known issue? Can anyone shed light on what might have caused
>> this?
>>
>> The control packets are generated in my block as follows:
>>
>> *wire eob = 1’b0;*
>>
>> *wire [1:0] pkt_type = 2'b10;*
>>
>> *wire [11:0] seqnum = 12'd0; // don't care*
>>
>> *wire [15:0] payload_length = 16'd16; //don't care (payload length in
>> bytes)*
>>
>> *assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};*
>>
>> *cvita_hdr_encoder cvita_hdr_encoder(*
>> *.pkt_type(pkt_type),.eob(eob), .has_time(1'b0),*
>> *.seqnum(seqnum),*
>> *.payload_length(payload_length),*
>> *.src_sid(src_sid), .dst_sid(dst_sid),*
>> *.vita_time(vita_time),*
>> *.header(cmd_tuser)*
>> *);*
>>
>> *chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (*
>> *.clk(clk), .reset(reset), .clear(clear),*
>> *.i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast),
>> .i_tvalid(cmd_tvalid), .i_tready(cmd_tready),*
>> *.o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast),
>> .o_tvalid(cmdout_tvalid), .o_tready(cmdout_tready));*
>>
>> The command packets appear to never reach the destination rfnoc block,
>> but I am at a loss for the cause.
>>
>> Is anyone currently using the control source functionality of the
>> noc_shell? I would really appreciate any pointers on how to fix this.
>>
>> Thank you,
>>
>> Sam
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

Hi Sam,

I am using command packets to tune the DDC block's DSP frequency. Are you
using ce_clk and ce_rst for clock and reset? Here is my code if you want to
take a look: https://pastebin.com/1AeHFb0J. Also, it might be worth trying
your code on a release tag like v3.13.0.2 in case master has a regression.

Jonathon

On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have an RFNoC block that generates command packets to write settings
> registers of the downstream connected block using the Control Source
> (cmdout_tdata) of the noc_shell . Previously this had worked perfectly
> (prior to approximately d6b2283 on rfnoc-devel), for both the X300 and
> E310, but this functionality appears to perhaps be broken in the more
> recent FPGA releases — since around the switch to Vivado 2017.4 and the
> move of the noc block clock domain crossing to axi_wrapper.v). I have tried
> the latest master branch (4f25ed1) with no success.
>
> Is this a known issue? Can anyone shed light on what might have caused
> this?
>
> The control packets are generated in my block as follows:
>
> *wire eob = 1’b0;*
>
> *wire [1:0] pkt_type = 2'b10;*
>
> *wire [11:0] seqnum = 12'd0; // don't care*
>
> *wire [15:0] payload_length = 16'd16; //don't care (payload length in
> bytes)*
>
> *assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};*
>
> *cvita_hdr_encoder cvita_hdr_encoder(*
> *.pkt_type(pkt_type),.eob(eob), .has_time(1'b0),*
> *.seqnum(seqnum),*
> *.payload_length(payload_length),*
> *.src_sid(src_sid), .dst_sid(dst_sid),*
> *.vita_time(vita_time),*
> *.header(cmd_tuser)*
> *);*
>
> *chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (*
> *.clk(clk), .reset(reset), .clear(clear),*
> *.i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast),
> .i_tvalid(cmd_tvalid), .i_tready(cmd_tready),*
> *.o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), .o_tvalid(cmdout_tvalid),
> .o_tready(cmdout_tready));*
>
> The command packets appear to never reach the destination rfnoc block, but
> I am at a loss for the cause.
>
> Is anyone currently using the control source functionality of the
> noc_shell? I would really appreciate any pointers on how to fix this.
>
> Thank you,
>
> Sam
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 FP GPIO with RFNoC API

[Jon Pendlum via USRP-users]

Hey Ryan,

I have a PR that adds custom I/O support for RFNoC blocks with FPGPIO
support as part of that. It is still being looked at internally at Ettus,
but I'll send you a patch to try it out.

Jonathon

On Fri, Oct 5, 2018, 5:59 AM Ryan Marlow via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Working on a project with custom RFNoC blocks where I need to use the FP
> GPIO. I've searched the mailing lists and seen previously suggested options
> like reconnecting fp gpio to the custom block, or generating timed command
> packets from my block to send to the radio block. Both those options seem
> feasible but what seems to be the most straightforward option is to just
> use the uhd api call: set_gpio_attr. Like in this example:
> https://files.ettus.com/manual/page_gpio_api.html
> I tried instantiating a multi_usrp object in my rfnoc app, but that
> doesn't seem like the right path and produces some unexpected results.
> I noticed that the radio_ctrl API includes that function but all it does
> is
>
>> throw uhd::not_implemented_error("set_gpio_attr was not defined for
>> this radio");
>>
> Is there some other way using the device3/RFNoC api to use the
> set_gpio_attr or some similar function to configure the gpio from software?
> Or more importantly is it even possible when using RFNoC to use those
> software functions?
> Thanks,
> Ryan Marlow
>
> --
> Ryan L. Marlow
> R L Marlow Consulting LLC
> rlmarlow.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC OFDM blocks error building FPGA image

[Jon Pendlum via USRP-users]

Hi Sarah,

I have submitted a pull request with some OFDM improvements including a fix
for this issue, hopefully it will be merged soon. I'll send you the patch
set to try out in the meantime.

Jonathon

On Fri, Sep 28, 2018 at 11:05 AM Sarah Tran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
> I am trying to build a custom FPGA image for my X310
> (daughterboards=UBX-160) using the uhd_image_builder gui and trying to use
> the following blocks:
>
> fft
>
> schmidl_cox
>
> eq
>
> ofdm_constellation_demapper
>
>
> as the code is running and building, it always stops on this error:
>
> '
> [00:22:41] Current task: Logic Optimization +++ Current Phase: Finished
> [00:22:41] Starting Connectivity Check Task
> ERROR: [Opt 31-2] SRLC32E
> x300_core/inst_eq/inst_axi_wrapper/header_fifo/fifo_short/gen_srlc32e[64].srlc32e
> is missing a connection on D pin.
> [00:22:51] Current task: Connectivity Check +++ Current Phase: Starting
> [00:22:51] Current task: Connectivity Check +++ Current Phase: Finished
> [00:22:51] Process terminated. Status: Failure
>
> 
> Warnings:   862
> Critical Warnings:  36
> Errors: 1
>
> Makefile.x300.inc:111: recipe for target 'bin' failed
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory '/home/lsop/rfnoc/fpga/usrp3/top/x300'
> Makefile:119: recipe for target 'X310_RFNOC_HG' failed
> make: *** [X310_RFNOC_HG] Error 2'
>
> I can't seem to get it resolved, and I was wondering if there was a trick
> that someone else was able to use to get it to build. Any help or insight
> is appreciated.
>
> Thank you,
> Sarah
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] max usable SPP on the E310

[Jon Pendlum via USRP-users]

Hey Jason,

Yes 512 is the max SPP, due to the 4k max DMA transfer size. To support
larger FFTs, you could modify the FFT noc block to split up the frames
between multiple packets and issue an EOB on the last packet. I have tried
that in the past and had some success.

Jonathon

On Tue, Sep 25, 2018 at 8:54 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is the max usable SPP size on the E310 capped at 512?  In my flowgraph, I
> have an RFNoC FFT block.  I know that the SPP needs to be set to the size
> of the FFT to make things happy and using 512 seems to work fine.  As soon
> as I step up to 1024 I see a lot of errors:
>
>
> RFNoC Streamer block received error ERROR_CODE_BAD_PACKET (Code: 0xf)
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: Bad CHDR or packet fragment
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: Bad CHDR or packet fragment
> RFNoC Streamer block received error ERROR_CODE_BAD_PACKET (Code: 0xf)
> timeout on chan 0
> timeout on chan 0
> RFNoC Streamer block received error ERROR_CODE_BAD_PACKET (Code: 0xf)
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: Bad CHDR or packet fragment
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: Bad CHDR or packet fragment
>
> (over and over)
>
> I know that when using an X310 it is sometimes necessary to increase the
> MTU size when you want to be able to have larger SPPs, but the E310 doesn't
> use an ethernet interface, so I don't know if there is an analogous
> approach that can be taken here (and reading this comment from a few years
> back supports my thought, at least as of 2015:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-December/017356.html).
> I also tried a flowgraph with just a radio and a keep-1-in-N and I still
> get the same errors with an SPP=1024, so it isn't the FFT causing the
> issues.
>
> So is SPP=512 the max usable value and is there anything I can do to
> increase it so I can use a larger FFT size on the E310?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] general RFNoC timing question

[Jon Pendlum via USRP-users]

Hey Jason,

In regards to your original post, I wonder if the issue is due to the split
stream block. Perhaps it has a bubble state and cannot keep up at full
rate. Have you tried moving the Keep One in N before the split stream?

Jonathon

On Tue, Sep 25, 2018 at 10:07 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, now I am really confused.
>
> Part of my math issue seems to be that I set the "sample rate" in the
> RFNoC radio to be my sample_rate because I knew I could ignore due to the
> lack of DDC (it would then be set to the master clock rate).
>
> When I run my flowgraph, I see that the master clock rate is getting set
> properly (if I use a bad value, it tells me), but it seems to be running at
> the sample rate that is in there (so if I say 25MHz, it will do that
> instead of the 56MHz the master clock rate is set to).  As far as I know,
> this shouldn't happen since I don't have a DDC in my bitfile to allow this
> (nor is it in my flowgraph).
>
> BUT, if I run a benchmark_rate test and set the --rx_rate to be 25e6, it
> says that it can't do that and it sets it to be the master clock rate.
>
> So what gives?  Is something happening on the GR side that is doing
> something odd with the sample rate?  This doesn't add up to me.
>
>
>
> - Original Message -
> Subject: general RFNoC timing question
> From: "Jason Matusiak" 
> Date: 9/24/18 2:48 pm
> To: "Ettus Mail List" 
>
> I have a flowgraph I am running on an E310 using all stock RFNoC blocks.
> It looks a lot like this:
>
>
> RFNoC:Radio ---> RFNoC: Split Stream ---> RFNoC: FFT ---> RFNoC: Keep 1 in
> N ---> RFNoC: Log Power > GR: complex to float  ---> GR:Raster Sink
>   |
>   |
>
> ---> RFNOC: Keep 1 in N ---> GR: log Power FFT ---> GR: custom block --->
> GR: Raster sink
>
> So no DDC in the flowgraph.  If I run the master_clock_rate at 56MHz, the
> sample rate should be the same (I have SPP=512, and that is the size of the
> FFT as well).  I would then think that the pair of Keep 1 in Ns should
> basically divide down the rate by N.  So if I have them set to 56e3, that
> means I should get a sample rate that averages out to be 1KHz out each of
> the two streams to host for a total of 2KHz.  I know that the E310 can
> stream 10MHz no problem to the ARM, so I am not sure why in this scenario I
> get a ton of:
>
> Ooverrun on chan 0
> Ooverrun on chan 0
> Ooverrun on chan 0
> Ooverrun on chan 0
> Ooverrun on chan 0
> Ooverrun on chan 0
> Ooverrun on chan 0
>
> Now why would that be?  I have no idea.
>
>
>
> I set my downstream sample rate (on the GR host) to be
> sample_rate/keep1inN.  I bring this up because in the case about
> sample_rate is the same as master_clock_rate.  If I reduce the sample_rate
> to be 40MHz (which gets ignored by the E310 since I don't have a DDC, but
> gets used in the down stream sample rate for the raster guis, I can set the
> keep1inN up to the max of 65535 and there are no overflows.  There are
> "timeout on chan 0" errors, but I think that is because RFNoC must be
> timing out somewhere du to the throughput being so slow.
>
> Does this make sense?  Does anyone have an idea what I am doing stupidly
> wrong?  I have a feeling I am violating timing somewhere, but I can't
> figure out where
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Pulling in AXI_FFT into a OOT module and block

[Jon Pendlum via USRP-users]

I see now. Simulation is a bit different than building images. To prevent
building every IP for every simulation, the exact IP you want to use needs
to be added to the test bench Makefile. It is pretty easy. Add the
following to the test bench Makefile in rfnoc/testbenches//Makefile:

LIB_IP_DIR = $(BASE_DIR)/../lib/ip
include $(LIB_IP_DIR)/axi_fft/Makefile.inc
DESIGN_SRCS += $(abspath \
$(LIB_IP_AXI_FFT_SRCS) \
)

If you are curious where this comes from, take a look at
usrp3/lib/rfnoc/noc_block_fft_tb/Makefile in the FPGA repo. I can see how
it is confusing and it needs to be documented somewhere.

As for using your own version of the axi_fft IP, you will need to copy it
locally to the IP directory. It is usually easiest to import or create the
IP in Vivado, configure as needed, generate the IP output products, and
copy over the .xci file.

Jonathon

On Sat, Sep 15, 2018 at 3:32 AM Rich Maes  wrote:

> I did follow that Getting Started guide and produce the text book
> rfnoc_tutorial OOT module and simulated it without issue.
>
> Then next thing I did was to create a second OOT module and name it
> nd_fft.  So the same generic OOT module with a different name.  That too
> simulated without issue.
>
> So now what I wanted to do was to take the stock FFT and place it into my
> new module.  So I took the RTL and the test.  I then tried to simulate and
> the error that came back was that module axi_fft was unresolved.  So the
> top level model did build, but the underlying IP was not in the search
> path.
>
> Based on what you are saying, I kind of expected that the axi_fft should
> have been in the default search path already.  Would you say that was
> unexpected behavior for the standard OOT module?
>
> I will look at your bullets below and provide feedback tonight.  I see
> what you are saying about modifying the .xci.  Am I supposed to copy the
> axi_fft IP to this ejk43/rfnoc-ootexample path to make it local?  I am
> guessing that bullet 2, could be a path back to the original IP so I don’t
> have to copy it.
>
>
>
> On Sep 14, 2018, at 8:20 AM, Jon Pendlum  wrote:
>
> Hi Rich,
>
> The standard Ettus in-tree Vivado IP, which includes the axi_fft, is
> automatically included. You do not need to do anything. Have you went
> through the RFNoC getting started guide (
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development)? I think
> that will help you understand the FPGA build process. The key concept to
> understand is that building the FPGA is separate from building your OOT
> module. The FPGA build Makefile exists in the Ettus FPGA repo and pulls in
> files from that repo. That is why you do not need to include any Ettus
> in-tree files, the Makefile will include them automatically.
>
> When you get to the point of adding your custom IP, you need to do these
> things:
> 1) Use this IP as a template on how to add your IP:
> https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/ip/complex_to_magphase_oot/.
> It is usually as simple as adding your .xci file and some renaming.
> 2) Add your IP to this file:
> https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/ip/Makefile.inc
> 3) Make sure you have this line:
> https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/Makefile.inc#L6
> 4) Use uhd_image_build_gui to import your OOT module and build your
> bitstream. See the RFNoC getting started guide.
>
>
> Jonathon
>
> On Fri, Sep 14, 2018 at 10:40 PM Rich Maes via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> So I have looked at the ejk43/rfnoc-ootexample and I have been trying to
>> apply what I think I am seeing.  Truth in advertising, I an FPGA engineer,
>> and I don’t usually get into Makefiles or CMakeLists.txt very much.
>>
>> I think the correct thing to do is to modify the CMakeLists.txt so that
>> when cmake is run, the the new Makefiles are generated with the correct
>> content.
>>
>> All I want to do, I believe right now is pull in the axi_fft IP. My next
>> will be to follow the advice of one of the respondents and build the IP
>> local to the OOT module, but I am still not certain how I am suppose to
>> reference it correctly.  Just trying to get a list of what needs to be
>> touched to get the standard OOT to look an IP directory.
>>
>>  What I have done is this:
>>
>> modify this line to include FFT
>>
>> set(GR_REQUIRED_COMPONENTS RUNTIME FFT)
>>
>>
>> and then later, I included this chunk in my
>> ~/rfnoc/src/rfnoc-nd_fft/CMakeLists.txt file
>>
>> 
>> # Setup CPack components
>> 
>> include(GrPackage)
>> CPACK_SET(CPACK_COMPONENT_GROUP_FFT_DESCRIPTION "GNU Radio FFT Blocks")
>>
>> CPACK_COMPONENT("fft_runtime"
>> GROUP"FFT"
>> DISPLAY_NAME "Runtime"
>> DESCRIPTION  "Runtime"
>> DEPENDS  "runtime_runtime"
>> )
>>
>> CPACK_COMPONENT("fft_devel"
>> GROUP"FFT"
>> DISPLAY_NAME 

Re: [USRP-users] Pulling in AXI_FFT into a OOT module and block

[Jon Pendlum via USRP-users]

Hi Rich,

The standard Ettus in-tree Vivado IP, which includes the axi_fft, is
automatically included. You do not need to do anything. Have you went
through the RFNoC getting started guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_Development)? I think that
will help you understand the FPGA build process. The key concept to
understand is that building the FPGA is separate from building your OOT
module. The FPGA build Makefile exists in the Ettus FPGA repo and pulls in
files from that repo. That is why you do not need to include any Ettus
in-tree files, the Makefile will include them automatically.

When you get to the point of adding your custom IP, you need to do these
things:
1) Use this IP as a template on how to add your IP:
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/ip/complex_to_magphase_oot/.
It is usually as simple as adding your .xci file and some renaming.
2) Add your IP to this file:
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/ip/Makefile.inc
3) Make sure you have this line:
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/Makefile.inc#L6
4) Use uhd_image_build_gui to import your OOT module and build your
bitstream. See the RFNoC getting started guide.


Jonathon

On Fri, Sep 14, 2018 at 10:40 PM Rich Maes via USRP-users <
usrp-users@lists.ettus.com> wrote:

> So I have looked at the ejk43/rfnoc-ootexample and I have been trying to
> apply what I think I am seeing.  Truth in advertising, I an FPGA engineer,
> and I don’t usually get into Makefiles or CMakeLists.txt very much.
>
> I think the correct thing to do is to modify the CMakeLists.txt so that
> when cmake is run, the the new Makefiles are generated with the correct
> content.
>
> All I want to do, I believe right now is pull in the axi_fft IP. My next
> will be to follow the advice of one of the respondents and build the IP
> local to the OOT module, but I am still not certain how I am suppose to
> reference it correctly.  Just trying to get a list of what needs to be
> touched to get the standard OOT to look an IP directory.
>
>  What I have done is this:
>
> modify this line to include FFT
>
> set(GR_REQUIRED_COMPONENTS RUNTIME FFT)
>
>
> and then later, I included this chunk in my
> ~/rfnoc/src/rfnoc-nd_fft/CMakeLists.txt file
>
> 
> # Setup CPack components
> 
> include(GrPackage)
> CPACK_SET(CPACK_COMPONENT_GROUP_FFT_DESCRIPTION "GNU Radio FFT Blocks")
>
> CPACK_COMPONENT("fft_runtime"
> GROUP"FFT"
> DISPLAY_NAME "Runtime"
> DESCRIPTION  "Runtime"
> DEPENDS  "runtime_runtime"
> )
>
> CPACK_COMPONENT("fft_devel"
> GROUP"FFT"
> DISPLAY_NAME "Development"
> DESCRIPTION  "C++ headers, package config, import libraries"
> DEPENDS  "runtime_devel"
> )
>
> CPACK_COMPONENT("fft_python"
> GROUP"FFT"
> DISPLAY_NAME "Python"
> DESCRIPTION  "Python modules for runtime; GRC xml files"
> DEPENDS  "runtime_python;fft_runtime"
> )
>
> CPACK_COMPONENT("fft_swig"
> GROUP"FFT"
> DISPLAY_NAME "SWIG"
> DESCRIPTION  "SWIG development .i files"
> DEPENDS  "runtime_swig;fft_python;fft_devel"
> )
>
> 
> # Add subdirectories
> 
> add_subdirectory(include/gnuradio/fft)
> add_subdirectory(lib)
> if(ENABLE_PYTHON)
> add_subdirectory(swig)
> add_subdirectory(python/fft)
> add_subdirectory(grc)
> endif(ENABLE_PYTHON)
> add_subdirectory(docs)
>
> 
> # Create Pkg Config File
> 
> configure_file(
> ${CMAKE_CURRENT_SOURCE_DIR}/gnuradio-fft.pc.in
> ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-fft.pc
> @ONLY)
>
> install(
> FILES ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-fft.pc
> DESTINATION ${GR_LIBRARY_DIR}/pkgconfig
> COMPONENT "fft_devel"
> )
>
>
>
>
> I also added this because cmake complained that it could not find
> GnuradioConfig.cmake
>
> install(FILES ../../../../src/gnuradio/GnuradioConfig.cmake
> DESTINATION ${CMAKE_MODULES_DIR}/gnu_radio
> )
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC

[Jon Pendlum via USRP-users]

Hey Steve,

The complex_to_mag_phase 32-bit output is a concatenation:  [31:16] phase,
[15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want
24-bit phase, mag. The phase value is in scaled radians. If you want a
different phase precision, you will need to create a new CORDIC IP
instance. Using the data with RFNoC, you have two options: 1) choose a
precision that will work with the built in UHD converters. see:
https://files.ettus.com/manual/page_converters.html or 2) handle the
conversion on your own. In either case, AXI Wrapper expects 32-bit data, so
you can concatenate or sign extend your data however works best for you.

Jonathon

On Tue, Sep 4, 2018 at 8:48 PM shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create a "complex-to-phase" by using the arctan within the
> Xilinx CORDIC IP.
> (Part of a simple fft-->1-in-N-->to-phase scheme).
> Quite frankly I am a bit confused with the different bit representations.
>
> According to the Xilinx manual (
> https://www.xilinx.com/support/documentation/ip_documentation/cordic/v6_0/pg105-cordic.pdf),
> the phase is represented by a 3QN format. How can such a format fit into an
> RFNoC design?
>
> Note: Is there a simpler way to calculate a complex-to-phase in RFNoC?
> I've noticed a "complex_to_mag_phase.v" within usrp3->lib->corgen, But I
> couldn't figure out whether the 32-bit output is a magnitude or a phase
>
> Thnx a lot,
> Steve
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Pulling in AXI_FFT into a OOT module and block

[Jon Pendlum via USRP-users]

If you only need integer decimation, noc_block_ddc should have everything
you need or close to it. Averaging across FFTs can be done with
noc_block_vector_iir. For an example, check out the
flowgraph rfnoc_vector_iir.grc in gr-ettus.

Jonathon

On Tue, Sep 4, 2018 at 3:23 PM Rich Maes  wrote:

> I’d like to add a configurable decimator and some averaging logic to the
> output of the FFT.  So I’ll be adding some new registers to the control
> bloc and verilog, but the overall core will still be very similar.
>
> I’ll take a look at the examples you reference below to see if that gets
> me going in the right direction.  Thanks.
> Rich
>
> On Sep 3, 2018, at 8:43 PM, Jon Pendlum  wrote:
>
> Hey Rich,
>
> Do you want to customize the FFT IP or use it as is? If you are using it
> as is, there is no need to do anything. All in-tree code and IP is
> automatically included as part of the FPGA build. If you want to customize
> it, I suggest copying the FFT IP into your OOT and using
> https://github.com/ejk43/rfnoc-ootexample as an example on how to add it
> (see the rfnoc/ip directory). Use viv_modify_ip (available after you source
> setupenv.sh) to customize the FFT IP. You'll want to rename it as well so
> it does not conflict with the in-tree FFT IP.
>
> Jonathon
>
> On Tue, Sep 4, 2018 at 9:58 AM Rich Maes via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Is there an example of modifying a out of tree (OOT) module and block to
>> pull in a rfnoc library.  Specifically I would like to pull in the AXI_FFT
>> generated code and make my own custom FFT block.  I can’t quite figure out
>> how to modify the CMAKE files, (I assume that is the proper method) to
>> reference that RFNOC library/source.
>>
>> Thanks in advance.
>> Rich
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Pulling in AXI_FFT into a OOT module and block

[Jon Pendlum via USRP-users]

Hey Rich,

Do you want to customize the FFT IP or use it as is? If you are using it as
is, there is no need to do anything. All in-tree code and IP is
automatically included as part of the FPGA build. If you want to customize
it, I suggest copying the FFT IP into your OOT and using
https://github.com/ejk43/rfnoc-ootexample as an example on how to add it
(see the rfnoc/ip directory). Use viv_modify_ip (available after you source
setupenv.sh) to customize the FFT IP. You'll want to rename it as well so
it does not conflict with the in-tree FFT IP.

Jonathon

On Tue, Sep 4, 2018 at 9:58 AM Rich Maes via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is there an example of modifying a out of tree (OOT) module and block to
> pull in a rfnoc library.  Specifically I would like to pull in the AXI_FFT
> generated code and make my own custom FFT block.  I can’t quite figure out
> how to modify the CMAKE files, (I assume that is the proper method) to
> reference that RFNOC library/source.
>
> Thanks in advance.
> Rich
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem running RFNoC testbench all of a sudden

[Jon Pendlum via USRP-users]

Hey Jason,

I ran into this problem too when I had a syntax error in sim_rfnoc_lib.svh
(I was messing around with the core RFNoC testbench infrastructure code).
After I fixed my typo, it went away. I suspect this is just a bug in xsim.

Jonathon

On Wed, Aug 8, 2018 at 9:52 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am not sure what I've done, but all of a sudden I don't seem to be able
> to run my testbench.  Things are in the "compiling" stage of the testbench
> when I get hit with this:
>
>
>
>
>
> *Built simulation snapshot ddc_chain_behav*
>
> *** Webtalk v2017.4 (64-bit)*
> *  SW Build 2086221 on Fri Dec 15 20:54:30 MST 2017*
> *  IP Build 2085800 on Fri Dec 15 22:25:07 MST 2017*
> * ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.*
>
> *source
> /opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim/xsim.dir/ddc_chain_behav/webtalk/xsim_webtalk.tcl
> -notrace*
> *INFO: [Common 17-186]
> '/opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim/xsim.dir/ddc_chain_behav/webtalk/usage_statistics_ext_xsim.xml'
> has been successfully sent to Xilinx on Wed Aug 8 08:40:08 2018. For
> additional details about this file, please refer to the WebTalk help file
> at /opt/Xilinx/Vivado/2017.4/doc/webtalk_introduction.html.*
> *INFO: [Common 17-206] Exiting Webtalk at Wed Aug 8 08:40:08 2018...*
> *run_program: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB):
> peak = 1340.074 ; gain = 0.000 ; free physical = 48514 ; free virtual =
> 292443*
> *INFO: [USF-XSim-69] 'elaborate' step finished in '5' seconds*
> *INFO: [USF-XSim-4] XSim::Simulate design*
> *INFO: [USF-XSim-61] Executing 'SIMULATE' step in
> '/opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim'*
> *INFO: [USF-XSim-98] *** Running xsim*
> * with args "ddc_chain_behav -key {Behavioral:sim_1:Functional:ddc_chain}
> -tclbatch {ddc_chain.tcl} -log {simulate.log}"*
> *INFO: [USF-XSim-8] Loading simulator feature*
> *Vivado Simulator 2017.4*
> *Time resolution is 1 ps*
> *source ddc_chain.tcl*
> *## current_wave_config*
> *ERROR : The following component DSP48A1 at instance
> ddc_chain.old_hb.small_hb_i.mult.dsp_st.DSP48AST is not supported for
> retargeting in this architecture. Please modify your source code to use
> supported primitives. The complete list of supported primitives for this
> architectures is provided in the 7 Series HDL Libraries Guide available on
> www.xilinx.com .*
> *$finish called at time : 0 fs : File
> "/wrk/2017.4/nightly/2017_12_15_2086221/data/verilog/src/retarget/DSP48A1.v"
> Line 74*
> *INFO: [USF-XSim-96] XSim completed. Design snapshot 'ddc_chain_behav'
> loaded.*
> *INFO: [USF-XSim-97] XSim simulation ran for 10us*
> *launch_simulation: Time (s): cpu = 00:00:12 ; elapsed = 00:00:16 . Memory
> (MB): peak = 1407.582 ; gain = 112.375 ; free physical = 48509 ; free
> virtual = 292438*
> *# if [string equal $vivado_mode "batch"] {*
> *# puts "BUILDER: Closing project"*
> *# close_project*
> *# } else {*
> *# puts "BUILDER: In GUI mode. Leaving project open."*
> *# }*
> *BUILDER: Closing project*
>
>
>
> I didn't update UHD or anything like that, so I can't figure out what I've
> done wrong.  I assume the DSP48A1 is because I am attempting to use most of
> the siggen code in my block.  This seemed to be working fine, and then this
> hit all of a sudden.
>
> Any thoughts?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] packet size for RFNOC testbenches

[Jon Pendlum via USRP-users]

Hey Jason,

You could try testing with noc_block_skeleton. It only does a loopback and
has a self checking testbench.

Jonathon

On Mon, Aug 20, 2018, 11:48 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have been trying to figure out an issue with my block for a while, and
> it dawned on me that I might be barking up the wrong tree.
>
> I would like to send a lot of data for my test (say 5000+ samples).  I
> noticed that things seem to get hosed after 496 samples.  It might be an
> issue with my block, but I am wondering if maybe it had something to do
> with the way the testbenches work.
>
> I tried splitting up the data into two testbenches of roughly 300 samples,
> but it still seems to die on the second test bench when it hits the 496th
> sample (my block that is).
>
> Are there any examples of a testbench where a LOT of samples are sent
> through (in real life, my block stops after a certain number of samples, so
> I wanted to replicate it in my testbench)?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] about rfnoc nocshell

[Jon Pendlum via USRP-users]

Hi Carry,

Unless you left out some more details, it sounds like you just want to
transmit. In that case you should use the regular UHD API and you can
ignore my previous suggestions. Take a look at the examples
tx_waveforms.cpp and tx_samples_from_file.cpp for how to use the UHD API.

Jonathon

On Fri, Aug 10, 2018 at 6:26 PM, carry chen  wrote:

> Thanks Jonathon!
>
> I want to send some data block to radio. I need to use uhd on arm and send
> the data. now I want to put the data block on ps memory, and access the
> data block in pl, so I can send the data block in PL direct!
>
> can I setup  my own datamover on another HP AXI port under uhd fpga
> framework? I use uhd-003012,no rfnoc.
>
>
> Thanks again!
>
>
> Best Regards,
>
> Carry
> --
> *From:* Jon Pendlum 
> *Sent:* Thursday, August 9, 2018 3:44:43 AM
>
> *To:* carry chen
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] about rfnoc nocshell
>
> Hi.
>
> Yes, but you should leave that one alone and setup your own datamover
> on another HP AXI port. What do you want to accomplish?
>
> Jonathon
>
> On Sun, Aug 5, 2018 at 11:44 AM, carry chen 
> wrote:
> >
> > Thanks Jonathon!
> > Does uhd fpga use datamover access PS DDR now?
> >
> > Best Regards,
> > Carry
> >
> > 
> > From: Jon Pendlum 
> > Sent: Monday, July 30, 2018 7:57 PM
> > To: carry chen
> > Cc: usrp-users@lists.ettus.com
> > Subject: Re: [USRP-users] about rfnoc nocshell
> >
> > Hi,
> >
> > 1) You cannot reduce noc_shell resource usage much. You can try
> > putting all your custom logic in just one RFNoC block, that way you do
> > not incur the overhead of multiple noc_shell instances.
> > 2) Do you mean "Can I access PS DDR memory directly from the FPGA
> > fabric?" If so, yes you can via the HP AXI ports. You'll need
> > something to interface with the HP AXI port though. Xilinx's AXI
> > Datamover or AXI DMA IP blocks are decent choices.
> >
> > Jonathon
> >
> > On Fri, Jul 6, 2018 at 3:26 AM, carry chen via USRP-users
> >  wrote:
> >> hello,list,
> >>
> >> I have study the rfnoc,I have 2 question:
> >> 1. I find nocshell module use large resource, e310 resource is less, so
> >> can
> >> I adjust some param to reduce the resoure comsume? I only config one
> >> radio(1
> >> ddc+1 duc),I find use so many resouce
> >> 2.Can I share memory between ps and pl direct?
> >>
> >> Best,Regards,
> >> Carry
> >>
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Debugging RFNoC siggen

[Jon Pendlum via USRP-users]

Hi Koen,

Your block should not wait on tready, that is a violation of the AXI spec.
Some blocks actually wait for tvalid to be asserted before asserting tready
(that is permitted by the spec), which would cause a deadlock in your
situation. You can work around that by putting an axi_flip_flop in the path
since it will always assert tready when it can.

However, I don't think that is your issue. You should be interfacing your
logic with the AXI wrapper instance in your block. AXI wrapper's
s_axis_data_tready signal essentially connects to a FIFO, so you should see
it assert. Do you see that?

Jonathon


On Fri, Aug 10, 2018, 5:52 PM TIMMEN Koen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
>
>
> Last week I posted a question, on how I could confirm that a custom RFNoC
> signal generator (piloted from a UHD API) functioned as intended. I
> received the tip to probe my block using the Vivado ILA. A great idea,
> because I did not know this existed (I am quite new in FPGA design) and it
> is a useful tool.
>
>
>
> Now, I was able to confirm that my custom block is functioning as intended
> by placing an ILA internal to it. However, no actual samples are ever
> generated due to a design choice I made; sample generation is only
> triggered when the block receives a tready signal from a downstream block.
> In this case a DUC block. In other words, the block stays dormant, waiting
> to receive a trigger.
>
>
>
> That leaves me with the question why it never receives this signal. Could
> someone explain to me at what point a DUC block will assert its tready
> signal? I was under the impression that as soon as I connected the blocks
> (using uhd::rfnoc::graph::connect()) as follows: SIGGEN à DUC à Radio,
> the DUC and Radio blocks would be asserting their ready samples directly
> after. But apparently this is not the case.
>
>
>
> Thank you for your replies,
>
>
>
> Koen
>
>
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] about rfnoc nocshell

[Jon Pendlum via USRP-users]

Hi.

Yes, but you should leave that one alone and setup your own datamover
on another HP AXI port. What do you want to accomplish?

Jonathon

On Sun, Aug 5, 2018 at 11:44 AM, carry chen  wrote:
>
> Thanks Jonathon!
> Does uhd fpga use datamover access PS DDR now?
>
> Best Regards,
> Carry
>
> 
> From: Jon Pendlum 
> Sent: Monday, July 30, 2018 7:57 PM
> To: carry chen
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] about rfnoc nocshell
>
> Hi,
>
> 1) You cannot reduce noc_shell resource usage much. You can try
> putting all your custom logic in just one RFNoC block, that way you do
> not incur the overhead of multiple noc_shell instances.
> 2) Do you mean "Can I access PS DDR memory directly from the FPGA
> fabric?" If so, yes you can via the HP AXI ports. You'll need
> something to interface with the HP AXI port though. Xilinx's AXI
> Datamover or AXI DMA IP blocks are decent choices.
>
> Jonathon
>
> On Fri, Jul 6, 2018 at 3:26 AM, carry chen via USRP-users
>  wrote:
>> hello,list,
>>
>> I have study the rfnoc,I have 2 question:
>> 1. I find nocshell module use large resource, e310 resource is less, so
>> can
>> I adjust some param to reduce the resoure comsume? I only config one
>> radio(1
>> ddc+1 duc),I find use so many resouce
>> 2.Can I share memory between ps and pl direct?
>>
>> Best,Regards,
>> Carry
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>

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

Re: [USRP-users] noc_block_null_source_sink module

[Jon Pendlum via USRP-users]

You cannot have a block with 0 inputs or 0 outputs from the HDL
perspective. You will always have at least 1 input and 1 output. You
can tie off the unused input or output though. Also, in your GRC XML,
you can choose not to declare the output or input. Check out
uhd_rfnoc_siggen.xml, which works just fine as a 0-input 1-output
block even though siggen.xml has a "dump" input declared.

On Wed, Aug 1, 2018 at 1:40 AM, Jason Matusiak
 wrote:
> What I don't understand is, why is the null sink able to have one input and
> no outputs?  I would think that it would suffer the same issues that a 2-in
> 1-out block would have.
>
> I tried to understand the noc_block_null_source_sink.v, but I didn't really
> see how to use it as a sink only.  I was going to create my own, but then I
> had the question from above.
>
> I am a little worried about the constraints that the block-to-block
> messaging has, so I was going to change my block to a 2-in 1-out block, but
> then remembered those issues.  Then my answer was to make it 2-in 2-out
> (like it is now), but connected a null sink to the unneeded output.
>
> Any words of wisdom?
>
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] noc_block_null_source_sink module
> From: "Jon Pendlum" 
> Date: 7/30/18 10:49 pm
> To: "Jason Matusiak" 
> Cc: "Ettus Mail List" 
>
> Hey Jason,
>
> The block is functionally complete, in fact I think it was the first
> block ever made. There is a UHD C++ example,
> rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC
> xml for GNU Radio needs to be created though.
>
> Jonathon
>
> On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users
>  wrote:
>> I was having trouble finding information on this block. I could see its
>> usefulness in an application I am looking into, but I wasn't sure how
>> complete the block was (I don't really see anything using it, nor a GRC
>> xml
>> file for it).
>>
>> Thanks
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>

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

Re: [USRP-users] RFNoC flowgraph runs right the second time

[Jon Pendlum via USRP-users]

Hey Jason,

Have you tried using a smaller SPP such as 256?

Jonathon

On Thu, Jul 26, 2018 at 2:39 AM, Jason Matusiak via USRP-users
 wrote:
> So, somehow I got things working for the first run in a certain situation.
> I attached 2 pictures to show my flowgraphs.  Again, my LBT block is
> currently just swapping the inputs to the outputs (in0 -> out1 and in1 ->
> out0).
>
> The working image seems to work everytime.
>
> The non-working image, seems to never work anymore (I get those "timeout on
> channel 0" errors).
>
> Currently, my swapping is like the RFNoC loopback example.  What I wonder
> is, could I be having some sort of issues due to back-pressure or something.
> I tried with some DMA-FIFOs around, but that didn't seem to help in any way.
>
> This is my swap:
>
> assign m_axis_data_tready[1] = s_axis_data_tready[0];
> assign s_axis_data_tvalid[1] = m_axis_data_tvalid[0];
> assign s_axis_data_tlast[1] = m_axis_data_tlast[0];
> assign s_axis_data_tdata[63:32] = m_axis_data_tdata[31:0];
>
> assign m_axis_data_tready[0] = s_axis_data_tready[1];
> assign s_axis_data_tvalid[0] = m_axis_data_tvalid[1];
> assign s_axis_data_tlast[0] = m_axis_data_tlast[1];
> assign s_axis_data_tdata[31:0] = m_axis_data_tdata[63:32];
>
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] RFNoC flowgraph runs right the second time
> Date: 7/25/18 10:42 am
> To: "Ettus Mail List" 
> Cc: "Martin Braun" 
>
> Thanks Martin. I tried that, but it actually seems to be working when I look
> at the results.  I saw you post earlier to someone about changing UHD's
> logging level.  Is this something that can be done via a config file?  I
> looked around, but all I could find was some references to c++ usage.
>
>
>> Jason,
>>
>> this is a tough one. I have no ideas, other than 'throw in a couple of
>> ILAs and see where it's stuck'.
>
>> -- M
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] about rfnoc nocshell

[Jon Pendlum via USRP-users]

Hi,

1) You cannot reduce noc_shell resource usage much. You can try
putting all your custom logic in just one RFNoC block, that way you do
not incur the overhead of multiple noc_shell instances.
2) Do you mean "Can I access PS DDR memory directly from the FPGA
fabric?" If so, yes you can via the HP AXI ports. You'll need
something to interface with the HP AXI port though. Xilinx's AXI
Datamover or AXI DMA IP blocks are decent choices.

Jonathon

On Fri, Jul 6, 2018 at 3:26 AM, carry chen via USRP-users
 wrote:
> hello,list,
>
> I have study the rfnoc,I have 2 question:
> 1. I find nocshell module use large resource, e310 resource is less, so can
> I adjust some param to reduce the resoure comsume? I only config one radio(1
> ddc+1 duc),I find use so many resouce
> 2.Can I share memory between ps and pl direct?
>
> Best,Regards,
> Carry
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] noc_block_null_source_sink module

[Jon Pendlum via USRP-users]

Hey Jason,

The block is functionally complete, in fact I think it was the first
block ever made. There is a UHD C++ example,
rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC
xml for GNU Radio needs to be created though.

Jonathon

On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users
 wrote:
> I was having trouble finding information on this block. I could see its
> usefulness in an application I am looking into, but I wasn't sure how
> complete the block was (I don't really see anything using it, nor a GRC xml
> file for it).
>
> Thanks
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] Possible to enable via RFNoC block via RFNoC

[Jon Pendlum via USRP-users]

Hey Jason,

You can send a command packet to another block via noc_shell's cmd_out
port. Command packets basically encapsulate a settings bus write. In
the payload of the command packet, the upper 32 bits are the settings
register address and the lower 32 bits are the data. Also, the block
will reply with a response packet, make sure to receive it (or just
leave ackin_tready set to 1'b1.)

There are a few things to be aware of though when manually sending out
command packets in a RFNoC block:
- This is a raw packet, so you will need to setup the header which
includes knowing the SID of the receiving block. That is easy if you
know which xbar port it is connected to: SID = {8'd0 (xbar ID), 4'd#
(xbar port), 4'd0 (block port)}. To find the xbar port, look at the
rfnoc_ce_auto_inst_.v file and find the array index of the
receiving block. For X3x0 devices, xbar port = array index + 5.
- The host will be unaware of any changes you made. If that is an
issue, you could try implementing a readback register that the host
regularly polls.
- Sending many timed commands requires extra care. RFNoC blocks store
timed commands in a FIFO until they are executed. UHD tracks the FIFO
depth to prevent overflow, but noc_shell does not. You can control the
depth of the FIFO via noc_shell's CMD_FIFO_SIZE parameter.

Jonathon

On Tue, Jul 31, 2018 at 4:12 AM, Jason Matusiak via USRP-users
 wrote:
> I am curious if it is possible to enable an RFNoC block from another RFNoC
> block?  An example would be, turning on the siggen when another RFNoC block
> decides that it should run.
>
> I don't believe that I've seen this done anywhere, so I have a suspicion
> that there isn't a good way to get messages from one RFNoC to another
> without going through the host first.
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] Problem with the most recent UHD changes building

[Jon Pendlum via USRP-users]

Hey Jason,

The fix was pushed recently and builds fine for me now.

Jonathon


On Tue, Jul 3, 2018, 2:27 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I just tried to pull down and build a fresh RFNoC install and it keeps
> failing.  I think this is related to the commit 827adb from a couple of
> days ago.  I say this because that commit showed a change to
> ad9361_ctrl.hpp, and my error when running "yes |pybombs - prefix init
> /opt/gnuradio/v3.7.12.0_rfnoc -R rfnoc -a rfnoc" is:
>
>
> [ 36%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/common/fx2_ctrl.cpp.o
> [ 36%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/common/ad9361_ctrl.cpp.o
> [ 36%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/common/ad936x_manager.cpp.o
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:
> In member function ‘virtual void ad9361_ctrl_impl::set_timing_mode(const
> string&)’:
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:153:23:
> error: ‘_use_safe_spi’ was not declared in this scope
> _use_safe_spi();
> ^
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:158:24:
> error: ‘_use_timed_spi’ was not declared in this scope
> _use_timed_spi();
> ^
> make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/common/ad9361_ctrl.cpp.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> make: *** [all] Error 2
> PyBOMBS.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBOMBS.monitor_process() - DEBUG - Return value: 2
> PyBOMBS.Packager.source - DEBUG - Building recipe uhd
> PyBOMBS.Packager.source - DEBUG - In cwd -
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/build
> PyBOMBS._process_thread() - DEBUG - Executing command `$ make -j1'
> [ 2%] Built target uhd_rpclib
> [ 2%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/common/ad9361_ctrl.cpp.o
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:
> In member function ‘virtual void ad9361_ctrl_impl::set_timing_mode(const
> string&)’:
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:153:23:
> error: ‘_use_safe_spi’ was not declared in this scope
> _use_safe_spi();
> ^
> /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd/host/lib/usrp/common/ad9361_ctrl.cpp:158:24:
> error: ‘_use_timed_spi’ was not declared in this scope
> _use_timed_spi();
> ^
> make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/common/ad9361_ctrl.cpp.o] Error 1
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> make: *** [all] Error 2
> PyBOMBS.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBOMBS.monitor_process() - DEBUG - Return value: 2
> PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> uhd:
> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package uhd. Aborting.
> 02671 kB / 02671 kB (100%)
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 Register's Memory Capability

[Jon Pendlum via USRP-users]

Hi Steve,

USE_EMBEDDED_REGS_COEFFS means that the filter will attempt to infer
the DSP48's embedded registers (specifically register B) for storing
coefficients. You should refer to Xilinx's DSP48 design doc
https://www.xilinx.com/support/documentation/user_guides/ug479_7Series_DSP48E1.pdf.

Using embedded registers is more efficient, because those registers
come for free as part of the DSP48. However, the embedded registers
only have a reset and will initialize to all 0s (instead of the
coefficients in COEFFS_VEC). At startup, the coefficients must be
loaded via the settings register bus for the filter to be useful. This
is not a big deal though, since the block controller for
noc_block_fir_filter does that. Also, since the embedded registers are
chained like shift register (via BCOUT output to B input), loading new
coefficients while streaming causes the FIR filter output to be
corrupted until all the new coefficients have been loaded.

If you set USE_EMBEDDED_REGS_COEFFS = 0, then regular registers will
be instantiated. Those registers will be initialized with COEFFS_VEC
and the filter will always be ready to go. Also, the output will not
be corrupted while loading new coefficients.

I would suggest enabling USE_EMBEDDED_REGS_COEFFS unless you plan to
constantly change coefficients and are worried about the filter output
being corrupted.

Jonathon

On Fri, Jun 8, 2018 at 12:06 AM, shachar J. brown via USRP-users
 wrote:
> After examining the files in depth, I realized I need some help
> understanding core concepts in FPGA programming:
>
> In "axi_fir_filter.v" there is a parameter named "USE_EMBEDDED_REGS_COEFFS",
> and explained in comment: " Reduce register usage by only using embedded
> registers in DSP slices".
>
> - What is the actual difference between registers and embedded registers?
> - Does the implementation of the two only differ in usage of "wire" vs.
> "reg"?
>
> Thanks for your time,
> Steve
>
> On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster  wrote:
>>
>> It's going to depend on how much block RAM the image is already using, and
>> how much more you can use while still getting the image to route. The
>> easiest way to find out will be to try it.
>>
>> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
>> wrote:
>>>
>>> Thanks Nick, that's an excellent example.
>>> Do you know what are the memory size restrictions of the configuration
>>> data?
>>>
>>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
>>> wrote:

 Look at the RFNoC FIR filter block for a good example of pushing
 configuration data into a block via the settings bus.

 On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users
  wrote:
>
> Hi all,
>
> I'm working on an X310.
>
> I have large data (tables of 1-3 K of variables) I would like to insert
> into the FPGA's memory registers while running.
>
> How much space is available in the FPGA? Seemingly, the Address for the
> "set_register" is only 8 bits long, and the first 128 addresses are 
> reserved
> for the Noc_Shell. So... Does that mean I can store only 128 variables at 
> a
> time?
>
> (Just to clarify: I want to change the data while running, and I'd like
> it to be inside the FPGA for performance issues).
>
> Thank a ton!
> Steve
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] Timeout On Chan 0 Error

[Jon Pendlum via USRP-users]

Hi Peter,

Does the testbench you make as part of the tutorial work?

Jonathon


On Wed, May 23, 2018, 12:09 PM Peter Sanchez via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have a USRP X310 and just finished going through the RFNoC Getting
> Started tutorial. After uploading the desired blocks to the FPGA, I wanted
> to run the example in GNU Radio Companion, like in the tutorial, but the
> terminal keeps showing "timeout on chan 0" errors. The Link light flashes
> between green and amber while this happens.
>
> I swapped the custom gain block that I made during the tutorial for the
> RFNoC Digital Gain block, in the GNU Radio Companion and in the FPGA, but
> the error persists.
> If I remove either Gain blocks and connect the DDC straight to the Copy
> block, the timeout errors stop.
>
> Does any one know what is wrong? I'm running Ubuntu and have the latest
> RFNoC files installed using the methods described in the tutorial.
>
> Thanks
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

[Jon Pendlum via USRP-users]

Hey Andrew,

The next line in fir_block_ctrl_impl.cpp sends the final tap:
sr_write(SR_RELOAD_TLAST, uint32_t(taps.back()));

The half a sample shift is odd though.

On Sat, Apr 21, 2018, 6:23 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote:
>
> Hello,
>
>
>
> An oddity regarding the RFNoC FIR Filter block. fir_block_ctrl_impl.cpp
> writes tap values to the settings registers with:
>
>
>
> for (size_t i = 0; i < taps.size() - 1; i++) {
> sr_write(SR_RELOAD, uint32_t(taps[i]));
>
> }
>
>
>
> which loops from 0 to taps.size() - 1. So if I define 41 taps from GRC, it
> only takes taps indexed from 0 to 39 and never writes tap index 40 (the
> 41st tap) to the settings register.
>
>
>
> I sort of confirmed this by comparing the RFNoC FIR Filter output
> against the GNU Radio Decimating FIR Filter (with Decimation=1) output with
> the same 41 taps and same input fed to both. Output gets shifted by half
> of a complex sample:
>
>
>
> GR FIR:
>
> 1 + .997j
>
> .994 + .991j
>
> .988 + ...
>
>
>
> RFNoC FIR:
>
> 0 + 1j
>
> .997 +.994j
>
> .991 + .988j
>
>
>
> Which is an effect of a FIR filter that has an even number of taps (40
> instead of 41).
>
>
>
> So I modified the condition in the FIR driver file to write from 0
> to taps.size() instead of taps.size()-1. Defined the 1st tap value to
> be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an and
> saw nothing on output. Then moved the non-zero tap to the middle (21st
> index) with leading 20 and trailing 20 taps being 0s and saw the input fed
> to output. Now if I didn't modify the FIR driver file so it stops at
> taps.size()-1 and writes only 40 of my 41 taps and set the first tap to
> 1000 with 40 trailing zeros, I see input fed to output. Was the
> taps.size()-1 check intentional?
>
>
>
> Andrew
>
> This definitely looks to me like a subtle bug in the "off by one" error
> category.
>
> One of our RFNoC devs will probably chime in at this point, and provide an
> opinion
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

[Jon Pendlum via USRP-users]

> I want to use this block with 1,000 coefficients, but when I tried to do so
> I saw that the maximum possible is only 41 coefficients.
>
> Does anybody know if Ettus has any solution to use FIR with 1,000
> coefficients?

The number of taps is an adjustable parameter in the FIR filter
block's Verilog code. Take a look at noc_block_fir_filter.v. Be warned
though, 1000 is a large number of taps and the build may fail.

Jonathon

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

Re: [USRP-users] bug using rx_stream constructor inside a loop ...

[Jon Pendlum via USRP-users]

Hello Matis,

Can you turn on full UHD logging and pastebin the output?

Jonathon


On Fri, Apr 6, 2018, 4:28 PM Matis Alun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Le 05/04/2018 à 16:29, Marcus D. Leech via USRP-users a écrit :
>
> On 04/05/2018 04:55 AM, Matis Alun via USRP-users wrote:
>
> Hi usrp users,
>
> I experienced some problem using my X300 + TwinRx over 1 Gb/s link.
>
> The following code example shows that after the iteration number 253, the
> program stops
> with the following traceback:
>
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: [0/Radio_0] sr_write() failed:
> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet -
> AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>   at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
>
> I have good news: If I move the part of the code which construct the
> rx_stream, there is no errors.
>
> Is someone can explain me ? Is this an uhd bug or not ?
>
> Matis
>
> This should be possible, but it seems awkward and unusual to do what
> you're doing, in the way that you're doing it.
>
>
> You should:
>
> STREAM_MODE_START_CONTINUOUS
>
> read as much data as you want
>
> STREAM_MODE_STOP_CONTINUOUS
>
> That is, there's no reason to keep doing the start/stop on every
> iteration, since you aren't pausing, you're basically just continuous
> streaming in an
>   awkward and unusual way.
>
> Now, this shouldn't raise that exception, but the workaround is to
> structure your code without tightly looping on START/STOP.
>
> yes, you're right, but this was here a small example to show you the
> traceback. My application is more complicated and acts like a data
> server which answer to any acquisition request. So each request could be
> at another frequency. So I thought we have to STOP, change the frequency
> and START.
>
> However, the problem is not that the START/STOP is inside the loop. Which
> is causing the traceback is the instanciation of the rx_stream inside
> the loop. Of course, I can organize my code to avoid this but I thought
> that it was probably an UHD bug. This is the reason why I send this message
> (and also to help people who had the same kind of problem...).
>
> Regards,
>
> Matis
>
>
>
> bool test2() {
> std::string args="addr=192.168.10.2";
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>
> std::string subdev_spec="A:0";
> usrp->set_rx_subdev_spec(subdev_spec);
> usrp->set_rx_rate(25e6, 0);
> usrp->set_rx_freq(1240e6, 0);
> usrp->set_rx_gain(50.0, 0);
> usrp->set_rx_antenna("RX1", 0);
>
> while (true) {
> uhd::sensor_value_t lo_locked = usrp->get_rx_sensor("lo_
> locked",0);
> if (lo_locked.to_bool()) {
> break;
> }
> usleep(1);
> }
>
>
> for (int iteration=0; iteration<1000; iteration++) {
> // try this block outside the loop and every thing is ok
> uhd::stream_args_t stream_args("sc16", "sc16");
> stream_args.channels.push_back(0);
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_
> args);
> // end of block
>
> cout << "iteration: "<< iteration << endl;
> uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::
> STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = 0;
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
> rx_stream->issue_stream_cmd(stream_cmd);
>
> std::vector buff_sc16(524288);
> uhd::rx_metadata_t md;
> int num_rx_samps;
>
>
> for (int i=0; i<10; i++) {
> num_rx_samps = rx_stream->recv(_sc16.front(),
> buff_sc16.size(), md, 1.0);
> cout << "recv:"<< num_rx_samps< }
>
> stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_
> MODE_STOP_CONTINUOUS;
> rx_stream->issue_stream_cmd(stream_cmd);
> }
> return true;
> }
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] file_souce block for RFNoC

[Jon Pendlum via USRP-users]

Hi,

The file_source and file_sink blocks (and corresponding RFNoC blocks) are
only useful for simulations. File I/O is not a sythensizable operation.

Jonathon

On Thu, Apr 5, 2018, 7:17 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi there,
>
> I find the "file_source" block in RFNoC for X310. Is there any example or
> tutorial how to use it by either UHD C++ or GNURadio? I am new to RFNoC and
> trying to get started with transmitting a waveform from a source file in a
> host computer. Thank you!
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Rfnoc over flow

[Jon Pendlum via USRP-users]

Hi Snehasish,

How long do you record samples? Do the overflows occur immediately?
Are they continuous, bursty, only at the beginning? What rate can you
run at without overflows?

I would suggest running "benchmark_rate --rx_rate 25.6e6 --duration
600" and "uhd_fft --samp-rate 25.6e6 --freq 2.4e9". Your system should
be able to run both of those apps without continuous overflows.

Jonathon

On Wed, Feb 7, 2018 at 8:41 AM, Snehasish Kar via USRP-users
 wrote:
> Hello
>
>
> I am uisng NI USRP 2954R with RAM 64GB, and intel Xeon CPU D-1537 @ 1.70GHz
> with supermicro motherboard MBD-X10SDV-7TP4F and intel SFP+ of model  X552.
> I am trying to stream data at sample rate of 25.6MSPS using both the
> receivers in gnuradio and writing the the samples to a linux-FIFO, but as
> soon as I start it, it only gives me overflow on both the channels. Please
> help me with it, where I am going wrong. Below is the output of my
> uhd_usrp_probe.
>
>
>
> uhd_usrp_probe --args="addr=192.168.40.2"
> [INFO] [UHDlinux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7);
> Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [X300] Detecting internal GPSDO
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC] pass (Throughput: 1290.5MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC] pass (Throughput: 1304.2MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
>   _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 11
> |   |   revision_compat: 7
> |   |   product: 30810
> |   |   mac-addr0: 00:80:2f:16:51:21
> |   |   mac-addr1: 00:80:2f:16:51:22
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 310514A
> |   |   FW Version: 5.1
> |   |   FPGA Version: 33.0
> |   |   FPGA git hash: b0890fa-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo,
> ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 3103BF3
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 3103C35
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: B
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | 

Re: [USRP-users] RFNoC Block with two inputs and one output.

[Jon Pendlum via USRP-users]

Hi Mark,

Are you getting a specific error message in GRC? You'll need to post
more details for someone to help you.

Jonathon

On Wed, Dec 13, 2017 at 4:46 AM, Mark Luscombe via USRP-users
 wrote:
> Hi all,
>
> My next question ;-)
>
> I want to create a RFNoC Block with two SC16 inputs and one SC16 output.
> There doesn’t seem to be an existing Block that does this, so I tried to
> copy the RFNoC AddSub Block that has two in and two out, and leave one
> output open and adjust the XML to indicate this. I’ve tried many times but
> cannot achieve a setup that GRC is happy with.
>
> Has anybody else got a two in and one out RFNoC Block to work in GRC, and if
> so could you share the XML’s with me?
>
> Thanks, Mark.
>
> P.S. As a temporary measure i replicate the single output to achieve a two
> in and two out RFNoC Block that GRC is happy with.
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

[Jon Pendlum via USRP-users]

Hi Tien,

Run 'make xsim' in the same directory as the testbench.

Jonathon

On Jan 22, 2018 12:52 PM, "Dang tien Vo-Huu via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hi EJ,
It works! Now I am able to simulate the custom block with IP in both cases.
Just another small question, can we simulate the built-in RFNoC block? I
see the simulate file (for example noc_block_fft_tb.sv) but not sure how to
run it..
Thank you very much for the help.

Best,
Tien


On Mon, Jan 22, 2018 at 10:55 AM, EJ Kreinar  wrote:

> Hi Tien,
>
> If the Xilinx IP is included in the uhd-fpga/usrp3/lib repo, you can
> follow the example provided in the Makefile for the noc_block_fft_tb:
> https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/n
> oc_block_fft_tb/Makefile
>
> Note the three steps:
> 1. set LIB_IP_DIR
> 2. Include the Makefile.inc associated with the Xilinx IP
> 3. Append generated IP to the DESIGN_SRCS
>
> If the Xilinx IP you want to use is contained in an OOT repo, then you
> would want to follow the Makefile.inc process of including the OOT repo:
> https://github.com/ejk43/rfnoc-ootexample
>
> The "noc_block_complextomagphase_tb" example shows an example of how to
> include and simulate Xilinx IP inside an OOT repo:
> https://github.com/ejk43/rfnoc-ootexample/blob/master/
> rfnoc/testbenches/noc_block_complextomagphase_tb/Makefile
>
> For another example, this repo with a polyphase channelizer also shows how
> to include and simulate Xilinx IP in an OOT repo: https://github.com/e33b1
> 711/rfnoc-ppchan
>
> Hope this helps,
> EJ
>
> On Fri, Jan 19, 2018 at 10:28 PM, Dang tien Vo-Huu via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>> I have this error when trying to simulate a custom RFNoC block in an OOT
>> module:
>>
>> $ make noc_block_hbFilter_tb
>> .
>> .
>> Starting static elaboration
>> ERROR: [VRFC 10-2063] Module  not found while processing
>> module instance  [/home/tienvh/workspace/rfnoc/
>> src/rfnoc-filters/rfnoc/fpga-src/noc_block_hbFilter.v:179]
>> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
>> unit(s) in library work failed.
>> INFO: [USF-XSim-99] Step results log file:'/home/tienvh/workspace/r
>> fnoc/src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_
>> tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
>> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please check
>> the Tcl console output or '/home/tienvh/workspace/rfnoc/
>> src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_tb/xs
>> im_proj/xsim_proj.sim/sim_1/behav/elaborate.log' file for more
>> information.
>> .
>> .
>>
>> I can build an FPGA image with the custom RFNoC block following the
>> instruction here: http://www.synchronouslabs.com/blog/creating-a-custom-
>> rfnoc-block-with-using-xillinx-ip
>> but I haven't found a way to simulate this block.
>> Is there any way to run the simulation in this situation? Otherwise it
>> would be difficult to debug if anything goes wrong..
>>
>> Thanks in advance.
>>
>> Best,
>> Tien
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>

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

Re: [USRP-users] RFNoC: Synthesizing a block containing modules from uhd-fpga

[Jon Pendlum via USRP-users]

Hi Adam,

Can you post your testbench makefile?

Jonathon

On Jan 10, 2018 5:07 PM, "Adam Parower via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
>
> I am trying to create a custom RFNoC block that is similar to the built-in
> DUC block. As such, it depends on the cordic_timed, axi_rate_change, and
> duc modules defined in uhd-fpga/usrp3/lib/rfnoc. When I attempt to run the
> testbench for my block, Vivado fails in synthesis. While Vivado is able to
> find cordic_timed.v, axi_rate_change.v, and duc.v, it is unable to find
> the submodules that these modules depend on (e.g. axi_rate_change requires
> setting_reg, axi_fifo_flop2, and axi_drop_partial_packet). What can I do to
> get Vivado to find these dependencies and synthesize my block?
>
>
> Thank you in advance for your assistance.
>
>
> Adam Parower
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com