[USRP-users] DPDK with UHD 4.0

[Dario Pennisi via USRP-users]

Hi,
i'm trying to use DPDK with UHD 4 but it is not detected by cmake.
i have ubuntu 20.04.1 which installs DPDK 19.11.3-0ubuntu0.2 when i use
apt-get install dpdk dpdk-dev

i tried passing manually environment variables for include and library
directories but that doesn't work.
can you please shed some light on this?
thanks,

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

Re: [USRP-users] simulation error with uhd 4.0

[Dario Pennisi via USRP-users]

i did some step forward. it looks like in the build directory there's a
file called complex_multiplier_sim_netlist.v that allows simulation however
when calling the simulation from an OOT directory the IP is rebuilt under
that directory and that file is not created.
unfortunately the sim/complex_multiplier.vhd being created is not usable as
it causes the simulator to crash.
any suggestions on how to have this done by the simulation makefile?

thanks,
Dario

On Sat, Nov 21, 2020 at 8:43 PM Jonathon Pendlum 
wrote:

> Hi Dario,
>
> Unfortunately, Vivado's xsim simulator sometimes crashes when it runs into
> syntax and elaboration errors. Make sure you don't have issues like signals
> with multiple drivers, undriven signals, missing reset logic, typos, etc.
> Note that these issues may be in code that is/seems unrelated to the cmul
> instantiation.
>
> Also, if you have access to ModelSim, I would highly suggest trying that
> tool instead as it is far more robust than xsim. You can use the vsim make
> target to use ModelSim.
>
> Jonathon
>
> On Sat, Nov 21, 2020 at 5:54 AM Dario Pennisi via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> i'm trying to simulate a block where i'm using cmul. in order to have
>> that compiled in i am including the following in my Makefile under
>> rfnoc/fpga in my OOT directory:
>>
>> include $(BASE_DIR)/../lib/ip/Makefile.inc
>> SIM_SRCS = $(abspath rfnoc_block_demod_tb.sv)  \
>> $(LIB_IP_COMPLEX_MULTIPLIER_OUTS) \
>>
>> i tried also adding this to DESIGN_SRCS but when running simulation with
>> Vivado 2019.1 i see the following error:
>>
>> ERROR: [XSIM 43-3983] Internal Compiler error encountered while
>> processing aggregate association.
>> ERROR: [XSIM 43-3915] Encountered a fatal error. Cannot continue.
>> Exiting...
>>
>> if i remove cmul instance from my design simulation works.
>>
>> can you please shed some light on how to fix this?
>> thanks,
>>
>> Dario Pennisi
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 
Dario Pennisi
ipTronix S.r.l.

Tel +39 06 66183814
Fax +39 06 66188420
Mobile  +39 335 6878904
Web www.iptronix.com
<https://urldefense.com/v3/__http:/www.iptronix.com__;!!KXGHL9MWuGc!s5Tn7AzcrRbHxw-tqBwTDmxvGjHnCEyM7Hgx2K_iBSRF5MT3mAq3Hf-oopBP-dAa$>

The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s), if
you are not the intended recipient, you are hereby notified that any use,
dissemination or reproduction is strictly prohibited and may be unlawful.
If you are not the intended recipient please contact the sender by return
e-mail and destroy all copies of the original message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] simulation error with uhd 4.0

[Dario Pennisi via USRP-users]

Hi Jonathon,
thanks for your reply. unfortunately the issue seems to be with
complex_multiplier ip generated by vivado. if i bypass that (my
instantiating wires that connect input to output instead of the IP)
everything works.  i noticed the IP generates a vhdl file and the aggregate
association error seems related to this. everything else in my design is
verilog so i doubt it may be my code.

On Sat, Nov 21, 2020 at 8:43 PM Jonathon Pendlum 
wrote:

> Hi Dario,
>
> Unfortunately, Vivado's xsim simulator sometimes crashes when it runs into
> syntax and elaboration errors. Make sure you don't have issues like signals
> with multiple drivers, undriven signals, missing reset logic, typos, etc.
> Note that these issues may be in code that is/seems unrelated to the cmul
> instantiation.
>
> Also, if you have access to ModelSim, I would highly suggest trying that
> tool instead as it is far more robust than xsim. You can use the vsim make
> target to use ModelSim.
>
> Jonathon
>
> On Sat, Nov 21, 2020 at 5:54 AM Dario Pennisi via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> i'm trying to simulate a block where i'm using cmul. in order to have
>> that compiled in i am including the following in my Makefile under
>> rfnoc/fpga in my OOT directory:
>>
>> include $(BASE_DIR)/../lib/ip/Makefile.inc
>> SIM_SRCS = $(abspath rfnoc_block_demod_tb.sv)  \
>> $(LIB_IP_COMPLEX_MULTIPLIER_OUTS) \
>>
>> i tried also adding this to DESIGN_SRCS but when running simulation with
>> Vivado 2019.1 i see the following error:
>>
>> ERROR: [XSIM 43-3983] Internal Compiler error encountered while
>> processing aggregate association.
>> ERROR: [XSIM 43-3915] Encountered a fatal error. Cannot continue.
>> Exiting...
>>
>> if i remove cmul instance from my design simulation works.
>>
>> can you please shed some light on how to fix this?
>> thanks,
>>
>> Dario Pennisi
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 
Dario Pennisi
ipTronix S.r.l.

Tel +39 06 66183814
Fax +39 06 66188420
Mobile  +39 335 6878904
Web www.iptronix.com
<https://urldefense.com/v3/__http:/www.iptronix.com__;!!KXGHL9MWuGc!s5Tn7AzcrRbHxw-tqBwTDmxvGjHnCEyM7Hgx2K_iBSRF5MT3mAq3Hf-oopBP-dAa$>

The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s), if
you are not the intended recipient, you are hereby notified that any use,
dissemination or reproduction is strictly prohibited and may be unlawful.
If you are not the intended recipient please contact the sender by return
e-mail and destroy all copies of the original message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] ILA in UHD 4

[Dario Pennisi via USRP-users]

Hi,
i am trying to debug my block and to do so i ran

GUI=1 make n310_rfnoc_image_core

this brings up vivado and allows me to synthesize the design and setup ILA.
when i try fitting and generating bitstream i get the following error:

[DRC PDRC-29] MMCM_adv_ClkFrequency_clkin1: The calculated frequency value,
0.000 MHz, of the CLKIN1_PERIOD attribute on the MMCME2_ADV site
MMCME2_ADV_X0Y0 (cell n3xx_clocking_i/misc_clock_gen_i/inst/mmcm_adv_inst)
is outside the allowed range (10.000 - 933.000 MHz). Please change the
CLKIN1_PERIOD attribute value in order to be within the allowed range for
this device.
[DRC PDRC-29] MMCM_adv_ClkFrequency_clkin1: The calculated frequency value,
0.000 MHz, of the CLKIN1_PERIOD attribute on the MMCME2_ADV site
MMCME2_ADV_X1Y5 (cell
u_ddr3_32bit/u_ddr3_32bit_mig/u_ddr3_infrastructure/gen_mmcm.mmcm_i) is
outside the allowed range (10.000 - 933.000 MHz). Please change the
CLKIN1_PERIOD attribute value in order to be within the allowed range for
this device.
[DRC PDRC-38] PLL_adv_ClkFrequency_clkin1: The calculated frequency value,
0.000 MHz, of the CLKIN1_PERIOD attribute on the PLLE2_ADV site
PLLE2_ADV_X1Y5 (cell
u_ddr3_32bit/u_ddr3_32bit_mig/u_ddr3_infrastructure/plle2_i) is outside the
allowed range (19.000 - 933.000 MHz). Please change the CLKIN1_PERIOD
attribute value in order to be within the allowed range for this device.

strange enough i don't get these when running from console.
any suggestions?

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

[USRP-users] simulation error with uhd 4.0

[Dario Pennisi via USRP-users]

Hi,
i'm trying to simulate a block where i'm using cmul. in order to have that
compiled in i am including the following in my Makefile under rfnoc/fpga in
my OOT directory:

include $(BASE_DIR)/../lib/ip/Makefile.inc
SIM_SRCS = $(abspath rfnoc_block_demod_tb.sv)  \
$(LIB_IP_COMPLEX_MULTIPLIER_OUTS) \

i tried also adding this to DESIGN_SRCS but when running simulation with
Vivado 2019.1 i see the following error:

ERROR: [XSIM 43-3983] Internal Compiler error encountered while processing
aggregate association.
ERROR: [XSIM 43-3915] Encountered a fatal error. Cannot continue.
Exiting...

if i remove cmul instance from my design simulation works.

can you please shed some light on how to fix this?
thanks,

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

[USRP-users] rfnoc on uhd4 3.8/9

[Dario Pennisi via USRP-users]

Hi,
I've been trying to create and use a rfnoc block for n310 within gnuradio 3.8 
and uhd4.0. I first tried with pybombs but this doesn't not seem to work very 
well and there is no default recipe that works. I then moved to manual install 
from source and got something up using the maint-3.8 and uhd-4.0 branches 
however none of the rfnoc blocks in uhd 4.0 seem to be usable directly in 
gnuradio companion as the yaml files in uhd are not compatible with the yaml 
block files required by grc.

I then moved to master branch of both repositories and this installs with 
gnuradio, some yaml files for some of the blocks in uhd, so I tired compiling a 
fpga with fft block as instructed in the tutorial but the fft would not produce 
output data.

Finally I tried compiling the gain example block out of tree and installed its 
control block both with maint 3.8 branch (that uses swig) and master branches 
(that uses pybind11) but in both cases the block doesn't get recognized when i 
issue uhd_usrp_probe and it gets listed as block#0 regardless of Ldconfig.
I get it listed in grc after I created a second yaml file compatible with grc 
but of course running a graph will fail as it doesn't find the block control 
class, likely because in the installation process I don't see python bindings 
being generated for it, regardless of the binding creation mechanism.

So my questions are:
1) is there any way to use rfnoc in grc as of today that doesn't need manual 
creation of the block.yaml files?
2) why the fft block using the block.yaml definition from gr-uhd doesn't seem 
to work?
3) how do I make oot blocks recognized by probe and grc?

Thanks,


Dario Pennisi

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

[USRP-users] help with vivado 2017 port

[Dario Pennisi via USRP-users]

Hi,
we're porting our block to the latest Vivado 2017.4 environment but have a few 
issues we can't explain.

  1.  Although uhd_usrp_probe finds the blocks with the correct names, it 
doesn't find the custom control block. This is reported by probe with a 
warning. Strange thing is that even if we don't use our custom code and just 
create the block with rfnocmodtool asking to create the custom block, verified 
the block is compiled and installed under lib, we still see this warning 
message, which suggests that either the so has not been loaded or there's some 
kind of mismatch. Xml is instead loaded and correctly parsed as block name is 
recognized
  2.  Our block is instantiated manually in x300_core as it has 4 axi ports so 
can't be automatically instantiated. One of the 4 ports exposes a DDC which is 
basically cut of the noc DDC block. When doing probe the block does not 
responds to requests and probe fails. This was working with vivado 2015.4 and 
yes, we added bus_clk and bus_rst in axi_wrapper

Can anyone help at least on the first point? We can't really understand why our 
custom control block seems to be ignored.
Thanks,

