Hi,

I am curious as to how sample alignment for MIMO DSP is guaranteed in the
RFNoC framework?

I see sample stream alignment mechanisms in blocks like the AddSub block,
and have written similar logic for my own new blocks. Is there a certain
tolerance of sample delays that will never be exceeded?

My real question is that I am trying to trace an issue where I have two
input streams to my block (coming from a 0/Radio#0:0 and 0/Radio#0:1) but
the second stream is always stalled. I never see TVALID's from it, even
though both master TREADY's are simply hardcoded for now. (I can see this by
means of packing the handshaking bits into the output data samples.)

I've just compiled an ILA into the design but I suspect this will just show
the same.

Thanks, Kevin

Hi Martin,

This is interesting feedback.

On the streaming, I am using a python create_rx_streamer() directly on the graph to the connected to the 1 or 2 outputs of my new rfnoc block, like this:

g_graph  = uhd.rfnoc.RfnocGraph("type=n3xx,addr=10.20.101.1")

stream_args  = uhd.usrp.StreamArgs("fc32", "sc16")

g_rx_streamer = g_graph.create_rx_streamer(2, stream_args)

I was not aware of the need for forking streaming commands, and I am not sure how to do this. I will try and find info in the docs, but if there is anything special to know it would be very valuable. (I can compile UHD by hand, and have been doing for certain debugging.)

On the “consuming of samples” I am under the impression that by me asserting TREADY an upstream block will consider that sample “consumed”, and of course, I do this on both streams from the (single) radio on the N300?

So between the forking streaming commands and the sample consumption I’m sure my issue is there somewhere.

Thanks, Kevin

From: Martin Braun martin.braun@ettus.com
Sent: Monday, 07 April 2025 16:16
Cc: usrp-users@lists.ettus.com
Subject: [EXTERNAL][USRP-users] Re: rfnoc sample alignment from two radio channels

We don't have any examples of blocks doing MIMO DSP -- that use case is a bit special because in general, you also want to compare timestamps. But let's stick with the addsub block, you could consider that a form of MIMO processing (coherent combining of signals assuming they're already phase-aligned...?).

The addsub block will properly align samples from upstream radio blocks if everything is on the same FPGA, because you usually don't lose samples on the FPGA, and we assume that the radios will get started at the same time. If you don't consume samples from a radio block, it will stall pretty quickly.

If tvalid is never going high, then maybe the second radio block is never actually starting to stream? How are you submitting stream commands? Straight to the radios, or to the streamer (and if it's the latter, is your block controller forking the stream command)? If you're running at TRACE level, then the radio will report all stream commands but for that you'd need to compile UHD by hand.

--M

On Sun, Apr 6, 2025 at 9:49 AM Kevin Williams <kevin.williams@vastech.co.za mailto:kevin.williams@vastech.co.za > wrote:

Hi,

I am curious as to how sample alignment for MIMO DSP is guaranteed in the
RFNoC framework?

I see sample stream alignment mechanisms in blocks like the AddSub block,
and have written similar logic for my own new blocks. Is there a certain
tolerance of sample delays that will never be exceeded?

My real question is that I am trying to trace an issue where I have two
input streams to my block (coming from a 0/Radio#0:0 and 0/Radio#0:1) but
the second stream is always stalled. I never see TVALID's from it, even
though both master TREADY's are simply hardcoded for now. (I can see this by
means of packing the handshaking bits into the output data samples.)

I've just compiled an ILA into the design but I suspect this will just show
the same.

Thanks, Kevin

USRP-users mailing list -- usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com mailto:usrp-users-leave@lists.ettus.com