Quentin, Before proceeding, make sure you *backup your verilog implementation* because changing to the axis-data interface will *delete the block verilog folder* you have been working in (testbench, block code, Makefile, etc).
The information below is based on the rfnoc spec ( https://files.ettus.com/app_notes/RFNoC_Specification.pdf) section 4.2.2 You will need to change the block description YAML file to have an axis-data interface, then run the create_verilog.py (uhd/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py) script. An example is shown below of the minimum change needed for an axis-data interface: [image: image.png] After running the create_verilog script the new block will have the signals Rob mentioned. These will be at the noc_shell module interface, with some new clock names: [image: image.png] Thanks, David On Thu, Apr 17, 2025 at 10:17 AM Quentin Prieels < quentin.prie...@student.uclouvain.be> wrote: > I just read a bit more about the "Sideband-At-End" signal, and it could > indeed be the issue. However, I don't see this signal (nor tlength, > ttimestamp, has_time, teov, or teob) in my current block definition. This > definition was auto-generated by *rfnoc_modtool*, similar to the one in > the gain example. Do you know how I can enable or configure this > Sideband-At-End in UHD 4.8? > > You're also right — I added a custom is_last_sample signal to mark the > last sample of my OFDM frame, in case it doesn’t align with a true end > symbol in RFNoC. > > If needed, here’s my current block definition: > > https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/rfnoc/blocks/schmidl_cox.yml > Quentin > On 4/17/25 18:40, Rob Kossler wrote: > > > Vous n’obtenez pas souvent d’e-mail à partir de rkoss...@nd.edu. Pourquoi > c’est important <https://aka.ms/LearnAboutSenderIdentification> > > 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 >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
