Re: [USRP-users] RFNOC blocks with multiple inputs?

2018-08-27 Thread Jason Matusiak via USRP-users
I may be wrong, but I am pretty sure that RFNoC has issues with more inputs 
than outputs on a block.  I believe the workout is to put a dummy output on the 
other side and hide it in GRC.  Hopefully someone will speak up if I am wrong.
 
 
- Original Message - Subject: [USRP-users] RFNOC blocks with 
multiple inputs?
From: "Andrew Danowitz via USRP-users" 
Date: 8/25/18 3:37 pm
To: "shachar J. brown via USRP-users" 

  Hi all,
 
I'm trying to create an rfnoc divide block. I have the RTL and testbench set up 
and working, but every time I try to put it in a grc flow, I get:
 
RuntimeError: Invalid stream args.
 
I'm assuming this has to do with the grc xml file for my block. Is there any 
documentation on how to make an rfnoc block with multiple inputs or outputs? 
For the make args, should I use the same ettus.rfnoc_generic call that the 
built-in addsub block uses?


 
Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise indicated 
and is therefore subject to obligations in any executed confidentiality 
agreements. Further, this email is intended solely for the use of the 
individual or entity to whom they are addressed. If you are not the intended 
recipient and this message has been addressed to you in error, please promptly 
notify i...@whitefoxdefense.com and destroy all copies of the message and any 
attachments. This email and attachments may contain technical data as defined 
in the International Traffic In Arms Regulations (ITAR) 22 CFR 120.10 or the 
Export Administration Regulations (EAR) 15 CFR Parts 730 - 780.  Export of this 
material may be controlled by these regulations and may not be exported or 
transferred to non-U.S. persons without prior written approval from the U.S. 
government.
___ USRP-users mailing list 
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[USRP-users] RFNOC blocks with multiple inputs?

2018-08-25 Thread Andrew Danowitz via USRP-users
Hi all,

I'm trying to create an rfnoc divide block. I have the RTL and testbench
set up and working, but every time I try to put it in a grc flow, I get:

RuntimeError: Invalid stream args.

I'm assuming this has to do with the grc xml file for my block. Is there
any documentation on how to make an rfnoc block with multiple inputs or
outputs? For the make args, should I use the same ettus.rfnoc_generic call
that the built-in addsub block uses?

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

2017-10-16 Thread Michael West via USRP-users
Hi Dario,

Interesting.  I would expect 2 UBX-160 with 2 radio blocks into the 2 input
ports to work.  My best guess is that there is some issue with either the
detected upstream nodes or the propagation of the stream command.  It would
be interesting to debug the source_block_ctrl_base::issue_stream_cmd()
function and see what the "chan" parameter is and to which upstream blocks
the command is being issued.  Is that something you can do?

Regards,
Michael

On Fri, Oct 13, 2017 at 1:57 PM, Dario Pennisi  wrote:

> 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> 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 
>> 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> 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
 
 .

 Regards,
 Michael

 On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users <
 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 inpu

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

2017-10-13 Thread 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" 
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 
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" 
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.

Regards,
Michael

On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users 
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

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

2017-10-13 Thread Michael West via USRP-users
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  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> 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
>> 
>> .
>>
>> Regards,
>> Michael
>>
>> On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users <
>> 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
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists

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

2017-10-13 Thread 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" 
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.

Regards,
Michael

On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users 
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
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 blocks with multiple inputs/outputs

2017-10-13 Thread Michael West via USRP-users
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

.

Regards,
Michael

On Wed, Oct 4, 2017 at 11:57 PM, Dario Pennisi via USRP-users <
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
> 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 blocks with multiple inputs/outputs

2017-10-04 Thread 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