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]> wrote: > > > On Wed, Mar 25, 2026 at 4:41 PM Barnard, Michael T < > [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 > > 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
