Hi Martin, For my own understanding,.... Although the endpoint buffers don't use DRAM as you pointed out, the replay block acting as a FIFO does, correct? So, if the first block on the FPGA side of the endpoint is the replay block, won't you achieve the goal of a large FIFO. In other words, in this scenario, isn't it basically guaranteed that the endpoint buffer will not fill up (prior to the replay DRAM filling up) since it will be able to dump into the replay DRAM (and assuming that you don't exceed the DRAM bandwidth)? Rob
On Thu, Feb 19, 2026 at 7:21 AM Martin Braun <[email protected]> wrote: > One important thing to point out is that we do *not* use DRAM for the > buffers, we use BRAM (of which much less is available). The requirement for > an endpoint buffer is that we can write to it synchronously. This is not > possible with DRAM, you must go through a memory interface, and then wait > for your write cycle, etc. The default Tx buffers are therefore already > close to the limit. If you want to increase it, you typically have to > change the design (e.g., take away the buffer from channel 1 and put it on > channel 0). But then you need to rebuild the image, which you're trying to > avoid. > > The 1 GiB of PL-DRAM memory included with the N320 is fantastic for > storing large amounts of memory, e.g., for capture/replay. The *average* > throughput of the DRAM is also fast enough to capture both channels at max > rate (it's just that average throughput is not the only requirement for an > endpoint buffer). So if you can do replay/capture, then you're good. You > can also try the replay_buffered stream arg, although it's not a silver > bullet. It helps in some scenarios but not others, YMMV. > > --M > > On Tue, Jan 27, 2026 at 8:01 PM Eugene Grayver <[email protected]> > wrote: > >> Thanks. I saw notes that seem to indicate that option. Anyone at >> Ettus/NI care to chime in as to how to do it? I found an example for E320 >> that shows an RFNoC .yml with a dram FIFO. I could make one for N320, but >> it is not clear how to use it from gnuradio. >> ------------------------------ >> *From:* Rob Kossler <[email protected]> >> *Sent:* Tuesday, January 27, 2026 6:45 AM >> *To:* Eugene Grayver <[email protected]> >> *Cc:* usrp-users <[email protected]> >> *Subject:* [EXTERNAL] Re: [USRP-users] TX DRAM buffer >> >> >> *Do not open links or attachments unless you recognize the sender. If >> unsure, click the Report Phish button or forward the email to OPSEC. * >> Hi Eugene, >> I "think" that the replay block can act as a FIFO in recent UHD images. >> But, there is a possibility I am wrong such that there is a build-time >> parameter that is needed to config this. Another option would be DPDK if >> you are not already using it. >> Rob >> >> On Mon, Jan 26, 2026 at 7:00 PM Eugene Grayver <[email protected]> >> wrote: >> >> Hi, >> >> The default TX buffer for N32x is 128k samples = 512 kB. The box has 1 >> GB of DRAM. I am getting occasional underflows when streaming at 200 Msps, >> even though the CPU is not very loaded and easily meets the average >> throughput. >> >> I have done all the usual stuff — isolated cores, pin threads to cores, >> etc. >> >> Is there a way to increase the default DRAM buffer size w/out rebuilding >> the FPGA image? >> >> Thanks. >> >> Eugene Grayver, Ph.D. >> Principal Engineer >> 310-336-1274 >> _______________________________________________ >> 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] >> > _______________________________________________ > 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]
