[USRP-users] Routing 10Gbe SFP+ via a switch to 25Gbe host
Hi All Given the amount of small form factor hosts that now support 2.5Gbe I was wondering if anyone has tried/had success to connect an X310’s 10Gbe SFP+ via a switch to convert it to 2.5Gbe. It has been mentioned on this mailing list that the network stack is very minimal on the X310, but I assume a switch should be able to handle translation of the speed and the X310 should actually not really be aware of this node sitting inbetween. Related, I am looking for small form factor hosts that can work with an X310. The biggest issue seems to be SFP+ support. The Supermicro Sys-E300 series looks promising, but I am struggling to find pricing locally in South Africa. Anyone use one of them with an X310 or have other similar suggestions? Your thoughts? Leon Wabeke ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] RFNoC Image Builder: two problems with Vitis HLS
Hello everyone, I'm currently stuck with creating a custom RFNoC bitfile with rfnoc_image_builder. I'm building the image for a USRP N310 and the software I'm using is the following: - Debian 12 - Python 3.11.2 - UHD 4.3.0.0 - Vivado 2021.1 (installed with the additional patch) The command I use to build the image is (I created the file n310_rfnoc_fosphor.yml myself): rfnoc_image_builder -F ~/uhd/fpga -y ~/core_yml/n310_rfnoc_fosphor.yml -t N310_XG After an unsuccessful build, the image builder gets stuck with HLS: BUILDER: Building HLS IP addsub_hls BUILDER: Staging HLS IP in build directory... Waiting for concurrent IP build to finish... (1800s [Ctrl-C to proceed]) I was wondering if there was a way to skip the concurrent IP build, using Ctrl-C only causes the entire rfnoc_image_builder to exit unsuccessfully with: make: *** [Makefile:90: N3X0_IP] Interrupt Waiting for the timeout after 1800 seconds throws the following error that I do not understand at all: source /tools/Xilinx/Vitis_HLS/2021.1/scripts/vitis_hls/hls.tcl -notrace can't read "zny": no such variable while executing "0Nyy-&ur-r$$!$-9-)n$ v t-n q- !$zny-%vz'yn&v! -v s!$zn&v! -zr%%ntr%-n$r-v -&uv%-svyr-" (file "/tools/Xilinx/Vitis_HLS/2021.1/common/scripts/error_message.tcl" line 2) invoked from within Additional info: before that, I had to upgrade two IP cores provided by UHD in Vivado manually because rfnoc_image_builder threw the error: CRITICAL WARNING: [filemgmt 20-1366] Unable to reset target(s) for the following file is locked: /home/fobp/sdr/uhd/fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/hb47_1to2/hb47_1to2.xci I would be happy to hear any help or pointers to how I could solve this problem. Thank you and regards Luca Bachmaier ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Problems streaming with X310 using Rust
Hi Mark, first time I see samcrow's uhd-rust! Interesting, and it does quite a few things. Now, I'll guess that the uhd-rust streamer objects are working subtly differently than the underlying C++ objects, and you notice that here. It does seem to make a few assumption on internals of UHD, which I can't from the top of my head confirm. Generally, it uses the UHD C API, as far as I can glimpse, and that of course means the whole chain of ownership is uhd_rust -> UHD C API offering opaque handles -> UHD C API function taking these handles -> calling C++ methods through shared pointers internally -> UHD (which is C++, not C) I do see the chance for unpleasant surprises there, so that's where I'd start looking. Best, Marcus On 29.06.23 15:40, Mark Koenig wrote: Hello, I am attempting to use Rust to task a continuous stream with the B200mini, N210 and X310. I have it working quite well for the B200mini and N210, but having trouble with the X310. With the X310 I am unable to have the stream be continuous and task more than 1 channel for the streamer. I am using the Github https://github.com/samcrow/uhd-rust for the UHD bindings and have verified all of the required C++ libraries have been imported correctly. Does anyone have any examples, experience or suggestions on how to get the X310 working correctly? Thank you very much Mark ___ USRP-users mailing list --usrp-users@lists.ettus.com To unsubscribe send an email tousrp-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] Re: RFNoC Image Builder: two problems with Vitis HLS
Hi Luca, Can you try going into the uhd/fpga/usrp3/top/n3xx/ and running `make cleanall` and running the build again? You should not have had to manually upgrade IP unless there was some kind of mismatch somewhere. Perhaps you tried building first without the patch but didn't clean out the old IP that was generated? A version mismatch might explain the HLS error you're getting. If the HLS IP continues to give you problems, you could try commenting out this line. https://github.com/EttusResearch/uhddev/blob/UHD-4.3/fpga/usrp3/lib/hls/Makefile.inc#L7 Wade On Tue, Jul 4, 2023 at 5:50 AM Bachmaier, Luca < luca.bachma...@iis.fraunhofer.de> wrote: > Hello everyone, > > > > I'm currently stuck with creating a custom RFNoC bitfile with > rfnoc_image_builder. I'm building the image for a USRP N310 and the > software I'm using is the following: > > - Debian 12 > > - Python 3.11.2 > > - UHD 4.3.0.0 > > - Vivado 2021.1 (installed with the additional patch) > > > > The command I use to build the image is (I created the file > n310_rfnoc_fosphor.yml myself): > > rfnoc_image_builder -F ~/uhd/fpga -y > ~/core_yml/n310_rfnoc_fosphor.yml -t N310_XG > > > > > > After an unsuccessful build, the image builder gets stuck with HLS: > > > > BUILDER: Building HLS IP addsub_hls > > > > BUILDER: Staging HLS IP in build directory... > > Waiting for concurrent IP build to finish... (1800s [Ctrl-C to > proceed]) > > > > I was wondering if there was a way to skip the concurrent IP build, using > Ctrl-C only causes the entire rfnoc_image_builder to exit unsuccessfully > with: > > make: *** [Makefile:90: N3X0_IP] Interrupt > > > > > > Waiting for the timeout after 1800 seconds throws the following error that > I do not understand at all: > > source /tools/Xilinx/Vitis_HLS/2021.1/scripts/vitis_hls/hls.tcl > -notrace > > can't read "zny": no such variable > > while executing > > "0Nyy-&ur-r$$!$-9-)n$ v t-n q- !$zny-%vz'yn&v! -v s!$zn&v! > -zr%%ntr%-n$r-v -&uv%-svyr-" > > (file > "/tools/Xilinx/Vitis_HLS/2021.1/common/scripts/error_message.tcl" line 2) > >invoked from within > > > > > > Additional info: before that, I had to upgrade two IP cores provided by > UHD in Vivado manually because rfnoc_image_builder threw the error: > > CRITICAL WARNING: [filemgmt 20-1366] Unable to reset target(s) for > the following file is locked: > > > /home/fobp/sdr/uhd/fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/hb47_1to2/hb47_1to2.xci > > > > > > I would be happy to hear any help or pointers to how I could solve this > problem. > > > > > > Thank you and regards > > Luca Bachmaier > > > ___ > 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] Custom RFNoC block: data throughput bottleneck
Dear all, we are working on a custom OOT RFNoC Block implementation [1] on a USRP X310 and are facing data throughput bottlenecks. The DSP is controlled via GNU Radio / UHD like this: Signal Source -> RFNoC TX Streamer -> custom OOT block -> RFNoC RX Streamer -> QT GUI Time Sink When running the flow graph we get a lot of "" printed to the console, i.e. package drop due to buffer overflow. Adding a GNU Radio "Probe rate" block shows that the sampling rate before the TX Streamer is 200kSps as desired. However, behind the RX Streamer, the sampling rate is only 64 Sps (!). When bypassing our custom VHDL implementation in the OOT Block (i.e. assigning all s_out_axis_t* to respective m_in_axis_t*) the flow graph works as expected, so the RFNoC part alone works just fine. The VHDL implementation requires some 100 clock cycles for a sample to propagate. But since we use the 200MHz clock, achieving sampling rates of 200kSps should not be an issue. The custom OOT block also has an option for interpolation (i.e. increasing sampling rate), but the behaviour is the same even for interpolation=1. Do you have some hints on how to improve performance? We have already tried to - Increase the payload FIFO depth from 32 to 128 - Try both, the context-payload and the data AXI-Stream interface - Assert tlast on every sample to reduce packages size Some things we have considered but are not sure about: - MTU size - Package size Thanks for taking the time to share your ideas Philipp, Jernej, Blaž [1] https://git.gsi.de/p.niedermayer/exciter/-/blob/f02ee94ad3358fff313fc14a1a8d8494ad68d8ab/rfnoc-beam_exciter/fpga/rfnoc_block_feedback_controller/rfnoc_block_feedback_controller.v#L419 smime.p7s Description: S/MIME Cryptographic Signature ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
