The NoC Shell is configurable for different use cases. You can read about the differences in the RFNoC Specification. https://files.ettus.com/app_notes/RFNoC_Specification.pdf
I suppose in your case, I would use the axis_data interface type (what the DDC block uses). What is the source of your trigger? How important is it that you sample at the time your trigger occurs? If the timing of the trigger is important, then you might need to look at the radio_time to figure out at what time the trigger occurred, then put logic in your block to capture two samples starting at that time. Otherwise, your trigger will be off due to the delay for the transfer of data from the radio to your block. But maybe the precision of the trigger isn't important and you can ignore that delay. In an RFNoC block, the data will come in on AXI-Stream (tdata, tlast, tavlid, tready). You need to follow the protocol of that bus to capture the data. The data won't be valid on every clock cycle because the data bus runs on a different clock rate from the ADC. It will only be valid when tvalid is high, and you must acknowledge the data by asserting tready. If this isn't clear, then I suggest you read up on how AXI-Stream works. Wade On Mon, Oct 24, 2022 at 12:35 AM Yasir Özçalık <simultaneou...@gmail.com> wrote: > Hi Wade, > thank you very much for your answer. I have successfully debugged it. Can > you also help me with my original problem? > I am using the E320 and UHD 4.0 version. I want to save 2 ADC samples into > block ram and read them later. For that reason, I have a trigger which > starts the saving process. When I saved 2 ADC samples into block ram and > read them later, I realized that some samples are zero. I debugged it and I > saw that valid signals of ADCs are not always 1. They sometimes switch back > to 0. While doing that, I have used the RFNoC-example as a starting point. > I don't know what the real problem is, but I examined different examples > and I realized that they used different files in their noc_shell files. For > example, the gain example used chdr_to_axis_pyld_ctxt which generates > payload and context data. But, ddc example used chdr_to_axis_data which > generates only axis datas. Therefore; I have tried different files in > noc_shell, but none of them worked as I expected. I don't want to take all > the examples to the host or anywhere else. I just want all ADC samples to > go into my custom RFNoC-block. I don't want any other datas such as > metadatas or anything else, but only ADC samples. > > My System: > Device : E320 > OS : Ubuntu 20.04.4 > UHD: 4.0 > > Kind Regards, > Yasir. > > Wade Fife <wade.f...@ettus.com>, 21 Eki 2022 Cum, 20:34 tarihinde şunu > yazdı: > >> Hi Yasir, >> >> The E320 runs Linux on the SoC of FPGA. There are devices in the FPGA >> which are visible to the Linux kernel, so updating the FPGA without first >> bringing down those devices causes problems. uhd_image_loader takes care of >> all this for you. You can use uhd_image_loader to first load your bitstream >> (the one you want to debug over JTAG), then use the Vivado hardware manager >> to connect to that bitstream via JTAG after it is already loaded. >> >> Wade >> >> On Thu, Oct 20, 2022 at 3:31 AM Yasir Özçalık <simultaneou...@gmail.com> >> wrote: >> >>> Hi everyone, >>> I am trying to debug E320 with JTAG. I connected to the E320 JTAG >>> console with Vivado 2019.1 hardware manager. Vivado successfully >>> recognized E320. Then, I loaded my custom bitfile. The problem is E320 >>> started to give me errors saying that "IO Error during GSM initialization." >>> I thought that might be because of the bit file. Therefore; I tried to load >>> the default bit file, but the same problem occurred again. When I use >>> uhd_image_loader, bitfiles work without problem. But when I wanted to debug >>> it with JTAG and loaded the bit file with jtag, uhd_usrp_probe gave me an >>> error message. Can anyone help me with this, please? What might be the >>> problem? >>> >>> Kind Regards, >>> Yasir. >>> _______________________________________________ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>> >>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
