Hi Tom, Microseconds would be fine as I just need to align to frequency hopping that has a scale of milliseconds. For the transmit side I should have no issue given that the transmit block is going to be a custom rfnoc one and I can set it up to start on a given vita time with a timed register set.
My concern is that my receiving rfnoc block is sending out very small bits of data as it is just outputting packet payload, so a block connected to its output would likely receive data only on boundaries of gr scheduling since I'm sure I'll never fill a buffer completely. This is the reason why I was asking about the possibility to capture data within the rfnoc block driver itself and remove the gr scheduling lag. My approach would be to hide work function in the block implementation so that instead of pushing data out it would just crunch it internally and react. I was trying that when I realized that rfnoc block driver can't assume data gets to host as it may (and likely is) be connected to a FIFO before really getting on the host, so the block driver is handling only data transfer between blocks but not really receiving data, correct? Thanks Dario Da: Tom Bereknyei Inviato: mercoledì 23 agosto, 01:47 Oggetto: Re: [USRP-users] RFNoC user registers and related APIs A: Dario Pennisi, Jonathon Pendlum Cc: usrp-users@lists.ettus.com 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 <usrp<mailto:usrp-users@lists.ettus.com>-us...@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> 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" <jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> 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 <usrp<mailto:usrp-users@lists.ettus.com>-us...@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> 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 USRP<mailto:USRP-users@lists.ettus.com>-us...@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>listinfo<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>/<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>usrp<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>-users_lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> _______________________________________________ USRP-users mailing list USRP<mailto:USRP-users@lists.ettus.com>-us...@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>listinfo<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>/<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>usrp<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>-users_lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> -- Maj Tom Bereknyei Defense Digital Service t...@dds.mil<mailto:t...@dds.mil> (571) 225-1630?
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
