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.
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?
"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?
בתאריך יום ג׳, 11 באוג׳ 2020 ב-21:06 מאת EJ Kreinar <
ejkrei...@gmail.com>:
> Agree on all points.
>
> A few further thoughts:
>
> > I saw in the article (" Measured Latency Introduced by RFNoC
> Architecture" )that the nocshell and the axi wrapper have a big latency
> (100nanosec and 1.7microsec) . There is a way to drop down the latency ?
>
> First, I probably would not classify 100 me as "high latency"-- if your ce
> clock is at 200 MHz that's just 20 clock cycles! Not too bad.
>
> Second, the root cause of the large latency from the cited paper is
> because the crossbar is fundamentally a N-to-N "packetized" switch....
> Before any data goes onto the crossbar, the noc_shell accumulates a full
> packet of data within a fifo in the noc_shell and then the entire packet is
> sent to the crossbar at the bus_clk rate. 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)
>
> If you would like to fully AVOID the overhead of the packetized crossbar
> because you need absolute minimal latency, you could theoretically add
> side-channels between rfnoc blocks, or insert your logic into a different
> part of the design (like the radio block, perhaps). I have heard of these
> strategies working for some people, but I really wouldn't recommend that
> for a beginner rfnoc user since you would effectively break all the helpful
> utilities that come along with rfnoc as-is (automatic builds,
> reusability/modularity of rfnoc blocks, etc).
>
> EJ
>
>
>
> On Tue, Aug 11, 2020, 9:32 AM Brian Padalino via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On Tue, Aug 11, 2020 at 6:18 AM Daniel Ozer via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi everyone,
>>> Im just started developing on the usrp X310 platform and i have some
>>> 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.
>>
>>>
>>> 2. if i have this theoretical chain : rfnoc: block1 -> rfnoc: block2
>>> -> rfnoc: block3 -> rfnoc: block4
>>> Is every block can send data to the next block at the maximum rate of
>>> the crossbar clk ?
>>>
>>
>> Yes. The crossbar acts as a switch.
>>
>>
>>>
>>> 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.
>>
>>
>>>
>>> 4. Is it possible to change the crossbar clk to ce_clk=214MHZ instead of
>>> bus clk ?
>>>
>>
>> Maybe, but what would be the point? You'll probably end up not being
>> able to close timing on the design, but that's just a guess.
>>
>>
>>>
>>> 5. I saw in the article (" Measured Latency Introduced by RFNoC
>>> Architecture" )that the nocshell and the axi wrapper have a big latency
>>> (100nanosec and 1.7microsec) . There is a way to drop down the latency ?
>>>
>>
>> I don't know how to address this. Maybe a link to the article and to
>> figure out where the "large" latencies are? What is your target latency?
>>
>> Brian
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
