On Sun, Aug 16, 2020 at 9:35 AM Daniel Ozer via USRP-users < usrp-users@lists.ettus.com> wrote:
> first of all thanks for the great answers, > still i have few questions: > > 1. Is the crossbar is capable to transfer data between 2 rfnoc blocks at > maximum rate of the crossbar clock ?(bus_clk=187.5MHZ) > > > "Yes. Each port can handle 200MHz worth of bandwidth, but it cannot > handle full bandwidth from both radios at the same time. You'd need > multiple crossbar ports for that." > Why is the crossbar not capable of handling both radio blocks full > bandwidth at the same time? if each radio block is a different instance it > seems like it should work. > The crossbar is capable of doing it, but one single port on the crossbar can't process all the bandwidth. Figure it's 187.5 MHz at 64-bits wide (8 bytes). That's a total of 1500 MBytes/sec that can be transferred. A single channel that consists of 200 MHz of bandwidth, with I and Q both consisting of 16-bits - so 4 bytes total - is 800 MBytes/sec. Add in another channel, and the single ports bandwidth has been exceeded. Does this make sense to you? > > 3. I have a chain : rfnoc: signal source -> rfnoc: DUC (1M to 200M) -> > rfnoc:radio_block. > how is it possible that the connection between the duc and the radio block > doesn't throw an error because the transfer rate is bigger than the clk > speed of the crossbar ? > > > "The bus widths are different between the two domains. Most everything on > ce_clk is 32-bit IQ samples, whereas the bus_clk domain is 64-bits wide." > I tried to find inside the pre-made rfnoc block such as DUC where 2 IQ > 32bit samples are coupled to 64bit bus and i didn't find . Are the samples > supposed to be coupled before leaving the rfnoc block or it something that > i should implement in my block? > It's handled in the axi_wrapper here: https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/axi_wrapper.v > > > "An easy way to decrease the latency, at the expense of more overhead, is > to simply decrease the packet size. (There's some lower limits here... a > packet size of like 4-10 would probably be troublesome, but I've heard > 60ish is a reasonable number and should decrease latency down to 300 > nanoseconds or so assuming ce_clk 200 MHz) " > How can i decrease the size of the packet in the noc_shell? > SPP is a parameter you can pass into the host code and it should try to limit the sizes of things. You can also force it by instantiating a packet_resizer: https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/packet_resizer.v ... but I would really think about the requirement. There's a header associated with each packet, and the more headers you put on, the lower efficiency you get. Brian
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