Dario Pennisi

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

Re: [USRP-users] Error with multiple block output ports

[Dario Pennisi via USRP-users]

Hi guys,
Although rfnoc supports different number of inputs and outputs uhd does not and 
you'll get all sorts of issues trying to address this.
This is the reason why adder block also has a subtract output...
Another issue is that loopback within fpga does not work. This means that 
signals in a chain have to originate or terminate on the host. If you have 
paths completely contained in rfnoc domain some streamers will not be enabled 
and you'll have to enable them manually.
Finally remember that ports share the bandwidth of a single axi port so make 
sure total bandwidth is below it. For x310 axi bw is around 300 msps


Dario Pennisi




On Tue, Jul 24, 2018 at 1:56 PM +0200, "Carlos Alberto Ruiz Naranjo via 
USRP-users" mailto:usrp-users@lists.ettus.com>> 
wrote:

Please, any help?? :( :( :(

2018-07-12 19:13 GMT+02:00 Brassard, Sean M. 
mailto:sean.brass...@jhuapl.edu>>:
We never received any help from Ettus on this and never got past the problem.

Sean

From: Carlos Alberto Ruiz Naranjo 
[mailto:carlosruiznara...@gmail.com]
Sent: Thursday, July 12, 2018 2:42 AM
To: Barker, Douglas W.
Cc: Jonathon Pendlum; Yim, Kaun J.; 
usrp-users@lists.ettus.com; Brassard, Sean M.

Subject: Re: [USRP-users] Error with multiple block output ports

I have the same problem, any help? ^^

2017-06-06 13:45 GMT+02:00 Barker, Douglas W. via USRP-users 
mailto:usrp-users@lists.ettus.com>>:
Hello,

Is there any update on our issue?

Thanks
Doug

From: Jonathon Pendlum 
[mailto:jonathon.pend...@ettus.com]
Sent: Monday, May 29, 2017 2:16 AM
To: Barker, Douglas W.
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Error with multiple block output ports

Try fixing these issues, especially the first one, and see if that helps:

- In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels instead 
of 3.
- In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is set to 
have only two active outputs.

On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W. 
mailto:douglas.bar...@jhuapl.edu>> wrote:
Jonathon,

I’ve attached the XML files that I was using.


Thanks!
Doug

From: Jonathon Pendlum 
[mailto:jonathon.pend...@ettus.com]
Sent: Thursday, May 25, 2017 3:46 PM
To: Barker, Douglas W.
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Error with multiple block output ports

Hi Doug,

Can you share your Noc Script XML file?



Jonathon

On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello,

I’m starting a new thread for this problem.  I get an error when trying to use 
more than 2 output ports on a RFNoC block.  I’ve designed a CE that has 9 
output ports and when starting the gnuradio flowgraph it errors out.  When I 
reduce the ports to 2 it works.  If I increase the ports to 3 it errors out.

I then made a simple modification to the ‘noc_block_split_stream’ block that is 
provided to have three output ports (also modified the associated XML files).  
It error out as well, in the same way.  This test has 
Radio->DDC-SplitStream->host.  Below are the messages produced by gnuradio when 
starting.  Can the folks at Ettus please take a look as it appears to be a bug 
in UHD.  I’ve attached the modified ‘noc_block_split_stream.v’ file so you can 
easily reproduce the error.

Thanks
Doug


Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'

Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py

[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; Boost_106300; 
UHD_4.0.0.rfnoc-devel-316-g24b98579
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mSetup basic communication...
[32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
[32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
[32;1m[INFO] [X300] [39;0mRadio 1x clock:200
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer sizes, 
but 1 input ports
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
DEBUG: output 

Re: [USRP-users] RFNoC Software Emulation

[Dario Pennisi via USRP-users]

Hi Brian,
as you may have guessed I’m not from ettus so maybe you can get better insight 
from them. On my side I would recommend you look at the APIs to write/read 
registers and the ones that set up streams to/from the device. These are the 
main building blocks and you will find that the register access APIs have a 
fire and forget approach by which if you lose a packet everything will stop 
working (packet out of sequence error), which is typical in high load udp 
scenarios.
Once you have looked at this you need to also emulate the software running on 
the ZPU processor (or ARM if you use embedded series).
Note that interface to devices is handled by device3 block which will enumerate 
all the available devices and allows you to bind each block to a given device. 
Don’t think you will need to modify that if you emulate completely but it’s for 
sure a place to look at.
Best regards,

Dario Pennisi

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

Re: [USRP-users] how to write test for block with two output ports

[Dario Pennisi via USRP-users]

Hi ishai,
Although a block with different number of inputs and outputs is feasible in 
rfnoc, uhd won't work well with it so I would suggest you define it with the 
same number of inputs and outputs and then just connect the unused into to a 
null source/sink

For a complete example on how to implement it look at the add sub block which 
has two inputs and two outputs... Just copy that and replace the internal 
algorithm and you're done.

Just one caveat... Since you are sharing a single axi interface of the internal 
matrix you are limited to around 300 msps total so if you plan to output two 
200 msps streams you will see overruns and nothing will work.

If you need to output two 200 msps streams the only way is manually 
instantiating your block and connect it to two axi ports. You can check 
x300_core which contains the instances of the radios... You can add you block 
along with them...
Best regards,

Dario Pennisi


Da: ishai alouche via USRP-users
Inviato: domenica 22 luglio, 20:58
Oggetto: [USRP-users] how to write test for block with two output ports
A: usrp-users@lists.ettus.com


Hi all,

I use the X310 usrp and i create new block with rdnocmodtools.

My block have one input and two outputs and I have two questions:

1. I try to understand how I define two output ports. I found two way to do it, 
the first is by duplicate the axi_wrapper block, and the second is without 
axi_wrapper at all and using chdr_framer instead (like in the split_stream 
block). My question is how is the correct way to write it? and second when we 
use chdr_framer and when I duplicate the axi_wrapper in general.

2. The second question is about the test bench. I wrote my block with two 
axi_wrapper and i try to check it.In the test bench I try to read the two ports 
with  tb_streamer.recv() function, but I didn't success and the function didn't 
read the results. I also want to know how i can use the tb_streamer.pull_word() 
command with two poets. I mean with tb_streamer.recv() the third argument was 
the port, i.e. 1 or 2, what is the correct syntax if I want to use 
tb_streamet.pull_word() for two ports.

Thank in advance
Ishai


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

Re: [USRP-users] RFNoC Software Emulation

[Dario Pennisi via USRP-users]

Hi Brian,
I think I understand where you're going but I still think you may have more 
trouble than solutions. One for all is bandwidth. 10g Ethernet is just able to 
support one channel at 200 msps. Unless you're downsampling somewhere you won't 
be able to pass all that bandwidth across the network for more than one stream. 
Also, linux tends to drop udp packets if traffic is too high so even if your 
sockets are handled locally you may experience trouble passing all that data 
around. Of course what you say is really nice and is sort of an extension to 
the concept of gnuradio blocks however I think that in the end, since the code 
between rfnic and sw implementation is going to be different anyway it's better 
to just write an oot sw block which is functionally equivalent to the rfnic one 
and you just drop it in. Note that in any case you can't just randomly swap 
rfnoc blocks with SW emulated ones as in each transition from host to rfnoc and 
vice versa you need streamers and bandwidth so for example if the block you 
want to substitute is in the middle of a rfnoc chain probably you won't have 
bandwidth as you're going to have data go back and forth too many times.

Regarding the one input 8 outputs this is something we stumbled upon as well. 
It's not a rfnoc limitation but rather just uhd as basically you have to have 
equal number of inputs and outputs or streamers won't be enabled correctly. You 
can hack it and enable them manually in your driver but it's easier to just add 
dummy inputs or outputs... You just have to remember once again that a single 
rfnoc block with multiple inputs and or outputs will share bandwidth across 
them so for example on x310 you can't pump in or out of ports more than a total 
of around 300msps...

Dario Pennisi



On Sun, Jul 22, 2018 at 5:40 PM +0200, "Brian Padalino" 
mailto:bpadal...@gmail.com>> wrote:

Hey Dario,

On Sun, Jul 22, 2018 at 11:20 AM Dario Pennisi 
mailto:da...@iptronix.com>> wrote:
Hi Brian,
It really depends on what you want to achieve. If you just want to perform 
validation then you can use simulation which is already set up and 
straightforward if you follow the examples. Also it would allow you to verify 
even hls code and make sure it does what you expect in a cycle accurate way. If 
you follow your idea you will get only a model which may not be so accurate 
because there is a lot going on in the hw that is difficult to model such as 
the interaction between internal fifos. Also even assuming your model of the 
sdr is accurate you'll still have to ensure that model of your IP is also 
accurate...

I understand what you're saying here, but this is just a step for the end goal. 
 I want to be able to add software or hardware RFNoC blocks as an abstracted 
interface for different accelerators/processors I may have for my application.  
I want to extend the reality of an RFNoC block from only living inside of the 
FPGA of an X300 to living wherever you want on your local network, including 
hosted on the same machine, or on a larger machine that is able to aggregate 
multiple sources, or on a TI DSP that runs linux and has network access.

On top of this, I've run into a few different RFNoC related bugs when working 
with custom blocks which required me to change UHD.  Most recently it was 
related to an 8-output block I had with a single radio for the source and, on 
the receive side, the radio and port mappings were not being correctly applied 
leading to strange errors when trying to create the graph.  I envision a way to 
exercise all the different RFNoC blocks input/output/connections using software 
only, and not having to rely on someone writing FPGA blocks and a test image to 
verify correct functionality.

The easiest and most straight forward initial implementation to achieve this 
goal is to try to emulate an RFNoC block in software utilizing CHDR and UDP.  I 
understand the concept of issuing a register access on the host side isn't 
something that exists, but the framework is mostly there especially with the 
error handling of CDHR over UDP.

I hope this clears up my intent.

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

Re: [USRP-users] RFNoC Software Emulation

[Dario Pennisi via USRP-users]

Hi Brian,
It really depends on what you want to achieve. If you just want to perform 
validation then you can use simulation which is already set up and 
straightforward if you follow the examples. Also it would allow you to verify 
even hls code and make sure it does what you expect in a cycle accurate way. If 
you follow your idea you will get only a model which may not be so accurate 
because there is a lot going on in the hw that is difficult to model such as 
the interaction between internal fifos. Also even assuming your model of the 
sdr is accurate you'll still have to ensure that model of your IP is also 
accurate...

In my experience we just needed to prove algorithms with SW oot blocks that 
were simulating the behaviour by using integer math and then we rewrote the 
core in RTL and simulated it... This workflow proved to be the most reliable 
and straightforward... I may be wrong or misunderstanding your end goal but 
these are my 50 cents...

Dario Pennisi



On Sun, Jul 22, 2018 at 5:13 PM +0200, "Brian Padalino" 
mailto:bpadal...@gmail.com>> wrote:

Hey Dario,

On Sun, Jul 22, 2018 at 3:55 AM Dario Pennisi 
mailto:da...@iptronix.com>> wrote:
Hi Brian,
Don't think what you want to do is feasible. While the streaming data part is 
easy as it's basically just an oot block, emulating register writes is not 
possible because they go through APIs that send commands over the network. The 
only reasonable option I see to do what you want is to create a complete model 
of a uhd device that basically talks through sockets but seems a big task to 
undergo...

This is actually what I was thinking about doing, but I don't want to re-create 
the CHDR/UDP portion of everything going on under the hood and I want to 
produce this model out-of-tree.

I want to create a standalone executable which will listen on a UDP socket and 
interact with my normal UHD application through UDP.

I realize this may be a large task, but it also sounds like an extremely useful 
one.  Do you agree?

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

Re: [USRP-users] RFNoC Software Emulation

[Dario Pennisi via USRP-users]

Hi Brian,
Don't think what you want to do is feasible. While the streaming data part is 
easy as it's basically just an oot block, emulating register writes is not 
possible because they go through APIs that send commands over the network. The 
only reasonable option I see to do what you want is to create a complete model 
of a uhd device that basically talks through sockets but seems a big task to 
undergo...

Dario




On Sat, Jul 21, 2018 at 7:18 PM +0200, "Brian Padalino via USRP-users" 
mailto:usrp-users@lists.ettus.com>> wrote:

I have a software model which performs the exact task I want done in RFNoC.  I 
want to be able to integrate it into my UHD application in the RFNoC flow and 
be able to switch between the slow software model and the real RFNoC block in 
an FPGA.

Is there a way I can create a software process (daemon?) that is my model and 
basically gets the stream as sent by my UHD application and replies 
appropriately?  I am interested in doing everything the FPGA is capable of 
doing - setting/reading registers, sending/receiving streams, errors/fault 
detection, etc.

I am looking for this to be out of tree and not integrated in a "special" UHD.  
Any help or guidance on this would be useful.

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

Re: [USRP-users] x300 unrecoverable timeouts

[Dario Pennisi via USRP-users]

Hi,
We recently investigated a similar issue and have a clear understanding on what 
this comes from.
Commands sent by PC to usrp device are responded with an acknowledge. Each 
command has a sequence number and is sent asynchronously. On the receiving side 
there is a check on acknowledge sequence number and if one is lost system will 
basically give up. The reason why packets can get lost is simply that 
communication is using udp which gives no guarantee on packet delivery and 
linux may drop packets, incoming or outgoing, at any time, even worse if you 
are passing through a switch instead of having a 1:1 link.
We fixed this by patching code so that when sending commands we immediately 
wait for acknowledge and if it doesn't get back in time we retry. This of 
course does not allow pipelined command transfers but provides a reliable 
solution as trying to cache commands and resend them if ack is out of sequence 
won't work since resending commands at that point would change the order 
commands are executed and could be potentially very wrong.
Would be great if someone from usrp could discuss this a bit further and come 
out with a better solution...
Best regards,

Dario Pennisi




On Fri, Jul 13, 2018 at 2:29 AM +0200, "Keith k via USRP-users" 
mailto:usrp-users@lists.ettus.com>> wrote:

Hello Will

This sounds eerily similar to issues I've had using N200s. I basically found 
that working at high rates, using either STREAM_MODE_NUM_SAMPS_AND_DONE or 
using starts and stops was completely unusable. The system would go into an 
unrecoverable set of timeouts or overflows. I had to switch to using non 
interrupted continuous streaming and I had to make sure that the UHD threads 
were isolated to their own cpu cores in order to eliminate being preempted. 
This was the only way I could get stable runtime of the rx side during a long 
running application.

On Thu, Jul 12, 2018 at 1:22 PM, Brophy, William via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
While working to get coherent streams working, I ran into an issue using an 
x310 with two TwinRX daughterboards.
The issue starts with a series of "ERROR_CODE_OVERFLOW (Out of sequence error)" 
errors. In an attempt to recover from that, the rx streamer is thrown out and 
recreated. The next stream errors change to "ERROR_CODE_TIMEOUT". Once in this 
state, all future streams end with this error.
The x310 is connected over 10G ethernet.

I managed to reproduce this error with an example program based off of 
“rx_multi_samples.cpp”. I had to make the following changes:

  1.  STREAM_MODE_START_CONTINUOUS is now used, ending the stream with 
STREAM_MODE_STOP_CONTINUOUS
  2.  The stream delay was set to .01 (mostly to speed up the rate the error 
would occur)
  3.  Multi stream commands (and stop commands) are issued in repetition 
(start, stop, start, stop, etc.) rather than just one long stream
  4.  Each stream uses a different sampling rate (alternates between 25Msps and 
50Msps)
  5.  A small loop was added to the collect loop to slow down the thread enough 
to get overflow errors (but only sometimes, nothing crazy)
  6.  Once the out of sequence error is encountered 10 times in a row, the rx 
streamer is destroyed and re-created
  7.  Every stream command after step 5 ends in a timeout error

It is also worth pointing out that this does not happen if the sample rate does 
not change. The out of sequence errors will still happen until the rx streamer 
is re-created, but the timeout errors do not occur after that…

I attached the entire example program (with modifications) to this email.
I started it with the args:
rx_multi_samples --args addr=192.168.30.2 --subdev "A:0 A:1 B:0 B:1" --channels 
"0,1,2,3" --dilv --rate 5000 --nsamps 800

Is there something wrong with how we are using the interface? Is there steps we 
can take to either avoid or recover from this state?

I appreciate any help we can get…

Will

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




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

[USRP-users] EOB marker in RFNoC

[Dario Pennisi via USRP-users]

Hi,
we are working on a packet processor in RFNoC on x310 and we would need to 
receive EOB markers on the stream port. We developed a block that generates 
bursts of data on the host side with proper start/end of burst tagging and we 
fed its output to a custom rfnoc block but we never see EOB set on tuser.
Is there any particular procedure/way to have this working?
Thanks,

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

[USRP-users] issue with RFNoC signal generator block on X310 (TLDR)

[Dario Pennisi via USRP-users]

Hi,
A short question for which there is a larger underlying issue: if I connect a 
RX RFNoC Radio block to a TX RFNoC radio block, regardless of the presence of 
FIFOs in the middle nothing gets transmitted.
The only way it works seems to be by passing through the host by inserting two 
fifos and something like a mult const block on the host side so that data goes 
back and forth to/from the host.
Is there any reason this is happening?

Now the TL;DR part... for which I did this test:

I am developing a complex block with 3 inputs and 3 outputs. It is basically a 
transceiver block in which channels are configured this way:

In 0packet data in
In 1RF data in from RX0
In 2RF data in from RX1
Out 0 Packet data out
Out 1 RF Data out to TX0
Out 2 RF Data out to TX1

Basically I have a streaming input from the host that contains data packets 
that are modulated and output on one of the two RF ports that will be connected 
to radios.
On the opposite side I have two radio blocks connected to input ports 1 and 2 
and which are demodulated and output as packets on output port 0
Since rfnoc works at 200 MSPS by default and since bus does not have enough 
bandwidth I reduced system clock frequency to 120 MHz using device3 block in 
gnuradio. This way overall bandwidth (166 MHx x 64 bit) is still less than what 
I am handling (2x 120MSPS @ 32 bit + 1x very low bandwidth channel).
Rx side works perfectly while TX side seems to have an issue. First of all I 
want to transmit in bursts at given timestamps so my tuser packets would 
contain valid timestamp for first packet of the burst and will contain end of 
burst on the last packet. Unfortunately I have not gone as far as this since 
when I start transmitting I see that after a few packets my block receives a 
low ready which halts it after some packets (around 6).
Checking radio block I can see it receives some packets (less than the ones 
transmitted) and then it sets ready low after it sees tvalid low and 
subsequently status is set to underrun.
After this everything is locked up and I have to reprogram FPGA in order to 
restart it.
Suspecting that packets where too small I increased their size to the same of 
the signal generator block sample but with no results.
Now the question is what could be going wrong? It should not be an issue with 
bandwidth and I don't see why packets seem to be lost somewhere although I see 
that after a short while things freeze up and packets don't make it to the 
radio.
This is the reason why I tested the radio loopback and now I am suspecting 
there is some issue with UHD drivers that may not enable correctly all the 
routing paths if host is not in the loop for the tx part.

Thank you,

Dario Pennisi

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

Re: [USRP-users] systemverilog files in rfnoc block

[Dario Pennisi via USRP-users]

Hi,
I pushed the fix on my fork:

https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c

Dario Pennisi








On Wed, Oct 25, 2017 at 8:06 PM +0200, "Jade Anderson" 
> wrote:


Hi,
Below is a question about sytemverilog support from August, that seems 
unresolved.
I found this workaround, but why does the scripted flow not support 
systemverilog design files?
Are there plans to make this change to support designs in sytemverilog?
  If not, then can you please point me to an example of how to include a 
synthesized netlist into a build?  I can synthesize my systemverilog module in 
Vivado for the  X310 with no problems.
All I need to do is then import it into the x310 build.

Thanks
Jade Anderson


Message: 5
Date: Fri, 25 Aug 2017 19:55:11 +
From: Dario Pennisi
To: "usrp-users@lists.ettus.com"
Subject: [USRP-users] systemverilog files in rfnoc block
Message-ID: <150369090.91...@iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

hi,

i am trying to include a couple of systemverilog files in the list of sources 
for a custom rfnoc block.

if i do that i can see in the log that all files with .sv extension are ignored 
and of course their modules are not found. if i launch compilation in gui mode 
and then add files back it works...

is there any way of avoiding this manual step?

thanks,


Dario Pennisi
-- next part --
An HTML attachment was scrubbed...
URL:

--

Message: 6
Date: Fri, 25 Aug 2017 20:27:18 +
From: Dario Pennisi
To: "usrp-users@lists.ettus.com"
Subject: Re: [USRP-users] systemverilog files in rfnoc block
Message-ID: <1503692838342.55...@iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

i think i found the issue...

tcl script file usrp3/tools/scripts/viv_utils.tcl actually contains 
instructions to add files to project based on their extensions and .sv is not 
listed so files are skipped.

adding a case for .sv works but it also includes axi_crossbar_intf.sv which 
seems to be a simulation file and won't compile so i had to exclude that file...

is there any reason why sv files are not included or is that just a lazy way to 
exclude simulation sources?

unfortunately i need to use some systemverilog constructs and with .v extension 
those seem not to be accepted...

thanks,


Dario Pennisi

___
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 with 2 inputs and 1 output

[Dario Pennisi via USRP-users]

You may want to check 
this:https://www.mail-archive.com/usrp-users@lists.ettus.com/msg03271.html

Dario Pennisi








On Sat, Oct 14, 2017 at 10:31 AM +0200, "Andrew Thommesen" 
> wrote:


Hi Dario,


Thanks. I did try that, but I am using a TwinRx daughtercard that runs at a 
slower 100MSPS so I don't think its an issue. It does work when I connect the 
inputs to radio and outputs to host blocks. My problems start when I try to 
connect one of the outputs to a radio for Tx from a WBX daughtercard..


Andy

From: Dario Pennisi 
Sent: 13 October 2017 19:32:33
To: usrp-users@lists.ettus.com; Andrew Thommesen
Subject: Re: [USRP-users] RFNoC Block with 2 inputs and 1 output

Hi Andy,
As I wrote you have to check available bandwidth. For x310 input data is 32 
bits at 160 MHz whereas radios run by default at 200 MHz so you won't be able 
to fit 800 mbyte/sec in a port able to receive just 640 mbyte/sec.
Note that setting sampling frequency in rfnoc radio is useless. To change 
sampling clock you have to set system clock attribute in device3. Of course 
same thing goes for outputs

Doing this worked for me... I'm connecting inputs to radio and outputs to host 
blocks...

Let me know if this helps...

Dario Pennisi





On Fri, Oct 13, 2017 at 9:15 PM +0200, "Andrew Thommesen" 
> wrote:


Hi Dario,


Thanks for the information. I managed to get this working as long as each 
output is connected to a rx_streamer (i.e. QT GUI Time Sink). However, when I 
try to use the block within a loopback configuration 
(https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback; output 0 connected 
to radio Tx block and output 1 connected to a sink) I get an overflow on 
channel 0. I am thinking that the delay in issuing the steam command for 
channel 0 followed by channel 1 is causing the fifo to overflow? Is it possible 
to enable both streams at the same time?


Andy


From: Dario Pennisi 
Sent: 12 October 2017 04:54:00
To: usrp-users@lists.ettus.com; Andrew Thommesen
Subject: Re: [USRP-users] RFNoC Block with 2 inputs and 1 output

Hi Andy,
Same issue here and you can probably find a set of emails form me in this list 
that went unanswered. I spent quite some time debugging this just to find out 
that apparently this is not supported. The issue in my opinion is that sofware 
does not initialize the streamer for the second input unless you also have a 
second output. Just add a second output on the block definition and connect it 
to null sink and if everything else is fine it should work.
Note that since input axi bus is 64 but at 166 MHz you won't be able to have 2 
inputs at 32 bit/200 MHz which is the default radios will work at so you have 
to change system sampling frequency to 120 MHz using the attribute in 
device3... Don't even try changing it in radio block as the sampling frequency 
there is not doing anything at all.
Good luck,

Dario Pennisi



On Wed, Oct 11, 2017 at 10:11 PM +0200, "Andrew Thommesen via USRP-users" 
> wrote:

Hi all,

I am trying to create a custom RFNoC block with 2 inputs and 1 output. I have 
attached my block code as well as the XML files for the UHD and GNU radio 
integration. The block behaves as expected when I run the testbench. However, 
when synthesised and used within the GNU radio flowgraph it does not seem to 
output anything. Further investigation using chipscope revealed that 
m_axis_data_tvalid is only ever 0 or 1. In simulation, the value can be 3 when 
data is received on both input channels. This suggests that on the hardware I 
am not receiving data from both streams, which would explain why I never get 
any output. This may suggest that the XML files are incorrect? Does anyone know 
what I could be doing wrong?

Thanks,

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

Re: [USRP-users] rfnoc blocks with multiple inputs/outputs

[Dario Pennisi via USRP-users]

Hi Mike,
Unfortunately it must be more widespread as I am using 2 ubx160 and connecting 
2 rfnoc radio blocks to the two inputs of my single block.
If you look in the history of the last few weeks you will see that I asked for 
help without really getting a final answer and after some debugging I came to 
the conclusion that it is a as issue and as you can see from Andy's emails I am 
not the only one experiencing this. Not sure about his setup tough.

You will see I also sent an email sort of a week ago asking about the nports 
parameter in rfnoc xml rather than declaring two separate ports but got no 
answer on that either...

Thanks,

Dario Pennisi



On Fri, Oct 13, 2017 at 10:35 PM +0200, "Michael West" 
<michael.w...@ettus.com<mailto:michael.w...@ettus.com>> wrote:

Hi Dario,

OK.  I dug in a bit more and I can now tell you are most likely using the 2 
streams from a single TwinRX daughterboard by the nature of the issue.  The 
root cause is that Twin RX uses ports 0 and 1 on the radio block (all other 
daughterboards only use port 0) and only port 0 is receiving the stream command 
when there is a single output port on your block.  The root of the issue is in 
the code block found here:  
https://github.com/EttusResearch/uhd/blob/maint/host/lib/rfnoc/source_block_ctrl_base.cpp#L29

Notice that the "chan" parameter is used to forward the command to the upstream 
block.  That parameter is the port on the block.  Since your block has only one 
output channel, chan is set to 0.  When you add the second output to your 
block, the function is called twice; once with chan=0 and once with chan=1.

Your workaround adding a second output port will work for now until the issue 
is resolved.  Since this only affects TwinRX in this particular use case and 
there are several other use cases we must consider and test for any proposed 
fix, a proper permanent resolution may take some time.

Regards,
Michael

On Fri, Oct 13, 2017 at 12:38 PM, Dario Pennisi 
<da...@iptronix.com<mailto:da...@iptronix.com>> wrote:
Hi Mike,
Unfortunately what you write is not what I see. Split stream has 1 input and 2 
outputs and that works. What I am saying is that the opposite doesn't. This 
seems to be due to the fact that for some reason blocks feeding second input 
are not started if block does not have a second port.
With the same block, even without adding code for a second output but just 
adding the fake output to the block descriptors made it work...
I'm sure there's a bug somewhere in uhd or gr-ettus as he is fine.
Best regards,

Dario Pennisi








On Fri, Oct 13, 2017 at 9:32 PM +0200, "Michael West" 
<michael.w...@ettus.com<mailto:michael.w...@ettus.com>> wrote:

Hi Dario,

A block can have any number of inputs and outputs, so 2 inputs and 1 output is 
fine.  The Split Stream block is an example of an asymmetric block.

The UHD XML description of the Split Stream block can be found here:  
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/include/uhd/rfnoc/blocks/splitstream.xml
The GnuRadio XML description of the Split Stream block can be found here:  
https://github.com/EttusResearch/gr-ettus/blob/master/grc/uhd_rfnoc_split_stream.xml

Hopefully, those examples will help.

As far as the multiple ports at 200 Msps on a single block, it is a known 
issue.  The bus clock would need to be raised to the CE clock of 214.286 MHz to 
allow 2 ports to operate at 200 Msps in one block, but doing that causes the 
FPGA build to fail timing.  As far as a workaround or trick, there is a way 
where you can hack up the core FPGA code and make a single module with 2 
noc_shells connected to separate crossbar ports in the x300_core code, but that 
is a bit more involved.  If you are daring and curious, look at the way 
noc_block_axi_dma_fifo and noc_block_radio_core blocks are instantiated and 
connected to the crossbar in 
x300_core.v<https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/x300/x300_core.v>.

Regards,
Michael

On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi,
I am still struggling with a block which should have 2 inputs and 1 output. 
Apparently everything is fine with both FPGA and software but the second input 
is not fed with data.
I could not find any example of an asymmetric block with different number of 
inputs/outputs so I am starting to suspect this is not supported. Can anyone 
tell me if this is the case and I need to add a dummy output?

Also, when defining block I see that in the xml there is the possibility to 
specify nports parameter so that a single port definition provides more than 
one port. If i set nports=2 for the input I am not sure how to define the 
gnuradio xml descriptor and If I just describe two ports as usual block will 
not initialize properly.

Finally, I understand that system clock rate on AXI bus is

Re: [USRP-users] rfnoc blocks with multiple inputs/outputs

[Dario Pennisi via USRP-users]

Hi Mike,
Unfortunately what you write is not what I see. Split stream has 1 input and 2 
outputs and that works. What I am saying is that the opposite doesn't. This 
seems to be due to the fact that for some reason blocks feeding second input 
are not started if block does not have a second port.
With the same block, even without adding code for a second output but just 
adding the fake output to the block descriptors made it work...
I'm sure there's a bug somewhere in uhd or gr-ettus as he is fine.
Best regards,

Dario Pennisi








On Fri, Oct 13, 2017 at 9:32 PM +0200, "Michael West" 
<michael.w...@ettus.com<mailto:michael.w...@ettus.com>> wrote:

Hi Dario,

A block can have any number of inputs and outputs, so 2 inputs and 1 output is 
fine.  The Split Stream block is an example of an asymmetric block.

The UHD XML description of the Split Stream block can be found here:  
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/include/uhd/rfnoc/blocks/splitstream.xml
The GnuRadio XML description of the Split Stream block can be found here:  
https://github.com/EttusResearch/gr-ettus/blob/master/grc/uhd_rfnoc_split_stream.xml

Hopefully, those examples will help.

As far as the multiple ports at 200 Msps on a single block, it is a known 
issue.  The bus clock would need to be raised to the CE clock of 214.286 MHz to 
allow 2 ports to operate at 200 Msps in one block, but doing that causes the 
FPGA build to fail timing.  As far as a workaround or trick, there is a way 
where you can hack up the core FPGA code and make a single module with 2 
noc_shells connected to separate crossbar ports in the x300_core code, but that 
is a bit more involved.  If you are daring and curious, look at the way 
noc_block_axi_dma_fifo and noc_block_radio_core blocks are instantiated and 
connected to the crossbar in 
x300_core.v<https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/x300/x300_core.v>.

Regards,
Michael

On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi,
I am still struggling with a block which should have 2 inputs and 1 output. 
Apparently everything is fine with both FPGA and software but the second input 
is not fed with data.
I could not find any example of an asymmetric block with different number of 
inputs/outputs so I am starting to suspect this is not supported. Can anyone 
tell me if this is the case and I need to add a dummy output?

Also, when defining block I see that in the xml there is the possibility to 
specify nports parameter so that a single port definition provides more than 
one port. If i set nports=2 for the input I am not sure how to define the 
gnuradio xml descriptor and If I just describe two ports as usual block will 
not initialize properly.

Finally, I understand that system clock rate on AXI bus is 166 MHz and since 
NOC ports are 64 bits, on X310 a single block should not be able to process two 
input streams at 200 MSPS.
Even raising AXI bus clock to 200 MHz would fail as but would still not provide 
sufficient overhead for packet headers.
Is there any suggested trick to handle this situation? Is it eventually 
possible to have a single rfnoc block connect to two AXI ports rather than just 
one?

Thanks,

Dario Pennisi


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


___
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 with 2 inputs and 1 output

[Dario Pennisi via USRP-users]

Hi Andy,
As I wrote you have to check available bandwidth. For x310 input data is 32 
bits at 160 MHz whereas radios run by default at 200 MHz so you won't be able 
to fit 800 mbyte/sec in a port able to receive just 640 mbyte/sec.
Note that setting sampling frequency in rfnoc radio is useless. To change 
sampling clock you have to set system clock attribute in device3. Of course 
same thing goes for outputs

Doing this worked for me... I'm connecting inputs to radio and outputs to host 
blocks...

Let me know if this helps...

Dario Pennisi





On Fri, Oct 13, 2017 at 9:15 PM +0200, "Andrew Thommesen" 
> wrote:


Hi Dario,


Thanks for the information. I managed to get this working as long as each 
output is connected to a rx_streamer (i.e. QT GUI Time Sink). However, when I 
try to use the block within a loopback configuration 
(https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback; output 0 connected 
to radio Tx block and output 1 connected to a sink) I get an overflow on 
channel 0. I am thinking that the delay in issuing the steam command for 
channel 0 followed by channel 1 is causing the fifo to overflow? Is it possible 
to enable both streams at the same time?


Andy


From: Dario Pennisi 
Sent: 12 October 2017 04:54:00
To: usrp-users@lists.ettus.com; Andrew Thommesen
Subject: Re: [USRP-users] RFNoC Block with 2 inputs and 1 output

Hi Andy,
Same issue here and you can probably find a set of emails form me in this list 
that went unanswered. I spent quite some time debugging this just to find out 
that apparently this is not supported. The issue in my opinion is that sofware 
does not initialize the streamer for the second input unless you also have a 
second output. Just add a second output on the block definition and connect it 
to null sink and if everything else is fine it should work.
Note that since input axi bus is 64 but at 166 MHz you won't be able to have 2 
inputs at 32 bit/200 MHz which is the default radios will work at so you have 
to change system sampling frequency to 120 MHz using the attribute in 
device3... Don't even try changing it in radio block as the sampling frequency 
there is not doing anything at all.
Good luck,

Dario Pennisi



On Wed, Oct 11, 2017 at 10:11 PM +0200, "Andrew Thommesen via USRP-users" 
> wrote:

Hi all,

I am trying to create a custom RFNoC block with 2 inputs and 1 output. I have 
attached my block code as well as the XML files for the UHD and GNU radio 
integration. The block behaves as expected when I run the testbench. However, 
when synthesised and used within the GNU radio flowgraph it does not seem to 
output anything. Further investigation using chipscope revealed that 
m_axis_data_tvalid is only ever 0 or 1. In simulation, the value can be 3 when 
data is received on both input channels. This suggests that on the hardware I 
am not receiving data from both streams, which would explain why I never get 
any output. This may suggest that the XML files are incorrect? Does anyone know 
what I could be doing wrong?

Thanks,

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

Re: [USRP-users] No output from OOT RFNOC Module

[Dario Pennisi via USRP-users]

Hi,
If your block is sending small amounts of bursty data the timeout being printed 
is irrelevant as it just indicates no data has been sent for a given time lapse 
not that no data has been received at all.

Dario Pennisi








On Wed, Oct 11, 2017 at 10:10 PM +0200, "John Medrano via USRP-users" 
> wrote:

We are in process of debugging an out of tree module that we created. It is a 
source object that generates a given sequence.

We have compiled and loaded in our X310 device and all looks good. But when we 
run it, we get no output.

Below is some of the output from the device.

Two questions:

1. Why do we receive the following debug message:
[INFO] [RFNOC] Assuming max packet size for 0/memory_0

2. What is meant by RFNOC blocks with streaming port, and creating rx_streamer 
messages?

Please advise,

Thanks,
John

[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
INFO: Setting args on 0/FIFO_0 (gr_vlen=256,spp=256)
DEBUG: output item size: 2048
INFO: Setting args on 0/memory_0 (gr_vlen=256,spp=256)
DEBUG: output item size: 2048
[INFO] [RFNOC] Assuming max packet size for 0/memory_0
DEBUG: check_topology()
DEBUG: RFNoC blocks with streaming ports: 1
DEBUG: start(): ninputs == 0 noutputs == 1
DEBUG: creating rx streamer with: 
gr_vlen=256,spp=256,block_id=0/FIFO_0,block_port=0
timeout on chan 0

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

[USRP-users] rfnoc blocks with multiple inputs/outputs

[Dario Pennisi via USRP-users]

Hi,
I am still struggling with a block which should have 2 inputs and 1 output. 
Apparently everything is fine with both FPGA and software but the second input 
is not fed with data.
I could not find any example of an asymmetric block with different number of 
inputs/outputs so I am starting to suspect this is not supported. Can anyone 
tell me if this is the case and I need to add a dummy output?

Also, when defining block I see that in the xml there is the possibility to 
specify nports parameter so that a single port definition provides more than 
one port. If i set nports=2 for the input I am not sure how to define the 
gnuradio xml descriptor and If I just describe two ports as usual block will 
not initialize properly.

Finally, I understand that system clock rate on AXI bus is 166 MHz and since 
NOC ports are 64 bits, on X310 a single block should not be able to process two 
input streams at 200 MSPS.
Even raising AXI bus clock to 200 MHz would fail as but would still not provide 
sufficient overhead for packet headers.
Is there any suggested trick to handle this situation? Is it eventually 
possible to have a single rfnoc block connect to two AXI ports rather than just 
one?

Thanks,

Dario Pennisi

___
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 with two inputs

[Dario Pennisi via USRP-users]

Hi nick,
Thank you.. the example you posted seems a 1 input 2 output block which is the 
opposite I'm trying to do.
Btw, is there any reason why you seem to be excluding software is an issue? 
Note that in my case I have a cpp controller as I need to do some custom 
register programming.
I noticed that in rfnoc XML block definition it's possible to either specify 
two sinks or have one sync with nports set to 2 but could not really spot what 
the difference is other than that setting nports to 2 i see that noc_block_impl 
is actually setting up just one sink and is raising an error for the mismatch 
between the two XML files (with the one in GRC)  so I guess this setting 
requires some special stuff in GRC XML as well but could not figure that out
Thanks,

Dario Pennisi





Da: Nick Foster
Inviato: martedì 26 settembre, 20:27
Oggetto: Re: [USRP-users] rfnoc block with two inputs
A: Dario Pennisi, usrp-users@lists.ettus.com


Yeah, I agree with that assessment. I don't know what the problem is, either. 
For reference, though, here's the relevant parts of a two-input-one-output 
RFNoC block I did. This works for me.

Note that NUM_PORTS can be anything you want. I'm currently using NUM_PORTS=2. 
NUM_CHANNELS is 4, since I'm putting two streams into each sc16 input.

  // RFNoC Shell
  wire [31:0] set_data[0:NUM_PORTS-1];
  wire [7:0]  set_addr[0:NUM_PORTS-1];
  wire [NUM_PORTS-1:0] set_stb;
  reg [63:0] rb_data[0:NUM_PORTS-1];
  wire [7:0] rb_addr[0:NUM_PORTS-1];

  wire [63:0]   cmdout_tdata, ackin_tdata;
  wire  cmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [NUM_PORTS-1:0] clear_tx_seqnum;

  wire [63:0] str_sink_tdata;
  wire str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata[0:NUM_PORTS-1];
  wire [NUM_PORTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid[0:NUM_PORTS-1];
  wire [15:0] resp_in_dst_sid;
  wire [15:0] resp_out_dst_sid[0:NUM_PORTS-1];

  // Set next destination in chain
  wire [15:0] next_dst[0:NUM_PORTS-1];

  // AXI Wrapper
  // input (sink) data
  wire [31:0]  in_tdata;
  wire [127:0] in_tuser;
  wire in_tlast, in_tvalid, in_tready;

  // predistorter output data (four of these)
  wire [15:0]  out_tdata[0:NUM_CHANNELS-1];
  wire [NUM_CHANNELS-1:0] out_tlast, out_tvalid, out_tready;

  wire [127:0] out_tuser[0:NUM_PORTS-1]; //only two of these
  //
  // Instantiations
  //

  // RFNoC Shell
  noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE[7:0]),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_PORTS))
  noc_shell (
.bus_clk(bus_clk),
.bus_rst(bus_rst),
.i_tdata(i_tdata),
.i_tlast(i_tlast),
.i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata),
.o_tlast(o_tlast),
.o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk),
.reset(ce_rst),
// Control Sink
.set_data({set_data[1], set_data[0]}),
.set_addr({set_addr[1], set_addr[0]}),
.set_stb({set_stb[1], set_stb[0]}),
.rb_data({rb_data[1], rb_data[0]}),
.rb_stb({NUM_PORTS{1'b1}}),
.rb_addr({rb_addr[1], rb_addr[0]}),
// Control Source (unused)
.cmdout_tdata(cmdout_tdata),
.cmdout_tlast(cmdout_tlast),
.cmdout_tvalid(cmdout_tvalid),
.cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata),
.ackin_tlast(ackin_tlast),
.ackin_tvalid(ackin_tvalid),
.ackin_tready(ackin_tready),
.resp_in_dst_sid({resp_in_dst_sid[1], resp_in_dst_sid[0]}),
.resp_out_dst_sid({resp_out_dst_sid[1], resp_out_dst_sid[0]}),
// Stream Sink
.str_sink_tdata(str_sink_tdata),
.str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid),
.str_sink_tready(str_sink_tready),
// Stream Sources //TODO ideally should be parameterized for NUM_CHANNELS
.str_src_tdata({str_src_tdata[1], str_src_tdata[0]}),
.str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid),
.str_src_tready(str_src_tready),
.src_sid({src_sid[1], src_sid[0]}),
.next_dst_sid({next_dst[1], next_dst[0]}),
.clear_tx_seqnum(clear_tx_seqnum),
.debug(debug));

  assign ackin_tready = 1'b1;

<..snip...>

  wire [31:0] mux_tdata[0:NUM_PORTS-1];
  wire [NUM_PORTS-1:0] mux_tlast, mux_tvalid, mux_tready;

   axi_wrapper #(
  .SIMPLE_MODE(0) /* Handle header internally */)
   axi_wrapper_inst (
  .clk(ce_clk), .reset(ce_rst),
  .clear_tx_seqnum(clear_tx_seqnum[0]),
  .next_dst(next_dst[0]),
  .set_stb(), .set_addr(), .set_data(),
  .i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast), 
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
  .o_tdata(str_src_tdata[0]), .o_tlast(str_src_tlast[0]), 
.o_tvalid(str_src_tvalid[0]), .o_tready(str_src_tready[0]),
  

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi Nick,
Sure. The block is a demodulator so basically it inputs samples and outputs 
packet bytes in bursts so of course we have rate change.
The relevant code is below:

  cvita_hdr_decoder cvita_hdr_decoder0 (
  .header(m_axis0_data_tuser),
  .pkt_type(), .eob(),.has_time(),
  .seqnum(),   .length(), .payload_length(),
  .src_sid(),  .dst_sid(),
  .vita_time(vita_time_in[0])
  );
  cvita_hdr_decoder cvita_hdr_decoder1 (
  .header(m_axis01_data_tuser),
  .pkt_type(), .eob(),.has_time(),
  .seqnum(),   .length(), .payload_length(),
  .src_sid(),  .dst_sid(),
  .vita_time(vita_time_in[1])
  );

  cvita_hdr_encoder cvita_hdr_encoder (
.pkt_type(2'd0), .eob(1'b1), .has_time(1'b1),
.seqnum(0), .payload_length(0), .dst_sid(next_dst_sid[0]), 
.src_sid(src_sid[0]),
.vita_time(vita_time_out),
.header(s_axis0_data_tuser));

Basically I extract the time from incoming packets and then use that to feed 
timestamp to the processing logic which outputs its timestamp in  vita_time_out.
Since I am outputting bursts I am setting eob and has time and since I don’t 
know packet length in advance I set length to 0.
src_sid and dst_sid are set equal to those decoded by noc shell for the first 
channel.

The one thing I don’t understand here is what has this to do with the fact that 
one input channel is not streaming…
As I mentioned in this condition my first input channel is streaming data and 
processing logic connected to it is working perfectly and outputting decoded 
data which I can receive correctly on the host. The problem is that data is not 
being streamed to the second input channel (or at least if it is then it’s not 
being demultiplexed by noc shell). I can’t see any logic that makes cvita hdr, 
which is sent to the output, dependent on what’s on the input….

Dario Pennisi

From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, September 26, 2017 5:16 PM
To: Dario Pennisi ; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc block with two inputs

Dario,

Glad simulation appears to be working.

Since you aren't using simple mode in the AXI wrapper (I assume because you're 
rate-changing inside the block, or some such) can you post the section of your 
code which handles the VITA headers?

Nick

On Tue, Sep 26, 2017 at 5:15 AM Dario Pennisi 
> wrote:
Hi,
I managed to get a good simulation for the two inputs. I did it by modifying 
default test bench this way:

  *   localparam NUM_STREAMS= 2;  // Number of test bench streams
  *   modified RFNOC_CONNECT to two RFNOC_CONNECT_BLOCK_PORT calls each with a 
different port. Port 0 of TB connected to port 0 of DUT and port 1 of TB 
connected to port 1 of DUT
  *   modified data streaming part with two calls to tb_streamer.send each with 
a different channel

this way I can see data being pumped in on both ports, at least in simulation. 
IP does what it should so at this point I tend to think there is no issue on 
the FPGA side.

Since I am connecting to two radio blocks and since internal bus is 166 MHz/64 
bit I modified the device3 arguments to "master_clock_rate=120e6", this way I 
would have 120MSPS at 32 bit x 2 muxed on the input bus of the IP. This should 
leave enough room for overhead.

Now. In these conditions I still don’t see data coming from the second channel 
so am thinking that the issue must be on the software side.

Any help would be greatly appreciated.
Thanks,

Dario Pennisi
From: Dario Pennisi
Sent: Tuesday, September 26, 2017 12:00 PM

To: usrp-users@lists.ettus.com; Nick Foster 
>
Subject: RE: [USRP-users] rfnoc block with two inputs

Hi,
I moved forward a bit but didn’t really come up to a solution.
In my block I doublechecked the signals which are replicated for each input and 
made sure they are connected at top level. This turned out to be apparently 
useless because I only have one output so src_sid and dst_sid for the second 
input channel are basically not going anywhere as there is no second output.
Is it at all possible to have 2 inputs and 1 output or there is a strict need 
to have the same number of inputs and outputs?
On the host side which are the points I can tap into to check what’s going on?

I also would be interested in trying simulation but didn’t find any example of 
simulation with 2 inputs.
Thanks,

Dario Pennisi
From: Dario Pennisi
Sent: Monday, September 25, 2017 11:11 PM
To: usrp-users@lists.ettus.com; Nick Foster 
>
Subject: Re: [USRP-users] rfnoc block with two inputs

Hi Nick,
Thank you for your feedback. I didn't notice src and data Sid are per input 
however looking at code I don't think this is the problem. My understanding is 
that src Sid is used to form cvita packet going out of the block. In simple 
mode axis wrapper doesn't seem to use 

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi,
I managed to get a good simulation for the two inputs. I did it by modifying 
default test bench this way:

  *   localparam NUM_STREAMS= 2;  // Number of test bench streams
  *   modified RFNOC_CONNECT to two RFNOC_CONNECT_BLOCK_PORT calls each with a 
different port. Port 0 of TB connected to port 0 of DUT and port 1 of TB 
connected to port 1 of DUT
  *   modified data streaming part with two calls to tb_streamer.send each with 
a different channel

this way I can see data being pumped in on both ports, at least in simulation. 
IP does what it should so at this point I tend to think there is no issue on 
the FPGA side.

Since I am connecting to two radio blocks and since internal bus is 166 MHz/64 
bit I modified the device3 arguments to "master_clock_rate=120e6", this way I 
would have 120MSPS at 32 bit x 2 muxed on the input bus of the IP. This should 
leave enough room for overhead.

Now. In these conditions I still don't see data coming from the second channel 
so am thinking that the issue must be on the software side.

Any help would be greatly appreciated.
Thanks,

Dario Pennisi
From: Dario Pennisi
Sent: Tuesday, September 26, 2017 12:00 PM
To: usrp-users@lists.ettus.com; Nick Foster 
Subject: RE: [USRP-users] rfnoc block with two inputs

Hi,
I moved forward a bit but didn't really come up to a solution.
In my block I doublechecked the signals which are replicated for each input and 
made sure they are connected at top level. This turned out to be apparently 
useless because I only have one output so src_sid and dst_sid for the second 
input channel are basically not going anywhere as there is no second output.
Is it at all possible to have 2 inputs and 1 output or there is a strict need 
to have the same number of inputs and outputs?
On the host side which are the points I can tap into to check what's going on?

I also would be interested in trying simulation but didn't find any example of 
simulation with 2 inputs.
Thanks,

Dario Pennisi
From: Dario Pennisi
Sent: Monday, September 25, 2017 11:11 PM
To: usrp-users@lists.ettus.com; Nick Foster 
>
Subject: Re: [USRP-users] rfnoc block with two inputs

Hi Nick,
Thank you for your feedback. I didn't notice src and data Sid are per input 
however looking at code I don't think this is the problem. My understanding is 
that src Sid is used to form cvita packet going out of the block. In simple 
mode axis wrapper doesn't seem to use while it is used by cvita encoder used 
for tuser. In my case I have 2 inputs and 1 output. I am using Sid form channel 
0 to create cvita header for the output.
Since I don't have a second output it seems to me src and day Sid for 2nd input 
are not used anyway...
For the rest there doesn't seem to be any other connection.
Am I missing something?
Btw is there any example of a block with 2 in and 1 out? I found only addsub 
which has 2 out and is not even using axis wrapper...
Thanks
Dario Pennisi



On Mon, Sep 25, 2017 at 9:28 PM +0200, "Nick Foster" 
> wrote:
Couple of problems just offhand.

* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)). Again, 
see noc_shell.v. I don't think this is a problem for you, though.

You should be getting errors in simulation (or warnings in synthesis) right 
now. Look very carefully through these warnings to see which signals are 
undriven. My guess is src_sid is undriven on the top 16 bits and so you can't 
set src_sid correctly for input 1.

Nick

On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi 
> wrote:
Hi,
It's quite complex and long... posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi,
I moved forward a bit but didn't really come up to a solution.
In my block I doublechecked the signals which are replicated for each input and 
made sure they are connected at top level. This turned out to be apparently 
useless because I only have one output so src_sid and dst_sid for the second 
input channel are basically not going anywhere as there is no second output.
Is it at all possible to have 2 inputs and 1 output or there is a strict need 
to have the same number of inputs and outputs?
On the host side which are the points I can tap into to check what's going on?

I also would be interested in trying simulation but didn't find any example of 
simulation with 2 inputs.
Thanks,

Dario Pennisi
From: Dario Pennisi
Sent: Monday, September 25, 2017 11:11 PM
To: usrp-users@lists.ettus.com; Nick Foster 
Subject: Re: [USRP-users] rfnoc block with two inputs

Hi Nick,
Thank you for your feedback. I didn't notice src and data Sid are per input 
however looking at code I don't think this is the problem. My understanding is 
that src Sid is used to form cvita packet going out of the block. In simple 
mode axis wrapper doesn't seem to use while it is used by cvita encoder used 
for tuser. In my case I have 2 inputs and 1 output. I am using Sid form channel 
0 to create cvita header for the output.
Since I don't have a second output it seems to me src and day Sid for 2nd input 
are not used anyway...
For the rest there doesn't seem to be any other connection.
Am I missing something?
Btw is there any example of a block with 2 in and 1 out? I found only addsub 
which has 2 out and is not even using axis wrapper...
Thanks
Dario Pennisi





On Mon, Sep 25, 2017 at 9:28 PM +0200, "Nick Foster" 
> wrote:
Couple of problems just offhand.

* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)). Again, 
see noc_shell.v. I don't think this is a problem for you, though.

