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 <da...@iptronix.com> 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 <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> 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> 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
