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
