On 14/04/2023 10:08, Rob Kossler wrote:
Jim, Marcus,
I *believe* that "skip_dram=1" will have no effect on the N310 because
it does not use DRAM in the stock image (or even populate the
dram-fifo RFNoC block). The definition of the stock RFNoC graph for
the N310 is here
<https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/n3xx/n310_rfnoc_image_core.yml>.
I was surfing a lot of the N3xx docs yesterday, and was left with the
impression, reinforced by the "skip_dram" device
argument, that there was DRAM FIFO in the N3xx by default. But the
.yml you pointed at seems pretty definitive.
Most of the "buffering" for the N310 transmit path is in the buff_size
of the streaming end points attached to the DUC (32768 samples) along
with a small amount of buffering at the DUC (defined here
<https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/duc.yml>)
and at the Radio (perhaps here
<https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/radio.yml>)
. The easiest way to increase buffering is to increase the buff_size
of the end points ep0 through ep3. But, it is possible that doing so
will cause the build to fail. I don't know if Ettus max-ed these out
or not. But, if the build fails, another option is to get rid of the
Replay block (and associated end points) and the DDC (if you don't
need it) to free up resources. Then you might be able to increase the
end point buff_sizes.
But, if you want to use the DRAM as a FIFO (which will provide much
larger FIFOs), you should be able to just replace the 4 channel Replay
block with a 4 channel DRAM fifo (defined here
<https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/axi_ram_fifo.yml>),
making sure to get the RAM address width (and perhaps other
parameters) correct for the N310 (will be same as Replay block uses).
The DRAM is 2GB so each FIFO "channel" could be configured for
125MSamples.
And, back to one of my previous comments, if you have a lot of host
RAM such that it would be a possibility to stream from a RAM-disk
based file, I believe it would be worth a try.
Rob
One of the things that puzzles me is that 12.5Msps just isn't that high
a streaming rate, in fact it's totally supported over
a *1* GBit interface.
At 12.5Msps, that buffer fills(drains) in about 2.5ms. There's plenty
of buffering on the host to buffer application scheduling
issues, so I don't know where these underruns would be coming from.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
