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 < [email protected]> 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" < > [email protected]> 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 < >> [email protected]> 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 >>> [email protected] >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Maj Tom Bereknyei Defense Digital Service [email protected] (571) 225-1630
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
