Thanks Wade! Perhaps this information could be incorporated into the RFNoC specification. Rob
On Thu, May 27, 2021 at 9:53 PM Wade Fife <wade.f...@ettus.com> wrote: > Rob, > > The "buff_size" parameter controls the "INGRESS_BUFF_SIZE" Verilog > parameter used in the stream endpoint. It has a significant effect on > streaming performance in the TX direction (host to USRP). A practical lower > limit is two MTU-sized packets, and the rfnoc_image_builder will coerce it > to at least that value. If the port is not actually used for steaming RF > data, you can set buff_size to 0 and it will use a very small FIFO > (32-deep). You generally want big buffers for the TX data paths that stream > RF data at high rates and the default images set these about as large as is > practical for the FPGA size. > > The "payload_fifo_depth" parameter sets the "PAYLOAD_FIFO_SIZE" Verilog > parameter used in the NoC Shell in both the TX and RX directions. I don't > think there's really a lower limit on this one and I agree that it makes > sense to make this 2 for most blocks. How big this one should be is block > dependent. For example, the Replay block can use this as a buffer that can > help to hide some of the latency of the DRAM. The Radio can benefit because > it serves as a buffer that can guard against underflow/overflow. But most > other blocks can set it to a really small value, like 2, which basically > means no FIFO. > > The context/info FIFO depths don't need to be very big, and they should > already be small by default. I believe they're usually set to 32-deep. > These FIFOs essentially buffer the header information for packets being > sent/received. You would only make these bigger if you needed to have > several packets in flight simultaneously in a single block (for example, if > you had big payload FIFOs and a small packet size such that multiple > packets were buffered in the FIFO at the same time). There's not really > much benefit to making them smaller than 32 since FIFOs that size are > implemented using SRL, which is very efficient. So I don't recommend > decreasing this value. > > Wade > > On Thu, May 27, 2021 at 9:55 AM Rob Kossler <rkoss...@nd.edu> wrote: > >> I am having some trouble building a custom RFNoC 4 FPGA design and so I >> am looking to reduce the footprint. One easy thing to try is to reduce >> various buffer sizes such as the ingress buffer size on the streaming >> endpoint or the incoming RFNoC block fifo depths. But, I am wondering if >> there are practical lower limits for how small these should be set to. Any >> comments on the questions below (or other insights or rules-of-thumb) would >> be greatly appreciated. Thanks. >> Rob >> >> - *Stream endpoint ingress buffer size*: "buff_size" parameter for >> endpoint in core yml >> - Is there a practical lower limit? For example, should it be at >> least MTU size? Does anything bad happen if I set it as low as 256? >> - Are large sizes needed only for SEPs that will accept steaming >> from host? For example if a DDC was connected to its own SEP would >> there be >> any need for a large buff_size on that SEP given that the incoming data >> would likely be coming from another FPGA block (i.e., the Radio)? >> - Are large sizes needed only for SEPs that require real-time flow >> (e.g. paths that terminate at a Radio)? For example, even though a >> Replay >> block accepts data from the host, it may not need real-time flow if >> you are >> just pre-storing samples that will later be played out in real-time. >> For >> this case, is there a practical lower limit for how small we should set >> buff_size? >> - Does the buffer size affect both directions? In other words, >> are 2 buffers created: one for the incoming packets from the crossbar >> AND >> one for the incoming packets from the static router? >> - *RFNoC block payload_fifo_depth*: >> - Is there a practical lower limit? >> - What is the disadvantage to setting this to one? My thinking is >> that I don't generally insert a buffer between two AXIS components >> within >> an RFNoC block so why do I want buffering between two AXIS components >> that >> span between two RFNoC blocks? >> - *RFNoC block <context|info>_fifo_depth*: >> - Should this be sized based on the expected packet length and the >> specified payload_fifo_depth? For example, if I expect incoming >> packets of >> 1000 samples and set my payload_fifo_depth to 2000 so that I can >> buffer 2 >> packets, should I then set the context or info fifo_depth to be 2? >> >> _______________________________________________ >> 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
