RFNoC4.0 endpoint buffer size

[hakegit]

I have some issues when using RFNoC4.0. When I was using RFNoC3.0, I needed to input a series of modules make by myself when building an image using IMAGE_BUILDER.py. When I am using RFNoC4.0, I need to input the modules in the image_core.yml. The problem is that my own modules need a large amount of BRAM in FPGA. When I am using RFNoC3.0, if I use more than four my own modules, building failure will arise, which is clearly due to insufficient BRAM. But when I use RFNoC4.0, I need to determind the buffer size of ENDPOINT (ep) in image_core.yml for each module when creating an image .And the connection need to be written by myself ,too. So I don't know how the BRAM used by my module corresponds to the cache size specified by me for ep. That is, how do I set the cache size for ep so that when my own module is added between ddc and radio, and between radio and duc. Currently, I am constantly trying to set the cache size of different EPs to different sizes, which may lead to issues with OOOOO or UUUUUU. I hope developers can provide me with a detailed explanation of how to set the cache size when my own module requires a large BRAM (approximately 8000 complex floating numbers). The specific names of my two own modules are sig1 and sig2. Each module requires a cache area of 8192 complex floating-point numbers.
My module connection methods are radio-sig2-ddc-ep and ep-duc-sig2-radio, with two identical links for sending and receiving. I would greatly appreciate it if I could receive guidance.

[2444616578]

I suggest you that you can write you connection radio-sig2-ddc-ep and ep-duc-sig2-radio directly in the icore.yml file. Then the buffer size of endpoints can be very large, like 65536, 655362,655364. You can try this. Is you directly connect the transmitting and receiving link ,you only need two eps, or four as the default yml file. I think another reason that cause the problem is that the clock of you block may be wrong. Check ce_clk, rfnoc_chdr. They are 184.36 and 200MHz respectively.

[hakegit]

6

[mbr0wn]

I'm going to refer to my answer to this issue over at EttusResearch/uhd#718