Hey Jorge Chen, I see what you're saying. Still, I'm not even sure 8 ports will fit. You could start with 5 ports, and then use a single streamer to get data out of the replay block into the host. You can use the replay block API to specify the memory region you want to download (or upload). So, the first 4 ports are for TX/RX, and the 5th port is for the host backhaul. This also allows you to statically connect the replay block to the DDC/DUC and skip stream endpoint for those. You'd only need one SEP for the 5th port.
If your app permits, you can also reconfigure the RFNoC graph, and use 4 ports total. While you're doing radio stuff, the ports are connected to the DDC/DUC. For download/upload, you reconfigure the graph and connect the replay block to the RX/TX streamers. The neat thing is, this will work with the default bitfile that we provide and you won't have to build your own bitfile. --M On Fri, Oct 11, 2024 at 2:03 PM Jorge Chen <superme...@gmail.com> wrote: > Hi Martin > > Thank you for your reply. I understand the N310’s default Replay block has > 4 input and 4 output ports. In my setup, I connect the tx_streamers to the > Replay block’s input ports and route the output ports to the DUC blocks on > the TX side. On the RX side, I connect the DDC blocks to the Replay block’s > input ports, with the output ports connected to the rx_streamers. This is > why I believe I may need additional ports for simultaneous TX-RX, and I’m > exploring possible solutions. > > I plan to use a 100MHz bandwidth with a sample rate of 122.88MSps per > channel. I’ve noticed that channel time offsets occur when overflows or > underflows happen in the real-time streaming architecture based on the > multi-usrp object. Since stability is crucial, especially it takes time to > collect data. And the experiment will be conducted outdoors, I aim to keep > the system as compact as possible, using just one USRP N310 and a notebook > (there will be a target in the air for transmitting samples to and > receiving samples from). This is why I’m considering using the Replay block > to off load the massive data transmission between NB and USRP N310. > > Thanks again for mentioning the TX/RX cross talk issue. I plan to try > separating the frequencies for the external TX/RX LOs to reduce the > problem. Do you think this approach might help? > > Any further suggestions would be greatly appreciated! > > Thanks! > Jorge > > On Wed, Oct 9, 2024 at 3:53 PM Martin Braun <martin.br...@ettus.com> > wrote: > >> Jorge, >> >> for 4x4 mode, you need 4 ports, not 8. If you configure the replay block >> with 4 channels, it will create both 4 input and output ports, >> respectively. What bandwidth are you trying to capture? >> >> Also remember that if you TX and RX simultaneously, you will get >> crosstalk. >> >> --M >> >> On Tue, Oct 8, 2024 at 10:06 AM Jorge Chen <superme...@gmail.com> wrote: >> >>> Hi all, >>> >>> I’m working on a multi-channel, phase-coherent transceiver platform >>> using the N310 and RFNoC Replay block (UHD4.6). It has been tested >>> successfully for 4TX and 4RX individually. >>> >>> However, I’m facing challenges getting 4TX and 4RX to work >>> simultaneously. >>> >>> Attempts to configure: >>> >>> 1. *1 Replay block with 8 I/O ports:* >>> - Result: Bitstream generated successfully, and Replay block >>> connects with other blocks. However, data read/write fails on ports >>> 4–7. >>> - Inference: [1][2] suggest the N310 Replay block only supports 4 >>> channels, which might explain the issue. >>> 2. * 2 Replay blocks, each with 4 I/O ports:* >>> - Result: Bitstream compilation fails (YAML and logs attached). >>> - Inference: Could the issue be related to connecting both Replay >>> blocks to the same DRAM? If so, is it possible to partition the DRAM >>> for >>> use by both blocks? >>> >>> Reference [2] mentions that DRAM access can be controlled by adjusting >>> axi_intercon_2x64_128_bd to restrict memory availability. >>> Could this be a solution to allow DRAM access for both Replay blocks? >>> >>> Any guidance on configuring the Replay block for simultaneous 4TX/4RX >>> would be greatly appreciated. >>> >>> >>> References: >>> [1] >>> https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4#Building_Custom_FPGA_Images_with_a_Replay_Block >>> [2] >>> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_the_Replay.2FDMA_FIFO_block_to_my_FPGA_image.3F >>> >>> >>> Thanks, >>> Jorge >>> >>> >>> Martin Braun <martin.br...@ettus.com> 於 2024年10月4日 週五 下午11:41寫道： >>> >>>> Mark the last connection as a back-edge ( >>>> https://uhd.readthedocs.io/en/latest/classuhd_1_1rfnoc_1_1rfnoc__graph.html#ab4cca8d99af451a9b9c5757af2b66ffa, >>>> see also >>>> https://uhd.readthedocs.io/en/latest/page_properties.html#props_graph_resolution_back_edges >>>> ). >>>> >>>> --M >>>> >>>> On Fri, Oct 4, 2024 at 4:39 PM hui cj <cjh416593...@gmail.com> wrote: >>>> >>>>> Sorry to bother everyone again, >>>>> >>>>> - 0/Replay#0:0 --> 0/DUC#0:0 >>>>> - 0/DUC#0:0 ==> 0/Radio#0:0 >>>>> - 0/Radio#0:0 ==> 0/DDC#0:0 >>>>> - 0/DDC#0:0 --> 0/Replay#0:0 >>>>> >>>>> I wonder to realize the graph that work for playing from DRAM and >>>>> recording to DRAM simultaneously, >>>>> >>>>> graph->connect(tx_replay_ctrl->get_block_id(), tx_replay_chan, >>>>> duc_ctrl->get_block_id(), duc_chan); >>>>> >>>>> graph->connect(duc_ctrl->get_block_id(), duc_chan, >>>>> tx_radio_ctrl->get_block_id(), tx_chan); >>>>> >>>>> >>>>> graph->connect(rx_radio_ctrl->get_block_id(), rx_chan, >>>>> ddc_ctrl->get_block_id(), ddc_chan); >>>>> >>>>> graph->connect(ddc_ctrl->get_block_id(), ddc_chan, >>>>> rx_replay_ctrl->get_block_id(), rx_replay_chan); >>>>> >>>>> >>>>> Then the following error ran out. >>>>> >>>>> [ERROR] [RFNOC::GRAPH::DETAIL] Adding edge 0/DDC#0:0 -> 0/Replay#0:0 >>>>> without disabling is_forward_edge will lead to unresolvable graph! >>>>> >>>>> Can someone help me? Thanks! >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
