Re: [USRP-users] Debugging RFNoC siggen
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 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
Re: [USRP-users] Debugging RFNoC siggen
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" Date: 8/10/18 10:03 am To: "Jon Pendlum" Cc: "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 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 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
Re: [USRP-users] Debugging RFNoC siggen
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
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> 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] Debugging RFNoC siggen
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
