Hi Dario, On Sun, Jul 22, 2018 at 1:57 PM Dario Pennisi <da...@iptronix.com> wrote:
> 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. > Noted, but nothing of concern for me here. I don't care about anything you've brought up here. I am not interested in being convinced the silliness of my idea, or the lack of bandwidth I can support. Not everything needs to run at 200Msps. Not everything needs to run in real time. Not everything needs to fit in the current RFNoC development environment. I am looking for a response regarding the feasibility of having software emulated RFNoC blocks, and guidance on where to look and how to implement it with the context that I want it to be out-of-tree. There are already hooks, somewhere, for sending CHDR packets for both data and control, as well as flow control, but from what I can figure out it isn't necessarily exposed externally? Would just deriving from device3 do mostly what I want, and the only extension is that there needs to be a hook for register writes/read? > > 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... > Sounds like it's a bug in UHD that should be fixed. Who knows how many other bugs are out there because the blocks tested are a very tiny subset of what blocks can be exercising. My intent is that something like this can create every possible combination of input and output ports and types. There are bugs within UHD and I want this to help find them and make RFNoC better. Brian >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
