Hi Jernej, I took a look at the code you shared. One thing I noticed is that you pass the data through your block, but not the sideband info. I'm assuming your block has some delay to it, which means the sideband information will not be correctly aligned in time with the outgoing packets. It's not obvious to me why this would cause the behavior you're seeing, so maybe that's not the issue. Nevertheless, I recommend fixing that. Since you're using SIDE_BAND_AT_END, you need to make sure that information is correct when TLAST is asserted.
If that's not the issue, then I assume the issue is in your PidFloatCoreStandard module, since I think you said that it works OK when you bypass it. You might take a look at the simulation and make sure you exercise the flow control (TREADY, TVALID). You could also consider putting an ILA on that interface and see what's going on there. You want to make sure the packets going into the NOC shell look correct (and also out of the RFNoC block, although the packets will be a little harder to understand). Thanks, Wade On Mon, Jul 10, 2023 at 1:28 AM Jernej Kokalj <[email protected]> wrote: > Hi Wade, > > thank you for support on this. Let me explain a bit the custom block for > you to better understand how we generate the AXI-Stream packets. > > The rfnoc_block_feedback_controller ( > https://git.gsi.de/p.niedermayer/exciter/-/blob/feedback_rfnoc/rfnoc-beam_exciter/fpga/rfnoc_block_feedback_controller/rfnoc_block_feedback_controller.v > ): > > - receives 200 (defualt value, can be configured) input datas (we do > not currently know how many data samples are in a packet) > - the module performs signal processing and generates ONE data packet > stream with "tLast" asserted on the last "tValid" data - so 200 output > datas with "tLast" on the 200th data output > - ttimestamp, thas_time, tlength, teov, teob are wired directly from > m_in to s_out inside the rfnoc_block_feedback_controller.v file > > There is also simulation of the block using the RFNoC template and the > block functional models - there the packets seem to be generated normally > that way and we see no issue. ( > https://git.gsi.de/p.niedermayer/exciter/-/blob/feedback_rfnoc/rfnoc-beam_exciter/fpga/rfnoc_block_feedback_controller/rfnoc_block_feedback_controller_tb.sv > ) > > We have read the specification stating that when SIDEBAND_AT_END is True > as in our case, then the package size is defined by "tlast" and "tlenght" > is ignored (we can generate tLast after 200 valid datas irrespective on how > many packets were on the input). > > Would it be possible for you to run the simulation and check where the > problem with AXI-Stream packets is? Or If you already see the problem, > support us on understanding the AXI-Stream packet generation. > > Best regards, > Jernej Kokalj > > The blocks' location ( > https://git.gsi.de/p.niedermayer/exciter/-/tree/feedback_rfnoc/rfnoc-beam_exciter/fpga > ): > > - sources and simulation are inside the > folder rfnoc_block_feedback_controller > - the rfnoc_block_feedback_controller uses also Xilinx IPs (generated > with Vivado 2021.1), which are located in the ip/ folder > > > > ------------------------------ > *From:* Wade Fife <[email protected]> > *Sent:* Wednesday, July 5, 2023 16:21 > *To:* Philipp Niedermayer <[email protected]> > *Cc:* [email protected] <[email protected]>; Jernej > Kokalj <[email protected]>; Blaž Kelbl <[email protected]> > *Subject:* Re: [USRP-users] Custom RFNoC block: data throughput bottleneck > > You don't often get email from [email protected]. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > Caution: This email originated from outside of Cosylab. > > I suspect your logic isn't processing packets correctly. For example, > maybe the sequence number is wrong on the output packets, or some other > header information is incorrect. Or maybe your AXI-Stream handshake logic > is wrong, causing you to miss samples. Or maybe TLAST isn't being asserted > on the correct sample. Something like that. It's hard to say. But the `D` > could mean simply that the packets going back to your host computer are > incorrectly constructed. > > Wade > > > > On Wed, Jul 5, 2023 at 12:16 AM Philipp Niedermayer <[email protected]> > wrote: > > Dear all, > > we are working on a custom OOT RFNoC Block implementation [1] on a USRP > X310 and are facing data throughput bottlenecks. > > The DSP is controlled via GNU Radio / UHD like this: > Signal Source -> RFNoC TX Streamer -> custom OOT block -> RFNoC RX > Streamer -> QT GUI Time Sink > > When running the flow graph we get a lot of "DDDD" printed to the console, > i.e. package drop due to buffer overflow. Adding a GNU Radio "Probe rate" > block shows that the sampling rate before the TX Streamer is 200kSps as > desired. However, behind the RX Streamer, the sampling rate is only 64 Sps > (!). > > When bypassing our custom VHDL implementation in the OOT Block (i.e. > assigning all s_out_axis_t* to respective m_in_axis_t*) the flow graph > works as expected, so the RFNoC part alone works just fine. > > The VHDL implementation requires some 100 clock cycles for a sample to > propagate. But since we use the 200MHz clock, achieving sampling rates of > 200kSps should not be an issue. The custom OOT block also has an option for > interpolation (i.e. increasing sampling rate), but the behaviour is the > same even for interpolation=1. > > Do you have some hints on how to improve performance? We have already > tried to > - Increase the payload FIFO depth from 32 to 128 > - Try both, the context-payload and the data AXI-Stream interface > - Assert tlast on every sample to reduce packages size > > Some things we have considered but are not sure about: > - MTU size > - Package size > > Thanks for taking the time to share your ideas > Philipp, Jernej, Blaž > > > [1] > https://git.gsi.de/p.niedermayer/exciter/-/blob/f02ee94ad3358fff313fc14a1a8d8494ad68d8ab/rfnoc-beam_exciter/fpga/rfnoc_block_feedback_controller/rfnoc_block_feedback_controller.v#L419 > > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