You should be getting errors in simulation (or warnings in synthesis) right 
now. Look very carefully through these warnings to see which signals are 
undriven. My guess is src_sid is undriven on the top 16 bits and so you can't 
set src_sid correctly for input 1.

Nick

On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi 
> wrote:
Hi,
It's quite complex and long... posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(
.NOC_ID(NOC_ID),
.INPUT_PORTS(2)
)
  noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid), 
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid), 
.o_tready(o_tready),
// Computer Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
// Control Source
.cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast), 
.cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast), 
.ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast), 
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast), 
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
// Stream IDs set by host
.src_sid(src_sid),   // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
.resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for input 
stream responses / errors
.resp_out_dst_sid(resp_out_dst_sid), // 

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi Nick,
Thank you for your feedback. I didn't notice src and data Sid are per input 
however looking at code I don't think this is the problem. My understanding is 
that src Sid is used to form cvita packet going out of the block. In simple 
mode axis wrapper doesn't seem to use while it is used by cvita encoder used 
for tuser. In my case I have 2 inputs and 1 output. I am using Sid form channel 
0 to create cvita header for the output.
Since I don't have a second output it seems to me src and day Sid for 2nd input 
are not used anyway...
For the rest there doesn't seem to be any other connection.
Am I missing something?

Btw is there any example of a block with 2 in and 1 out? I found only addsub 
which has 2 out and is not even using axis wrapper...
Thanks

