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-users@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-users@lists.ettus.com<mailto: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
