I experianced the same issues that EJ mentioned last year (maybe earlier). At the time Jon, helped me with a patch to get it to work properly (this was an OOT that sent out a specific chunk of samples on repeat [I think I mentioned this in a thread a few weeks ago]). I am not sure if it is fixed to handle this now since I haven't used the block since. Based on Jonathon's response in this thread, it sounds like this could be an issue (and now that I think about it, it could be the reason the current block I am working on is working fine in simulation but not on the FPGA). I'd love to hear of a way to make this work more automagically. --------- Original Message --------- Subject: Re: [USRP-users] Debugging RFNoC siggen From: "EJ Kreinar via USRP-users" <usrp-users@lists.ettus.com> Date: 8/10/18 10:03 am To: "Jon Pendlum" <jon.pend...@gmail.com> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>, koen.tim...@thalesaleniaspace.com
Hi Koen, There's also a potential deadlock situation to watch out for: If your block output samples to the axi_wrapper *before* UHD software assigns a destination address, I've seen the axi_wrapper FIFO become full and deadlock somewhere in the transmit path. This was an issue several 6-12 months ago with the noc_block_siggen, at least, and the siggen enable register needed to be enabled explicitly *after* UHD had called "connect". I'm not confident this is still an issue, or if it's been fixed in the intermediate time, but it's something to watch out for. Based on my rough understanding of your block, it sounds like the ready signal from the axi_wrapper might go high immediately after the block initializes, and your user block would then try to dump a lot of data into the axi_wrapper before things are configured. EJ On Fri, Aug 10, 2018 at 6:18 AM Jon Pendlum via USRP-users <usrp-users@lists.ettus.com> wrote: Hi Koen, Your block should not wait on tready, that is a violation of the AXI spec. Some blocks actually wait for tvalid to be asserted before asserting tready (that is permitted by the spec), which would cause a deadlock in your situation. You can work around that by putting an axi_flip_flop in the path since it will always assert tready when it can. However, I don't think that is your issue. You should be interfacing your logic with the AXI wrapper instance in your block. AXI wrapper's s_axis_data_tready signal essentially connects to a FIFO, so you should see it assert. Do you see that? Jonathon On Fri, Aug 10, 2018, 5:52 PM TIMMEN Koen via USRP-users <usrp-users@lists.ettus.com> wrote: Hello all, Last week I posted a question, on how I could confirm that a custom RFNoC signal generator (piloted from a UHD API) functioned as intended. I received the tip to probe my block using the Vivado ILA. A great idea, because I did not know this existed (I am quite new in FPGA design) and it is a useful tool. Now, I was able to confirm that my custom block is functioning as intended by placing an ILA internal to it. However, no actual samples are ever generated due to a design choice I made; sample generation is only triggered when the block receives a tready signal from a downstream block. In this case a DUC block. In other words, the block stays dormant, waiting to receive a trigger. That leaves me with the question why it never receives this signal. Could someone explain to me at what point a DUC block will assert its tready signal? I was under the impression that as soon as I connected the blocks (using uhd::rfnoc::graph::connect()) as follows: SIGGEN à DUC à Radio, the DUC and Radio blocks would be asserting their ready samples directly after. But apparently this is not the case. Thank you for your replies, Koen _______________________________________________ USRP-users mailing list 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 _______________________________________________ USRP-users mailing list 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