Dario Pennisi








On Mon, Sep 25, 2017 at 9:28 PM +0200, "Nick Foster" 
> wrote:

Couple of problems just offhand.

* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)). Again, 
see noc_shell.v. I don't think this is a problem for you, though.

You should be getting errors in simulation (or warnings in synthesis) right 
now. Look very carefully through these warnings to see which signals are 
undriven. My guess is src_sid is undriven on the top 16 bits and so you can't 
set src_sid correctly for input 1.

Nick

On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi 
> wrote:
Hi,
It’s quite complex and long… posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(
.NOC_ID(NOC_ID),
.INPUT_PORTS(2)
)
  noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid), 
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid), 
.o_tready(o_tready),
// Computer Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
// Control Source
.cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast), 
.cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast), 
.ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast), 
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast), 
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
// Stream IDs set by host
.src_sid(src_sid),   // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
.resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for input 
stream responses / errors
.resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for output 
stream responses / errors
// Misc
.vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
.debug(debug));

  
  //
  // AXI Wrapper
  // Convert RFNoC Shell interface into AXI stream interface
  //
  
  wire [31:0]  m_axis0_data_tdata;
  wire m_axis0_data_tlast;
  wire m_axis0_data_tvalid;
  wire m_axis0_data_tready;
  wire [127:0] m_axis0_data_tuser;

  wire [31:0]  m_axis1_data_tdata;
  wire m_axis1_data_tlast;
  wire m_axis1_data_tvalid;
  wire m_axis1_data_tready;
  wire [127:0] m_axis1_data_tuser;

  wire [31:0]  s_axis0_data_tdata;
  wire s_axis0_data_tlast;
  wire s_axis0_data_tvalid;
  wire s_axis0_data_tready;
  wire [127:0] 

