OK. The AXI-Stream Data (simple) interface is the easiest for this case in my opinion. Are you using "Sideband-At-End" in order to have the "tlength" automatically calculated?
You need to set "tlast" like you mentioned. This is critical and not always easy. Remember that the CHDR packet can only be about 2000 samples whereas an OFDM packet might be longer. So, your idea about preserving the tlast from the input stream is probably needed. You also probably want to preserve teob from the input unless you are also detecting your own end of burst in which case you need logic to set this on the final packet and you need to set tlast on the last sample because the input packets will likely not have tlast set on this sample. Note that in the past I have used "axi_rate_change" in a block such as yours (my block was a pulse detection block based on power) because in addition to handling a true rate change (which you don't need), it also takes care of re-packetizing the data. This allows your own logic to not worry about RFNoC packets. But, switching to use this module might be more of a headache than just handling the RFNoC packets with your own logic. For the question you asked about receiving a new CHDR packet if an output packet has not been produced, I think the answer is Yes, this is no problem. Rob On Thu, Apr 17, 2025 at 12:16 PM Quentin Prieels < quentin.prie...@student.uclouvain.be> wrote: > Hi Rob, > > I'm not sure. I also tried forwarding the tlast signal of the original > tdata samples to force the system to send a CHDR packet—even if my OFDM > packet wasn't finished yet—but it doesn’t seem to solve the issue. > > Another question I’ve been asking myself is:* does RFNoC allow a block to > receive a new incoming CHDR packet if it hasn’t yet produced an outgoing > packet*? > > I'm using the AXI-Stream Data (Simple) interface, so I assume the NoC > shell handles packet manipulation and length. I don't see where I could > modify this behavior... > > If you have any ideas or insights, I’d be happy to investigate further. > > Best regards, > Quentin > > On 4/17/25 17:58, Rob Kossler wrote: > > > Vous n’obtenez pas souvent d’e-mail à partir de rkoss...@nd.edu. Pourquoi > c’est important <https://aka.ms/LearnAboutSenderIdentification> > > Hi Quentin, > Perhaps your issue is related to the 'length' parameter of the RFNoC > packet? If you are not correcting the packet length based on the number of > samples you are dropping, then you will get ill-formed packets coming out. > Do you think that this could be the issue? > Rob > > On Thu, Apr 17, 2025 at 11:40 AM Quentin Prieels < > quentin.prie...@student.uclouvain.be> wrote: > >> Hello everyone, >> >> I'm currently implementing a Schmidl & Cox OOT module on a USRP X310 as >> part of my master's thesis. (For those interested, the code is available >> here >> <https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/tree/latency> ( >> https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency).) >> >> The purpose of this block is to detect the beginning of an OFDM frame — >> specifically, just after the Schmidl & Cox preamble. I want the block to >> forward *only* the "valid" samples (i.e., those that are part of the >> actual OFDM frame). So when I call rx_stream->recv(), only actual data >> packets should be received by my UHD application. >> My first idea was to control the tvalid signal of the AXI-Stream >> interface: setting it to 0 when the data was not a "valid" OFDM sample, >> and asserting it (1) only when the data was valid. However, this seems >> to cause some kind of deadlock. My UHD application always times out and >> receives no data. Interestingly, when I output zero-valued samples instead >> of deasserting the tvalid signal, I can see that my synchronization >> mechanism is working as expected. This suggests the issue likely lies in my >> use of AXI signals or a misunderstanding of the RFNoC protocol. >> >> *Note*: my configured SPP (samples per packet, here 200) is smaller than >> the length of the actual OFDM frame, which consists of thousands of complex >> samples. >> >> So here's my main question: >> Given a continuous stream of data (currently configured as packets with >> 200 samples each, where every packet is valid), how can I output *only a >> subset* of this stream — a specific sequence of continuous samples >> (potentially spread across multiple packets) — such that only this valid >> subset is received by the UHD application? Alternatively, how can I mark >> only part of the stream as valid for the receiver, while discarding the >> rest? >> >> (For those interested in the code, this behavior corresponds to when >> output_select is set to 2'b01 in the following module: detector.sv >> <https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/fpga/ofdm/rfnoc_block_schmidl_cox/detector.sv> >> ( >> https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/fpga/ofdm/rfnoc_block_schmidl_cox/detector.sv) >> , which controls forwarding of input data only when in the FORWARDING >> state.) >> >> Thank you all for your help, >> Quentin >> >> >> >> _______________________________________________ >> 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
