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" <bpadal...@gmail.com<mailto:bpadal...@gmail.com>> wrote: Hey Dario, On Sun, Jul 22, 2018 at 11:20 AM Dario Pennisi <da...@iptronix.com<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