Re: [USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi,
It’s quite complex and long… posting the initial part with shell and wrappers

module noc_block_demod #(
  parameter NOC_ID = 64'h1408E12980FDE75E,
  parameter MAX_PACKET_SIZE = 64)
(
  input bus_clk, input bus_rst,
  input ce_clk, input ce_rst,
  input  [63:0] i_tdata, input  i_tlast, input  i_tvalid, output i_tready,
  output [63:0] o_tdata, output o_tlast, output o_tvalid, input  o_tready,
  output [63:0] debug
);

  
  //
  // RFNoC Shell
  //
  
  wire [31:0] set_data;
  wire [7:0]  set_addr;
  wireset_stb;
  reg rb_stb;
  reg  [63:0] rb_data;
  wire [7:0]  rb_addr;

  wire [63:0] cmdout_tdata, ackin_tdata;
  wirecmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast, 
ackin_tvalid, ackin_tready;

  wire [2*64-1:0] str_sink_tdata;
  wire [1:0]   str_sink_tlast, str_sink_tvalid, str_sink_tready;

  wire [63:0] str_src_tdata;
  wirestr_src_tlast, str_src_tvalid, str_src_tready;

  wire [15:0] src_sid;
  wire [15:0] next_dst_sid, resp_out_dst_sid;
  wire [15:0] resp_in_dst_sid;

  wireclear_tx_seqnum;

  noc_shell #(
