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.willi...@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 > 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