Thanks for the insight; I've got a better handle on things now. I'm still not sure where to get the timestamp value from. The processing doesn't touch the host PC at all everything is contained in the FPGA. Is the timestamp distributed to the cores or do I need to request the value from somewhere else in the FPGA?
Michael Barnard TL Computer Engineer, Scalable Computing Group Applied Sensing Division 300 College Park, Dayton, OH 45469-0031 O:(937) 713-4271 | C:(440) 622-6486 | udri.udayton.edu<http://udri.udayton.edu/> [1621527942842] UDRI Proprietary - Unprotected ________________________________ From: Martin Braun <[email protected]> Sent: Thursday, March 26, 2026 9:30 AM Cc: [email protected] <[email protected]> Subject: [USRP-users] Re: X310 Precise Transmit Control CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Some additional comments: - You can probably ignore EOV - If you do use EOV, note that it is treated differently than EOB in some places. For example, the recv() call (in software) will terminate immediately when it sees an EOB, but you can have multiple EOVs in a single burst (so from that recv() call, you can never have more than one EOB, but any number of EOVs). - If you come from a strict FPGA background, it's important to get behind the "network on chip" part of RFNoC. Your clocks don't really matter here. What matters is, when the radio gets a CHDR packet, it will read the timestamp and compare it against the corresponding timer. When a CHDR packet leaves one block, you shouldn't care (at design time) if the next block is right next to it, or 100 km away over an Ethernet line. I'm exaggerating, but I hope this helps understand this concept. --M On Wed, Mar 25, 2026 at 9:56 PM Brian Padalino <[email protected]<mailto:[email protected]>> wrote: On Wed, Mar 25, 2026 at 4:41 PM Barnard, Michael T <[email protected]<mailto:[email protected]>> wrote: I am a FPGA developer working in Verilog with an X310 writing code in a custom RFNoC block. I recently got independent streaming control working to output samples at my discretion to a streaming endpoint then through the cross bar but I do have some questions on parts of the control behavior. It’s not clear to me what the difference between End of Burst (EOB) and End of Vector (EOV) is or when I need to use one or the other. My current design only uses EOB on the last data packet while EOV is always set to 0. I’m getting underflow errors occasionally but I can’t confidently say which packets they’re associated with. I also need to send a second packet with EOB high to flush the first packet out of the buffer; my guess would be that the first EOB would force a buffer flush. Is there any EOV was added for when your data might be too large for a single CHDR packet. Think like a 16384 sample FFT frame - it can't fit inside a single CHDR packet, so EOV is used. I’m also wondering if there is a way to precisely schedule samples or packets for transmit out of the radio. I’ve observed that because the data is processed at ~215 MHz in the RFNoC block and fed into the DAC at 200 MHz pauses have to be included between each packet to prevent overfilling the transmit buffer but this also means that a timing in the 215 MHz domain may not be reflected in the 200 MHz domain. Is there a way to tell the transmit logic/front end to start transmitting at a particular time either in the CHDR header or using the timestamp? Or am I at the mercy of the front end components without any fine control of transmit timing? The CHDR with Timestamp is used there. When it's the first packet in a burst, that time is compared against the timestamp of the radio. If it's late, then the radio sets an error condition that is sent back to the host and the radio block will consume the packets as fast as possible until it sees the EOB. There are other modes of operation depending on how you set up your RFNoC graph as to what to do during these error conditions. Check the state machine here: https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/radio_tx_core.v#L299 [github.com]<https://urldefense.us/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_master_fpga_usrp3_lib_rfnoc_blocks_rfnoc-5Fblock-5Fradio_radio-5Ftx-5Fcore.v-23L299&d=DwMFaQ&c=pftDoUyzvDgNGToC1TC2fAYTjbKPSqv0CTWoNdikfI0&r=_YNw12ReY4H38tz6L9d14UI9KmDH4TWmWo4TzJSbxw9SuCqdtK-AT-259kfxeZsh&m=bVvtqauPQKkwOFyp6pIaqyonQasy1o456UpJAuwvY8AZOSrv24SufW7pJZTEFIdS&s=svYWjmrncxL4sI1kllS9riUDzvO1tNla7wsRZ66__Lc&e=> As for the processing clock versus radio clock, you should be adhering to the AXI streaming tready signal for back pressure. You can fill up that pipeline and things should be fine. Good luck. Brian _______________________________________________ USRP-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ________________________________ The information contained in this e-mail and any attachments from UDRI may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