.NOC_ID(NOC_ID),
.INPUT_PORTS(2)
)
  noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid), 
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid), 
.o_tready(o_tready),
// Computer Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
// Control Source
.cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast), 
.cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
.ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast), 
.ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast), 
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast), 
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
// Stream IDs set by host
.src_sid(src_sid),   // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
.resp_in_dst_sid(resp_in_dst_sid),   // Response destination SID for input 
stream responses / errors
.resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for output 
stream responses / errors
// Misc
.vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
.debug(debug));

  
  //
  // AXI Wrapper
  // Convert RFNoC Shell interface into AXI stream interface
  //
  
  wire [31:0]  m_axis0_data_tdata;
  wire m_axis0_data_tlast;
  wire m_axis0_data_tvalid;
  wire m_axis0_data_tready;
  wire [127:0] m_axis0_data_tuser;

  wire [31:0]  m_axis1_data_tdata;
  wire m_axis1_data_tlast;
  wire m_axis1_data_tvalid;
  wire m_axis1_data_tready;
  wire [127:0] m_axis1_data_tuser;

  wire [31:0]  s_axis0_data_tdata;
  wire s_axis0_data_tlast;
  wire s_axis0_data_tvalid;
  wire s_axis0_data_tready;
  wire [127:0] s_axis0_data_tuser;

  wire [31:0]  s_axis1_data_tdata;
  wire s_axis1_data_tlast;
  wire s_axis1_data_tvalid;
  wire s_axis1_data_tready;
  wire [127:0] s_axis1_data_tuser;
  wire [63:0]  vita_time_in;
  wire [63:0]  vita_time_out;
