usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRFNoC Replay module (DRAM to PC)
Hello all,
I have some confusion regarding the RFNoC Replay module.
Due to the limited transmission rate between my computer and the X310, I
cannot transmit and receive waveforms in real-time. Therefore, I want to
use the Replay module to transmit the waveform stored in DRAM and record
the received signal into DRAM.
Based on the following links:
https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#What_can_the_DRAM_be_used_for.3F
https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4
I believe this functionality can be achieved.
The provided example has already implemented the Record and Play functions,
but I am still confused about how to store the waveform in DRAM and then
transfer it to the computer.
Q1:
Is only one channel of the Replay module needed to achieve this
functionality?
Q2:
(1) The example constructs the following graph to store the transmitted
data in DRAM:
- TxStreamer#0:0 --> 0/Replay#0:0
- 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 --> RxStreamer#0:0
(2) To store the received data into DRAM at the same time, should I
construct the following graph as well?
- 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
(3) To read the data from DRAM and transfer it to the computer:
- 0/Replay#0:0 --> RxStreamer#0:0
Q3:
I want to start both the Record and Play functions of the Replay module at
the same time. Is this possible?
Is there any example code available that shows how to transfer DRAM data to
the computer?
Thank you!
Q1) Yes, only one channel is required. Each channel has both send and
receive capabilities and you can use both simultaneously. However, note
that sending and receiving between host and replay block, and between
replay block and radio, simultaneously, would require two channels. For
example, one channel for TX/RX between host and replay block, and another
channel for TX/RX between replay block and radio.
Q2) Notice that you have the same block ports being used in both (1) and
(2), so you can't do both graphs at the same time. You'll need to switch
between graphs or use additional ports on the Replay block if you want to
connect the replay block to the host and to the radio at the same time
while being able to transfer in both directions. But the routes you gave
look valid.
Q3) Yes. You can use timed commands for both Rx and Tx.
Here's an example for RX (record from radio to replay block, then transfer
to host):
https://github.com/EttusResearch/uhd/blob/master/host/examples/python/replay_capture.py
Here's an example for TX (transfer from host, then playback to radio):
https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc_replay_samples_from_file.cpp
They both use timespecs to indicate the time to start receiving or
transmitting at the radio. The basic idea is that you tell it some known
time in the future to begin.
Wade
On Thu, Oct 3, 2024 at 12:29 PM hui cj cjh416593819@gmail.com wrote:
Hello all,
I have some confusion regarding the RFNoC Replay module.
Due to the limited transmission rate between my computer and the X310, I
cannot transmit and receive waveforms in real-time. Therefore, I want to
use the Replay module to transmit the waveform stored in DRAM and record
the received signal into DRAM.
Based on the following links:
https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#What_can_the_DRAM_be_used_for.3F
https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4
I believe this functionality can be achieved.
The provided example has already implemented the Record and Play
functions, but I am still confused about how to store the waveform in DRAM
and then transfer it to the computer.
Q1:
Is only one channel of the Replay module needed to achieve this
functionality?
Q2:
(1) The example constructs the following graph to store the transmitted
data in DRAM:
- TxStreamer#0:0 --> 0/Replay#0:0
- 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 --> RxStreamer#0:0
(2) To store the received data into DRAM at the same time, should I
construct the following graph as well?
- 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
(3) To read the data from DRAM and transfer it to the computer:
- 0/Replay#0:0 --> RxStreamer#0:0
Q3:
I want to start both the Record and Play functions of the Replay module at
the same time. Is this possible?
Is there any example code available that shows how to transfer DRAM data
to the computer?
Thank you!
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi all,
exactly for this use-case we have written a Wrapper around UHD [1] which does exactly what is requested by the original question. It has been tested with X310 and worked, but most development and testing is currently done on X410. Maybe this can help the development.
Max
[1] https://github.com/Barkhausen-Institut/usrp_uhd_wrapper
Maximilian Matthe
Head of Engineering Lab
maximilian.matthe@barkhauseninstitut.org
Tel.: +49 173 4509667
From: Wade Fife wade.fife@ettus.com
Sent: Friday, October 4, 2024 2:34 AM
To: hui cj cjh416593819@gmail.com
Cc: usrp-users@lists.ettus.com usrp-users@lists.ettus.com
Subject: [USRP-users] Re: RFNoC Replay module (DRAM to PC)
Q1) Yes, only one channel is required. Each channel has both send and receive capabilities and you can use both simultaneously. However, note that sending and receiving between host and replay block, and between replay block and radio, simultaneously, would require two channels. For example, one channel for TX/RX between host and replay block, and another channel for TX/RX between replay block and radio.
Q2) Notice that you have the same block ports being used in both (1) and (2), so you can't do both graphs at the same time. You'll need to switch between graphs or use additional ports on the Replay block if you want to connect the replay block to the host and to the radio at the same time while being able to transfer in both directions. But the routes you gave look valid.
Q3) Yes. You can use timed commands for both Rx and Tx.
Here's an example for RX (record from radio to replay block, then transfer to host):
https://github.com/EttusResearch/uhd/blob/master/host/examples/python/replay_capture.py
Here's an example for TX (transfer from host, then playback to radio):
https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc_replay_samples_from_file.cpp
They both use timespecs to indicate the time to start receiving or transmitting at the radio. The basic idea is that you tell it some known time in the future to begin.
Wade
On Thu, Oct 3, 2024 at 12:29 PM hui cj <cjh416593819@gmail.commailto:cjh416593819@gmail.com> wrote:
Hello all,
I have some confusion regarding the RFNoC Replay module.
Due to the limited transmission rate between my computer and the X310, I cannot transmit and receive waveforms in real-time. Therefore, I want to use the Replay module to transmit the waveform stored in DRAM and record the received signal into DRAM.
Based on the following links:
https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#What_can_the_DRAM_be_used_for.3F
https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4
I believe this functionality can be achieved.
The provided example has already implemented the Record and Play functions, but I am still confused about how to store the waveform in DRAM and then transfer it to the computer.
Q1:
Is only one channel of the Replay module needed to achieve this functionality?
Q2:
(1) The example constructs the following graph to store the transmitted data in DRAM:
- TxStreamer#0:0 --> 0/Replay#0:0
- 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 --> RxStreamer#0:0
(2) To store the received data into DRAM at the same time, should I construct the following graph as well?
- 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
(3) To read the data from DRAM and transfer it to the computer:
- 0/Replay#0:0 --> RxStreamer#0:0
Q3:
I want to start both the Record and Play functions of the Replay module at the same time. Is this possible?
Is there any example code available that shows how to transfer DRAM data to the computer?
Thank you!
USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
Barkhausen Institut
www.barkhauseninstitut.org
Barkhausen Institut gGmbH | Sitz: Schweriner Str. 1, 01067 Dresden, Germany | Registergericht: Amtsgericht Dresden, HRB 37267 | Geschäftsführer: Prof. Dr. Gerhard Fettweis, Dr. Tim Hentschel | Vorsitzender der Gesellschafterdelegation: Jan Gerken
Hinweise zum Datenschutz und zur Verarbeitung Ihrer Daten finden Sie unter: https://barkhauseninstitut.org/data-privacy
This email and any attachments are intended only for the person to whom this email is addressed and may contain confidential and/or privileged information. If you received this email in error, please do not disclose the contents to anyone, but notify the sender by return email and delete this email (and any attachments) from your system. Information on data protection and processing of your personal information: https://barkhauseninstitut.org/data-privacy
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!
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 cjh416593819@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-leave@lists.ettus.com
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 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.
- Result: Bitstream generated successfully, and Replay block connects
-
- 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.braun@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 cjh416593819@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 superme991@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.braun@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 cjh416593819@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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.braun@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 superme991@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.braun@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 cjh416593819@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 superme991@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.braun@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 superme991@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.braun@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 cjh416593819@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hello Hui could you solve this Issue? I am trying sth very similar. Since the hints you got from wade, more precisely the two examples you were pointed at are python and C++ my question is, can this be done using python only? Say transmit num_x (say 500k-2mio samples) and receive num_x + margin at the same time. So that Tx and Rx are triggered exactly at the same time (regarding the precision the USRP can give)…
Since I already have a lot of Signal processing already done in Python. Otherwise I’ll have to figure go deeper into C++