On Mon, Jul 28, 2025 at 10:15 AM Kevin Williams <
kevin.willi...@vastech.co.za> wrote:
> I did an experiment today with just this (Ettus blocks only):
>
>
>
> connections:
>
> - { srcblk: radio0, srcport: out_0, dstblk: ep0, dstport:
> in0}
>
> - { srcblk: ep6, srcport: out0, dstblk: ddc0, dstport: in_0 }
>
> - { srcblk: ddc0, srcport: out_0, dstblk: ep6, dstport: in0 }
>
>
>
> Which did not work – the remote streaming stopped.
>
>
>
> Changing the destination EP to a new one, ep7, worked again.
>
>
>
> From the RFNoC 4 workshop slides I was under the impression blocks could
> start and end on the same SEP?
>
For what it's worth, I'm using remote streaming with a custom block and
it's working well.
In fact, the way remote streaming works (at least for an X440) is that the
Ethernet/UDP information is written here:
https://github.com/EttusResearch/uhd/blob/40403b7c00154e4559c47bd6dde924f092992d45/fpga/usrp3/lib/rfnoc/xport_sv/chdr_xport_adapter.sv#L671
The kv_map uses the destination EPID as the key for the ethernet
information which gets looked up for every packet.
So if the streaming works when not doing remote streaming it might be
something else since all data paths go through here.
If you get the first few packets and it stops, is there any way you're
providing `enable_fc` as an argument? That would enable flow control which
obviously wouldn't be good if you aren't doing any flow control processing
on your RX side.
Lastly, I agree with Martin that you should probably add an ILA to your
block and the SEP interfaces to see where the AXI stream is getting stopped
up.
Good luck.
Brian
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