//  reg  [11:0]  seq_num;

  axi_wrapper #(
.SIMPLE_MODE(0))
  axi_wrapper0 (
.clk(ce_clk), .reset(ce_rst),
.clear_tx_seqnum(clear_tx_seqnum),
.next_dst(next_dst_sid),
.set_stb(set_stb), .set_addr(set_addr), .set_data(set_data),
.i_tdata(str_sink_tdata[63:0]), .i_tlast(str_sink_tlast[0]), 
.i_tvalid(str_sink_tvalid[0]), .i_tready(str_sink_tready[0]),
.o_tdata(str_src_tdata), .o_tlast(str_src_tlast), 
.o_tvalid(str_src_tvalid), .o_tready(str_src_tready),
.m_axis_data_tdata(m_axis0_data_tdata),
.m_axis_data_tlast(m_axis0_data_tlast),
.m_axis_data_tvalid(m_axis0_data_tvalid),
.m_axis_data_tready(m_axis0_data_tready),
.m_axis_data_tuser(m_axis0_data_tuser),
.s_axis_data_tdata(s_axis0_data_tdata),
.s_axis_data_tlast(s_axis0_data_tlast),
.s_axis_data_tvalid(s_axis0_data_tvalid),
.s_axis_data_tready(s_axis0_data_tready),
.s_axis_data_tuser(s_axis0_data_tuser),
.m_axis_config_tdata(),
.m_axis_config_tlast(),
.m_axis_config_tvalid(),
.m_axis_config_tready(),
.m_axis_pkt_len_tdata(),
.m_axis_pkt_len_tvalid(),
.m_axis_pkt_len_tready());

  axi_wrapper #(
.SIMPLE_MODE(0))
  axi_wrapper1 (
.clk(ce_clk), .reset(ce_rst),
.clear_tx_seqnum(clear_tx_seqnum),

[USRP-users] rfnoc block with two inputs

[Dario Pennisi via USRP-users]

Hi,
We are developing a block which needs two inputs from the two radios. The block 
works with one input but when adding the second one only the first input is fed 
with data.
Block has noc_shell instantiated with INPUT_PORTS(2) and its str_data output 
bus is connected to two axi_wrappers. Adding ILA shows that ready is always 
high on both sides but only the first side ever gets valid data.

In the gnuradio xml initialization is done like this:

 iptronix.block(
self.device3,
  uhd.stream_args( # TX Stream Args
cpu_format="sc16",
otw_format="sc16",
channels=(0,1),
args="",
  ),
  uhd.stream_args( # RX Stream Args
cpu_format="sc16",
otw_format="sc16",
args=""
  ),
  $block_index,
  $device_index
)

...
  
in
fc32
$grvlen
rfnoc
2
  

Whereas in the rfnoc block definition we added the following:

  

 in_0
 sc16
   

 ini_1
 sc16


 out0
 sc16

  

Is there anything we're not doing correctly? I could not find any example other 
than addsub that shows how to set up a rfnoc block with two inputs and one 
output...
Thanks,

Dario Pennisi

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

[USRP-users] proposed patch for rfnoc_block_impl.cc

[Dario Pennisi via USRP-users]

Hi,
After some testing it turned out that when creating a rfnoc block that sends 
timestamps for packets, the output stream is not tagged.
The patch below solves the issue and also removes the annoying timeout message 
that comes out whenever a block is not sending data so often.
Hope this helps and hope to see it in git soon.
Thanks,
Dario

diff --git a/lib/rfnoc_block_impl.cc b/lib/rfnoc_block_impl.cc
index 0b57957..b9cb691 100644
--- a/lib/rfnoc_block_impl.cc
+++ b/lib/rfnoc_block_impl.cc
@@ -562,7 +562,7 @@ rfnoc_block_impl::work_rx_a(

 case ::uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
   //its ok to timeout, perhaps the user is doing finite streaming
-  std::cout << "timeout on chan 0" << std::endl;
+  //std::cout << "timeout on chan 0" << std::endl;
   break;

 case ::uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
@@ -584,7 +584,14 @@ rfnoc_block_impl::work_rx_a(
 );
   }
   }
-
+  if (_rx.metadata.has_time_spec) {
+const pmt::pmt_t val = pmt::make_tuple
+  (pmt::from_uint64(_rx.metadata.time_spec.get_full_secs()),
+   pmt::from_double(_rx.metadata.time_spec.get_frac_secs()));
+for (size_t i = 0; i < output_items.size(); i++) {
+  add_item_tag(i, nitems_written(i)+ (num_samps / _rx.vlen) - 1, 
pmt::string_to_symbol("rx_time") , val);
+}
+  }
   // There's no 'produce_each()', unfortunately
   return num_samps / _rx.vlen;
}
@@ -615,7 +622,7 @@ rfnoc_block_impl::work_rx_u(

   case ::uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
 //its ok to timeout, perhaps the user is doing finite streaming
-std::cout << "timeout on chan " << i << std::endl;
+//std::cout << "timeout on chan " << i << std::endl;
 break;

   case ::uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
@@ -637,7 +644,14 @@ rfnoc_block_impl::work_rx_u(
 );
   }
 }
-
+if (_rx.metadata.has_time_spec) {
+  const pmt::pmt_t val = pmt::make_tuple
+(pmt::from_uint64(_rx.metadata.time_spec.get_full_secs()),
+ pmt::from_double(_rx.metadata.time_spec.get_frac_secs()));
+  for (size_t i = 0; i < output_items.size(); i++) {
+add_item_tag(i, nitems_written(i)+ (num_samps / _rx.vlen) - 1, 
pmt::string_to_symbol("rx_time") , val);
+  }
+}
 produce(i, num_samps / _rx.vlen);
   } /* end for (chans) */
}
@@ -690,4 +704,3 @@ void rfnoc_block_impl::handle_rfnoc_msg(pmt::pmt_t msg)
 }
   }
}
-

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

[USRP-users] rfnoc burst stream tagging

[Dario Pennisi via USRP-users]

Hi,

i've been developing a packet decoder block in rfnoc and so far it seems to 
work in the sense that i can successfully decode packets and receive them in 
gnuradio. in my implementation output data from the block would be in short 
bursts and i would like to be able on the host to identify each packet 
separately and have a timestamp for it.

in my block i have used axi_wrapper in SIMPLE_MODE=0 and made sure tuser packet 
contains has_time=1 and valid vita_time for each packet. also since i don't 
know packet size in advance i am leaving axi_wrapper figure it out by itself so 
am setting payload_length to 0 in cvita_hdr_encoder that feeds tuser to 
axi_wrapper.

if i set eob to 0 i am able to receieve only one rx_time tag from the block 
whereas if i set eob=1 for each packet i don't receive any rx_time tag at all...

is there anything i am missing or is this standard behaviour as blocks like 
usrp_source emit timestamps only on overruns? is there any way i can have 
timestamps for each packet?


in order to receive data i created a sink block derived from gr::sync_block, 
whereas i read that

gr::tagged_stream_block seems more suitable for my purposes... is there 
anything special/different that forces me to use such class rather than 
sync_block?


finally, is there anything special i should do in the rfnoc block rtl or host 
code to produce tags for each packet?


thanks,


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

Re: [USRP-users] systemverilog files in rfnoc block

[Dario Pennisi via USRP-users]

i think i found the issue...

tcl script file usrp3/tools/scripts/viv_utils.tcl actually contains 
instructions to add files to project based on their extensions and .sv is not 
listed so files are skipped.

adding a case for .sv works but it also includes axi_crossbar_intf.sv which 
seems to be a simulation file and won't compile so i had to exclude that file...

is there any reason why sv files are not included or is that just a lazy way to 
exclude simulation sources?

unfortunately i need to use some systemverilog constructs and with .v extension 
those seem not to be accepted...

thanks,


Dario Pennisi

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

[USRP-users] systemverilog files in rfnoc block

[Dario Pennisi via USRP-users]

hi,

i am trying to include a couple of systemverilog files in the list of sources 
for a custom rfnoc block.

if i do that i can see in the log that all files with .sv extension are ignored 
and of course their modules are not found. if i launch compilation in gui mode 
and then add files back it works...

is there any way of avoiding this manual step?

thanks,


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

Re: [USRP-users] RFNoC user registers and related APIs

[Dario Pennisi via USRP-users]

Hi Tom,
Microseconds would be fine as I just need to align to frequency hopping that 
has a scale of milliseconds. For the transmit side I should have no issue given 
that the transmit block is going to be a custom rfnoc one and I can set it up 
to start on a given vita time with a timed register set.

My concern is that my receiving rfnoc block is sending out very small bits of 
data as it is just outputting packet payload, so a block connected to its 
output would likely receive data only on boundaries of gr scheduling since I'm 
sure I'll never fill a buffer completely.
This is the reason why I was asking about the possibility to capture data 
within the rfnoc block driver itself and remove the gr scheduling lag.

