Jon, I am interfacing my logic with the AXI wrapper instance and the AXI wrapper’s s_axis_data_tready signal is exactly the signal that should trigger my block. In my initial e-mail I said I was waiting for the downstream block tready signal, while actually I was referring to the signal you ask for.
This is exactly my problem, I was under the impression that this signal would be asserted after initialization, since the AXI wrapper FIFO should be empty if no samples were transmitted yet. Apparently this is not the case or there is some other problem since I never see this signal being asserted. This is my workflow: - Program device in Vivado hardware manager - Set trigger for s_axis_data_tready == 1 - Run UHD API (this simply creates USRP device, grabs block controllers and calls graph::connect() Kind regards, Koen De : Jon Pendlum [mailto:jon.pend...@gmail.com] Envoyé : vendredi 10 août 2018 12:18 À : TIMMEN Koen Cc : USRP-users@lists.ettus.com Objet : Re: [USRP-users] Debugging RFNoC siggen 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<mailto: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<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
