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