My approach would be to hide work function in the block implementation so that 
instead of pushing data out it would just crunch it internally and react.
I was trying that when I realized that rfnoc block driver can't assume data 
gets to host as it may (and likely is) be connected to a FIFO before really 
getting on the host, so the block driver is handling only data transfer between 
blocks but not really receiving data, correct?

Thanks

Dario


Da: Tom Bereknyei
Inviato: mercoledì 23 agosto, 01:47
Oggetto: Re: [USRP-users] RFNoC user registers and related APIs
A: Dario Pennisi, Jonathon Pendlum
Cc: usrp-users@lists.ettus.com


Dario,

I've been working on a similar requirement. how strict are your timing needs? 
For prototyping we were able to get microsecond timing with just a scheduler 
implemented in python on an E310. The other major limitation right now is that 
RFnoc does not implement the UHD tagging of samples on the receiving side or to 
schedule the transmission on the transmit side. I would love to see that 
functionality implemented in someway but tags are only a GNUradio concept not 
in RFNOC.

A good start is to utilize the timing information in the headers, but ideally 
you would just edit the existing radio blocks to make them more useful in 
general.
On Tue, Aug 22, 2017 at 15:57 Dario Pennisi via USRP-users 
<usrp<mailto:usrp-users@lists.ettus.com>-us...@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
 wrote:
Hi Jonathon,
Thank you for your feedback. There's one more thing I am missing. I need to 
implement closed loop frequency hopping in the sense that my rfnoc block 
demodulates a signal, provides demodulated data to host along with timestamp 
and host needs to send a timed command to another block that will emit its 
answer packet. It is my understanding that it is possible to set registers at a 
given timestamp so this should do it.
What I am wondering is if there is a clean way to receive data from FPGA with 
minimal latency so that timed registers programming can be set within a short 
time. At the moment I am implementing a great block that gets data from a port 
and sends commands to a message port connected to the rfnoc block which then 
sends timed commands.
Initially was thinking it would make sense to intercept data directly from the 
rfnoc block c code but could not figure out a way to do that.
Can you please provide some insight and eventually pointers on how to do this?

Thanks,

Dario



On Tue, Aug 22, 2017 at 7:26 PM +0200, "Jonathon Pendlum" 
<jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote:

Hi Dario,

Yes, the deep dive is a bit outdated, but most of the core concepts are still 
valid. Originally, next_dst was derived from a register in the user register 
address space (usually register 128). However, that was wasteful of user 
registers, so that signal was pulled into Noc Shell and set as part of the Noc 
Shell register address space. I would suggest not using the configuration buses 
on AXI Wrapper, but instead to use axi_setting_reg if you want a register with 
an AXI stream interface.

The settings bus / readback bus concept has existed in USRPs before RFNoC. We 
avoided redesigning those buses so we could easily include pre-RFNoC code (such 
as the radio core) into RFNoC. We do have a redesign of that bus on our RFNoC 
roadmap to make it more consistent.

Jonathon

On Tue, Aug 22, 2017 at 3:56 AM, Dario Pennisi via USRP-users 
<usrp<mailto:usrp-users@lists.ettus.com>-us...@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
 wrote:
Hi,
I have some doubts on the interfaces available on noc shell and axi wrapper.
Based on the deep dive slides noc shell provides 3 bidirectional busses:
Command & response
Looking at the noc_shell code this should be indicated as control source. This 
bus seems to be able to send commands to other blocks. Is the command sink 
really usable to have a block send commands to other blocks?
Data packets
This should just contain sample data in and out of the block
Settings bus
This should be what noc shell code calls control sink and is basically an axi 
bus that is used to read and write registers.

In axi_wrapper the settings 

Re: [USRP-users] RFNoC user registers and related APIs

[Dario Pennisi via USRP-users]

Hi Jonathon,
Thank you for your feedback. There's one more thing I am missing. I need to 
implement closed loop frequency hopping in the sense that my rfnoc block 
demodulates a signal, provides demodulated data to host along with timestamp 
and host needs to send a timed command to another block that will emit its 
answer packet. It is my understanding that it is possible to set registers at a 
given timestamp so this should do it.
What I am wondering is if there is a clean way to receive data from FPGA with 
minimal latency so that timed registers programming can be set within a short 
time. At the moment I am implementing a great block that gets data from a port 
and sends commands to a message port connected to the rfnoc block which then 
sends timed commands.
Initially was thinking it would make sense to intercept data directly from the 
rfnoc block c code but could not figure out a way to do that.
Can you please provide some insight and eventually pointers on how to do this?

Thanks,

Dario



On Tue, Aug 22, 2017 at 7:26 PM +0200, "Jonathon Pendlum" 
<jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote:

Hi Dario,

Yes, the deep dive is a bit outdated, but most of the core concepts are still 
valid. Originally, next_dst was derived from a register in the user register 
address space (usually register 128). However, that was wasteful of user 
registers, so that signal was pulled into Noc Shell and set as part of the Noc 
Shell register address space. I would suggest not using the configuration buses 
on AXI Wrapper, but instead to use axi_setting_reg if you want a register with 
an AXI stream interface.

The settings bus / readback bus concept has existed in USRPs before RFNoC. We 
avoided redesigning those buses so we could easily include pre-RFNoC code (such 
as the radio core) into RFNoC. We do have a redesign of that bus on our RFNoC 
roadmap to make it more consistent.

Jonathon

On Tue, Aug 22, 2017 at 3:56 AM, Dario Pennisi via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi,
I have some doubts on the interfaces available on noc shell and axi wrapper.
Based on the deep dive slides noc shell provides 3 bidirectional busses:

  *   Command & response
Looking at the noc_shell code this should be indicated as control source. This 
bus seems to be able to send commands to other blocks. Is the command sink 
really usable to have a block send commands to other blocks?

  *   Data packets
This should just contain sample data in and out of the block

  *   Settings bus
This should be what noc shell code calls control sink and is basically an axi 
bus that is used to read and write registers.

In axi_wrapper the settings bus is decoded to allow sending axi streaming 
packets to each configured busses through registers 129 and 130. This basically 
allows sending packets of configuration data to each configured bus over the 
AXI configuration busses. It is used in window block to send window data

Axi wrapper also allows looping timestamp data or vice substituting it with 
user generated data.

One thing I don’t understand is for example that in the rfnoc getting started 
web page the gain sample uses register 128 which according to the deep dive ppt 
is supposed to be reserved for axi wrapper next destination, whereas the 
noc_shell_regs.v seems to indicate SR_NEXT_DST_SID is 6… it seems to me deep 
dive ppt is outdated and settings registers from 128 on can be feely used as 
long as they aren’t used for configuration busses… correct?

Another thing I think I understood is that the settings register space can be 
used for both reads and writes and provides a 32 bit data bus and has only 128 
addresses left for user application of which 2*channels are used for 
configuration busses. This address space is separate from the user readback 
which provide another 256 x 64 bit possible readback registers which are 
completely separate from the settings register space.. while it makes sense 
it’s not totally clear why an additional dedicated addressing space was needed 
for reading 64 bit back data and why for example there is no equivalent for 
writing.

Thanks,

Dario


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


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

[USRP-users] RFNoC user registers and related APIs

[Dario Pennisi via USRP-users]

Hi,
I have some doubts on the interfaces available on noc shell and axi wrapper.
Based on the deep dive slides noc shell provides 3 bidirectional busses:

  *   Command & response
Looking at the noc_shell code this should be indicated as control source. This 
bus seems to be able to send commands to other blocks. Is the command sink 
really usable to have a block send commands to other blocks?

  *   Data packets
This should just contain sample data in and out of the block

  *   Settings bus
This should be what noc shell code calls control sink and is basically an axi 
bus that is used to read and write registers.

In axi_wrapper the settings bus is decoded to allow sending axi streaming 
packets to each configured busses through registers 129 and 130. This basically 
allows sending packets of configuration data to each configured bus over the 
AXI configuration busses. It is used in window block to send window data

Axi wrapper also allows looping timestamp data or vice substituting it with 
user generated data.

One thing I don't understand is for example that in the rfnoc getting started 
web page the gain sample uses register 128 which according to the deep dive ppt 
is supposed to be reserved for axi wrapper next destination, whereas the 
noc_shell_regs.v seems to indicate SR_NEXT_DST_SID is 6... it seems to me deep 
dive ppt is outdated and settings registers from 128 on can be feely used as 
long as they aren't used for configuration busses... correct?

Another thing I think I understood is that the settings register space can be 
used for both reads and writes and provides a 32 bit data bus and has only 128 
addresses left for user application of which 2*channels are used for 
configuration busses. This address space is separate from the user readback 
which provide another 256 x 64 bit possible readback registers which are 
completely separate from the settings register space.. while it makes sense 
it's not totally clear why an additional dedicated addressing space was needed 
for reading 64 bit back data and why for example there is no equivalent for 
writing.

Thanks,

Dario

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

Re: [USRP-users] Fw: a few questions on rfnoc

[Dario Pennisi via USRP-users]

Hi Nicolas,
Thank you very much for your quick response.
Regarding variable packet sizes the output of my block is going straight to the 
host side and I am not planning these to connect to other blocks. In this case 
do you see any issue? Will uhd and gnuradio cope with that or will I have 
issues?

Regarding timing I was referring to a relationship between input and output 
packets. I understand these can be unrelated and basically I just have to 
generate the right chdr on the output side but just wanted to cross check.

Regarding message ports the point is that my block is a sort of protocol 
decoder so the idea is to input samples and output metadata when a packet is 
received. In rfnoc_fosphor_c_impl::handle_cfg_message message port is an input 
whereas I was considering treating output data as an output message port as it 
is a more logical representation of what I am outputting. In any case if data 
can be output in discontinuous, variable length bursts then I don’t see any 
problem in using stream…

Finally, regarding tutorial… the link you sent me is exactly what I studied so 
far but it contains little information on how to code C implementations to 
support RFNoC blocks. As you may have guessed I have to perform some 
significant post processing on data and for me xml block descriptors are not 
enough. For this reason I was looking for the rfnoc-tutorial/lib/gain_impl.cc 
file referred in your link which I can’t find anywhere.

Thanks,

Dario Pennisi

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

[USRP-users] Fw: a few questions on rfnoc

[Dario Pennisi via USRP-users]

Hi,
We are creating a RFNoC block that inputs a continuous flow of data and needs 
to output an irregular burst of variable length.
I tried to research a bit but didn't found a final answer on the following 
questions:

  1.  Packets to and from RFNoC blocks need to have a min/max/fixed length? 
Apparently not and if I didn't misunderstand it is also possible to send 
packets without the length so that their length could be variable but just want 
to be sure.
  2.  Is there any timing related requirement on when packets are sent/received?
  3.  My output port would basically resemble a message port... I seem to 
understand that there is some work in progress to support message outputs from 
RFNoC blocks but didn't really understand if this is really feasible or not. If 
it is where can I find some examples?
  4.  On the host side I need to add some custom C code so was looking for the 
tutorial here 
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials) but this 
link does not seem to work anymore and on git there seem to be no trace of it. 
is there any sample skeleton with the block implementation to just manage data 
from a stream and read/write registers?
Thanks you,

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