[USRP-users] Re: Reset Timing Violation

There's not enough information in the screen shot, but I think the output of the double synchronizer is on a different clock domain than flop flop (dato_entrada) being reset by it. The reset signal needs to be driven by the same clock as the flip flop being reset, otherwise Vivado can't ensure tha

[USRP-users] Re: ChdrPacket and ChdrData errors and warnings

Hi Kevin, The BFM for CHDR does some checks to make sure packets are formatted correctly. The error message means the "Length" field in the CHDR header doesn't match the length of the AXI-Stream packet. The chdr_to_item call is giving a warning because it's expecting a multiple of 32-bits (ITEM_W

[USRP-users] Re: Synthesis of Xilinx IP in RFNOC

Hi Adrían, Was it an error or a warning that you received? Sometimes black boxes get resolved in a later build stage. Was the message output during the generation of the IP, or synthesis of the E320? Normally when you build the FPGA, it first builds all the IP. So I'm wondering if that step was c

[USRP-users] Re: E320 - loopback test error

I believe the CODEC loopback tests the connection between the FPGA and the AD3961. Maybe the device is damaged? I would try putting a clean SD card image on there and see if it's still happening. If so, I would try different cables, power supplies, and host Ethernet device to rule those out. If tha

[USRP-users] Re: UHD 4.1.0 speed

There was a change related to how get_time_now was implemented in UHD 4.0 but that was improved in UHD 4.2. I would expect the behavior in 4.2 to be more like 3.15 and earlier. Wade On Wed, Oct 12, 2022 at 3:24 AM zhou via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Marcus, > > Differen

[USRP-users] Re: UHD_IMAGE_LOADER load another .bit

I'm not sure if the FPGA image didn't load, if you loaded the wrong one, or if your block isn't working for some reason. Does the FPGA git hash reported by uhd_usrp_probe match the one you built from? If the git hash still shows a different one than the one you built from, then you're still using a

[USRP-users] Re: Why initialize large array in Verilog is not successfully in RFNOC blocks...

Does the file you're reading from have enough data in it? Wade On Thu, Oct 13, 2022, 7:39 AM sp wrote: > Why initialize large array in Verilog is not successfully. When size of > array is 255 it work like charm but for other number more than 255 like > 1024 and > we observe all array is f

[USRP-users] Re: AXI-RAM memory width

Right, it needs to be 64 bits to work without other changes. That's the width of the AXI Interconnect to which the axi_ram block connects. However, the connection to the DRAM is 256 bits. That gets shared across 4 ports by the AXI Interconnect, and each port could potentially be reading and writing

[USRP-users] Re: Debugging E320 with JTAG causes a problem

Hi Yasir, The E320 runs Linux on the SoC of FPGA. There are devices in the FPGA which are visible to the Linux kernel, so updating the FPGA without first bringing down those devices causes problems. uhd_image_loader takes care of all this for you. You can use uhd_image_loader to first load your bi

[USRP-users] Re: Why initialize large array in Verilog is not successfully in RFNOC blocks...

e? > > On Fri, Oct 14, 2022 at 7:36 PM Wade Fife wrote: > >> Does the file you're reading from have enough data in it? >> >> Wade >> >> >> On Thu, Oct 13, 2022, 7:39 AM sp wrote: >> >>> Why initialize large array in Verilog is not su

[USRP-users] Re: Debugging E320 with JTAG causes a problem

the examples to the host or anywhere else. I just want all ADC samples to > go into my custom RFNoC-block. I don't want any other datas such as > metadatas or anything else, but only ADC samples. > > My System: > Device : E320 > OS : Ubuntu 20.04.4 > UHD: 4.0 > > Kind

[USRP-users] Re: How to use command replace hardware-reboot

If you can connect over USB, you can connect to the SCU, which will allow you to shutdown the device and turn it back on. To connect to the SCU, see: https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_micro https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_serial_micro

[USRP-users] Re: Simulation after synthesis or implementation

Hi Adrián, It is possible to do a post-synthesis simulation, but that's an advanced topic and I wouldn't recommend it unless you suspect you've found a bug in Vivado synthesis. There's no way to do a post-implementation simulation that I know of. If you want to do a normal simulation and write yo

[USRP-users] Re: AXI_RAM_FIFO doesn´t return any information

You mentioned you don't receive any ready. Do you mean that the tready signal never asserts on your output port? It is not allowed in AXI-Stream to wait for tready to assert before asserting tvalid. Some devices will assert tready before tvalid asserts, but some won't. You need to assert tvalid whe

[USRP-users] Re: Simulation for RFNoC block input signal

Yes. Take a look at the gain OOT RFNoC block example: https://github.com/EttusResearch/uhddev/blob/master/host/examples/rfnoc-example/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv For example, here it generates test input data: https://github.com/EttusResearch/uhddev/blob/1be0f33bf32fd319facc654cb5

[USRP-users] Re: X410 - FPGA unresponsive after several RFNoC Graph Creations

Hi Maximilian, This sounds similar to some issues that are already fixed. I tried what you did on my X410 running UHD 4.3 and didn't see this issue. Can you try updating the X410 to UHD 4.3 to see if that resolves the issue? Thanks, Wade On Fri, Nov 4, 2022 at 3:20 AM Maximilian Matthé < maxim

[USRP-users] Re: How can we develop two RFNOC block that there is a reg relation between them?

Gain and multiply are pretty simple operations. Perhaps you could put them both in the same block? Then you would not need to share this register between different blocks. Wade On Sun, Nov 6, 2022 at 1:06 PM sp wrote: > I am developing two RFNOC blocks, a gain block, and a multiplier block... >

[USRP-users] Re: How many user reg we can define in a RFNOC block?

There's no limit. See previous answer here: https://lists.ettus.com/empathy/thread/XECWYF2DOQI2BKWFZ6SQM47I3BX2VCRS Wade On Mon, Nov 14, 2022 at 10:37 AM sp wrote: > I have developed some RFNOC blocks. I had a question. > in an RFNOC block HOW many user registers can we use? can we use three >

[USRP-users] Re: x410 master clock rate

Hi Dario, It looks like this mode was never officially supported. I'm going to follow up with R&D on Monday (it's a holiday in the US), since I don't know if there's a reason this mode wasn't kept in the code. The recommended way to get 125 Msps is to use X4_200 with the DDC and a master clock rat

[USRP-users] Re: UHD SPP problem with E320 and XG link

Hi Samie, In your example, you requested to use "addr=10.40.3.1". To use the 10 GbE SFP port, be sure to specify the address of the XG port, which is typically 192.168.10.2. I don't think jumbo frames are supported over the 1 GbE RJ45 port. Thanks, Wade On Fri, Dec 16, 2022 at 4:47 AM Samie Mos

[USRP-users] Re: Building x310 FPGA image for UHD 4.3.0

It says the IP is locked. Perhaps you have old IP left over from a previous build that used an older Vivado version (the Vivado version changed with UHD 4.3). Try doing "make cleanall" to remove all the IP before building it again. Also, do a 'git status' and make sure you don't have any extra file

[USRP-users] Re: The design did not satisfy timing constraints.

Here's a quick explanation. FPGAs have clocks that control the transfer of data between its internal registers. The Xilinx Vivado tool does a timing check during build to make sure that the paths from each driving register to each receiving register is not too long for the specified clock period. W

[USRP-users] Re: RFNoC OOT Xilinx IP not XCI Based

FPGA IP output products are generated as part of the make process for FPGA builds. There's no mechanism in rfnoc_image_builder itself to do anything IP related since rfnoc_image_builder just runs make for the FPGA target. The UHD repo has examples of IP using XCI, BD, and TCL that describes a BD (V

[USRP-users] Re: Building x310 FPGA image for UHD 4.3.0

You probably need to install Xilinx patch AR76780. See the dependencies section in the manual for links to the patch: https://files.ettus.com/manual/md_usrp3_build_instructions.html UHD has already been updated to give you an error when this patch is not installed and you try to build the FPGA, b

[USRP-users] Re: Building x310 FPGA image for UHD 4.3.0

Oh, thanks for pointing that out! Maybe that was correct at one point, but the patch is definitely required for X310 as well in UHD 4.3. I'll see that this gets changed in the manual. Wade On Tue, Jan 3, 2023 at 3:19 PM wrote: > I noticed that part of the manual but ignored it because it sounds

[USRP-users] Re: RFNoC FFT block on X410

One trick with the FFT block I think is that the packet size needs to match the FFT size. Try something like: radio = uhd.rfnoc.RadioControl(graph.get_block("0/Radio#0")) radio.set_properties("spp=" + str(fft_size)) Wade On Sat, Jan 7, 2023 at 12:11 PM Piotr Krysik wrote: > Hello, > > Does an

[USRP-users] Re: Dears,

No, this is normal behavior for N310. Wade On Tue, Jan 24, 2023 at 4:56 AM mychk1 1 wrote: > > I'm using USRP N310. I observed that the fans is regularly speed up down > without any streaming. I just connect SFP0 and the ETH. Is there something > wrong? > > BR, > Marchin >

[USRP-users] Re: Help with replay_capture.py

Hi Uri, Thanks for reporting this! You are correct. Here's a patch for UHD-3.0 (see below) to fix it until we get a permanent solution in UHD. The record was working correctly, but it was replaying the same buffer in memory for all channels. Thanks, Wade diff --git a/host/examples/python/repla

[USRP-users] Re: Help with replay_capture.py

Apologies, I meant to say the fix is for UHD-4.3, not 3.0. Wade On Fri, Jan 27, 2023 at 1:52 PM Wade Fife wrote: > Hi Uri, > > Thanks for reporting this! You are correct. Here's a patch for UHD-3.0 > (see below) to fix it until we get a permanent solution in UHD. The rec

[USRP-users] Re: Error when synthesizing example OOT block : IP "cmplx_mul" is locked

Hi Lorenzo, I tried your steps but couldn't reproduce the issue you're seeing. I wonder if somehow the patch is not being picked up, or perhaps you somehow have stale build files. Can you run the following? cd fpga/usrp3/top/x300/ source setupenv.sh What's the output of setupenv.sh? At this poin

[USRP-users] Re: Error when synthesizing example OOT block : IP "cmplx_mul" is locked

ivado project I used to import the > xci files for updating. Maybe there is a better way to open the .xci > without creating a new project? > > Thanks, > Lorenzo > > -- > *From:* Wade Fife > *Sent:* Thursday, February 2, 2023 7:37 PM >

[USRP-users] Re: Module not found when creating OOT module

My initial guess was that the module in rfnoc_block_trigger.v wasn't named rfnoc_block_trigger. Vivado says it found the file "rfnoc_block_trigger.v" but not the module named "rfnoc_block_trigger". Or perhaps there was something else wrong with the module that caused it to not compile? But then I d

[USRP-users] Re: Block controller hangs in testbench

Hi Joe, You could try stepping through the testbench code in the simulator to see where it's hanging, or look at your block's signals in the simulation to see what it does with the write. Make sure it behaves the same as one of the register writes in a working testbench. Perhaps a reset signal is

[USRP-users] Re: benchmark_rate throws error

Hi Joe, The error you're getting basically means it can't communicate with the FPGA on the N320. It's sending a packet to the device, but it's not getting the response packet it expects. So it could be a network configuration issue, a cabling issue, maybe a firewall issue, or something else that's

[USRP-users] Re: X310 - All LEDs are off

Hi Ali, I wonder if the FPGA is not coming up. I'm not sure what the LEDs do in that case and I don't have a device handy to check. You could try this recovery procedure to see if that fixes the problem. https://kb.ettus.com/X300/X310_Device_Recovery If not, the device may be damaged. Wade On

[USRP-users] Re: USRP E320 DMA

Hi Yasir, Maybe you could add another RFNoC CHDR port to your block just for streaming the parameter data. So it would have a dedicated streamer separate from the one used for ADC data. Wade On Fri, Feb 17, 2023 at 2:53 AM Yasir Özçalık wrote: > Hi everyone, > I have a problem with DMA. I am t

[USRP-users] Re: USRP X410 + QSFP28 network adapter from intel

Hi Piotr, I don't know of anyone who has tried that card specifically for 10 GbE, but Intel cards in general are commonly used with USRPs for 10 GbE. However, the Intel cards are not recommended for 100 GbE on X410. See here for the recommended cards and cables which has been tested and validated

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

You could swap the bytes in your block, or swap them in software on the host. The data gets rearranged by the streamer depending on the data type configured (e.g., sc16) and the endianness of the host machine. Wade On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via USRP-users < usrp-u

[USRP-users] Re: X410 Overflow with Custom FPGA

Hi Brian, Unfortunately, the DSP inside the current RFNoC DDC block processes one sample per clock cycle. So the maximum sample rate through the DDC is the same as the rate of the clock you provide to the ce clock input. With the 400 MHz bitstreams, radio_2x is 245.76 MHz. Because this is below th

[USRP-users] Re: X410 Overflow with Custom FPGA

rate can match the clock rate. Wade On Wed, Mar 22, 2023 at 10:00 PM Brian Padalino wrote: > On Wed, Mar 22, 2023 at 10:40 PM Wade Fife wrote: > >> Hi Brian, >> >> Unfortunately, the DSP inside the current RFNoC DDC block processes one >> sample per clock cycle.

[USRP-users] Re: Using RAM in a OOT block

Hi Lorenzo, There might be a better way to design the RAM you want. 4096 samples is only 16 KiB, which you should be able to do with block RAM. Using DRAM seems like overkill for such a small amount of data. For example, the DRAM IP itself uses more than 16 KiB of buffers just to talk to the DRAM.

[USRP-users] Re: Backpressure over Ethernet

It sounds like something isn't right. The streamers should automatically backpressure. That's how it works with the radio, and it should be the same for a custom block connected to stream endpoints. We have seen cases where host ethernet interfaces can't keep up when you start approaching the line

[USRP-users] Re: PCIe NIC card connect to USRP-X410

Hi, Please see the recommendations in the following KB article: https://kb.ettus.com/X410#10_Gigabit_Ethernet https://kb.ettus.com/X410#100_Gigabit_Ethernet Wade On Tue, Apr 4, 2023 at 12:45 PM wrote: > Hello, > > What PCIe NIC cards are suggested to connect USRP-X410 through 10GbE and > 100G

[USRP-users] Re: x410 x4_200 connectivity question

I don't think that card supports 4 x 10 GbE. But suppose you used a card that does, or you used multiple 10 GbE cards to connect to all four 10 GbE ports on the X410, then you would set the args to "addr=192.168.10.2,second_addr=192.168.11.2,third_addr=192.168.12.2,fourth_addr=192.168.13.2". The st

[USRP-users] Re: intel X710DA4 NIC card and breakout cable

This is the card Ettus sells for this product. It's the Intel X7A-DA2. https://www.ettus.com/all-products/10gige-kit/ For X410 cables, if you want to use 4 x 10 GbE, go to this link and click to view the accessories for X410. Look for the "QSFP28 To 4xSFP28 Breakout Cable, 1M". https://www.ni.co

[USRP-users] Re: Remote Streaming UHD 4.4 on USRP-2974

Hi, On the USRP-2974 I thought "sfp1" on the FPGA was the port that goes to the internal NIC/CPU. Maybe try sfp0? You should be able to see the packets in wireshark if you run that on the other computer. Also, the activity lite on the USR-2974 should blink. Thanks, Wade On Thu, May 18, 2023 at

[USRP-users] Re: X410 not powering on

Hi Arjan, I have not heard of this before. It should be as simple as connecting an appropriate AC cable to the X410 power supply brick, plugging the AC cable into the wall, then plugging the 6-pin power cable into the X410 and pressing the power button. If you haven't already, try disconnecting e

[USRP-users] Re: x410 TX issues

Did you test your code one one of the default images? That'd be a good way to confirm that you're using the replay block correctly. It could also be a simple mistake in the YAML. Maybe you could share your custom YAML to get another set of eyes on it? Did you add any custom logic that data is supp

[USRP-users] Re: vivado 2021.2

Hi Kevin, You could upgrade Vivado. It would take some work to update all the IP, and there's a chance that something might break. That error is pretty random, so even the slightest change can make it go away. If you're using UHD-4.4 then you can change the build seed. For example: make BUILD_SE

[USRP-users] Re: N2rt13HDRTExceptionE in Vivado 2021.1

It depends on the target, but normally if you repeat the same build you will get exactly the same results. I suggest you try the build seed option I mentioned in your other thread. This feature is intended to give you a different build result when you want one. I'm curious to know what target you'

[USRP-users] Re: x410 TX issues

Wow, I don't know why running it in the GUI would matter. You mentioned you did some customization in the Vivado GUI. Could that have something to do with it? I looked over your YAML and I noticed you have MEM_DATA_W on the Replay block set to 128 but you're building for the X410_X4_200 target whi

[USRP-users] Re: x410 TX issues

I believe the indicator light is ultimately driven by the RFNoC radio block. It turns on when it receives data packets to be transmitted. So if it doesn't turn on, that likely means no data is making it from the replay block to the radio block. Wade On Thu, Jun 8, 2023 at 9:19 AM wrote: > I had

[USRP-users] Re: Control operation timed out with custom block

Hi Joe, This error message usually means that the host did a register read/write request but never got a response from the USRP. This might happen, for example, if a clock wasn't properly connected to the NoC shell. It could also be some kind of network issue (swapped cables, firewall, improperly

[USRP-users] Re: UHD 4.0 - Reading FPGA core temperature - USRP2974

Hi Marino, The register is there, but it sounds like we don't expose it through the API. This utility is out of date, but it can still be used to read the temperature value: ~/uhd/firmware/usrp3/x300$ python2 x300_debug.py --addr=192.168.10.2 --peek=0xA02C In that command, 192.168.10.2 is the IP

[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

[USRP-users] Re: Custom RFNoC block: data throughput bottleneck

I suspect your logic isn't processing packets correctly. For example, maybe the sequence number is wrong on the output packets, or some other header information is incorrect. Or maybe your AXI-Stream handshake logic is wrong, causing you to miss samples. Or maybe TLAST isn't being asserted on the c

[USRP-users] Re: RFNoC Image Builder: two problems with Vitis HLS

00:06] Current task: Initialization +++ Current Phase: Finished > > [00:00:06] Process terminated. Status: Failure > > > > I will report back on your suggestion of commenting out the line ASAP. I > would be very happy to hear feedback from you regarding the errors/warnings > above in the

[USRP-users] Re: RFNoC Image Builder: two problems with Vitis HLS

/sdr/uhd/fpga/usrp3/lib/ip/axi_hb31/Makefile.inc:20: > LIB_IP_AXI_HB31_TRGT] Error 1 > > make[1]: Leaving directory '/home/fobp/sdr/uhd/fpga/usrp3/top/n3xx' > > make: *** [Makefile:90: N3X0_IP] Error 2 > > > > > > Other than that, commenting out the line

[USRP-users] Re: Custom RFNoC block: data throughput bottleneck

> Jernej Kokalj > > The blocks' location ( > https://git.gsi.de/p.niedermayer/exciter/-/tree/feedback_rfnoc/rfnoc-beam_exciter/fpga > ): > >- sources and simulation are inside the >folder rfnoc_block_feedback_controller >- the rfnoc_block_feedback_controller uses

[USRP-users] Re: Building Bitstream for USRP X410

Hi, What did you run to get this error? Which version of the UHD repo are you using? Building the FPGA requires a Vivado license, but all of the IP is included with Vivado. Assuming you have a working Vivado license, please ensure you have the correct version of Vivado installed for the version o

[USRP-users] Re: Building Bitstream for USRP X410

ther I should upgrade or downgrade the Vivado version? > Also, I am holding a University License of Vivado, is it possible that IP > is not available for my license? > Thanks. > > Regards, > Arman > > > On Tue, Jul 25, 2023 at 7:04 AM Wade Fife wrote: > >> Hi, >>

[USRP-users] Re: MPM major compat number mismatch even after updating FW to latest on X410

I think you checked out the wrong branch. Looking at your [INFO] statement, it says you're using a2a04e31, which is the latest commit on master. 5.2 is also the version you should get from the master branch. The "4.4" hasn't been updated on master yet because it's not released yet. Wade On Fri, A

[USRP-users] Re: What is the power socket on an Octoclock CDA-2990?

The connector on the Octoclock is a Switchcraft L722RA. I don't know the part number for the mating connector, but you might be able to find a compatible one using that as a reference. Wade On Wed, Aug 9, 2023 at 7:33 AM Royce Connerley via USRP-users < usrp-users@lists.ettus.com> wrote: > I ret

[USRP-users] Re: Xilinx Zynq 7020 SoC

The Zynq SoC on the E3xx/N3xx USRPs is a 7-Series Xilinx device, so you'll find it with the other Xilinx 7-Series documentation. Maybe this is what you're looking for? https://docs.xilinx.com/v/u/en-US/ug479_7Series_DSP48E1 Wade On Mon, Aug 14, 2023 at 6:34 PM Marcus D. Leech wrote: > On 14/08

[USRP-users] Re: Overflows with CHDR_W = 128 on x410

Hi Joe, Did you change the chdr_width in the rfnoc_image_core YAML file and rerun rfnoc_image_builder on that file? Which version of UHD are you using to build the FPGA? Streaming over 10 GbE to 128-bit CHDR with 500 Msps radio isn't a use case we test, since 10 GbE can't keep up. Normally we wo

[USRP-users] Re: How to use Questa for simulation

What gives an error? What are you trying to simulate and how are you running the simulation? The last time I used Questa, I think I just added it to my path instead of ModelSim and it worked the same. Some additional changes might be needed if you want to use Visualizer with our Makefiles instead

[USRP-users] Re: Overflows with CHDR_W = 128 on x410

If you are streaming data from the radio, then overflows are to be expected since 10 GbE can't keep up with 500 Msps. But that should happen with 64-bit CHDR as well. It doesn't matter how big the buffers are. If you are not using the radio, then overflows should not occur at all, since there's no

[USRP-users] Re: Overflows with CHDR_W = 128 on x410

You are correct about INGRESS_BUFF_SIZE. It's only used to buffer data that the stream endpoint receives from another endpoint (e.g., data sent from the host computer to a stream endpoint). There's no extra buffering in the sending stream endpoint. For normal RX where we stream to a host computer,

[USRP-users] Re: Overflows with CHDR_W = 128 on x410

What was the error message or symptom that told you that you were getting an overflow? RFNoC has flow control throughout the datapath, so when things can't keep up, the pipe normally backs up into the radio and that's where the overrun occurs. In other words, when the radio receives a new sample bu

[USRP-users] Re: Overflows with CHDR_W = 128 on x410

That would be the radio reporting the overflow then. So, it sounds like your gate causes data to back up into the radio where it eventually ran out of room. Increasing the PYLD_FIFO_SIZE makes more space for data to buffer up, increasing the time before an overflow would occur Wade On Fri, Aug 18

[USRP-users] Re: USRP X410 and PCIe connection

PCIe using the iPass+ zHD connectors is not supported on X410 with UHD. Like Marcus said, there's no software support in UHD for it. It is only supported with NI LabVIEW using the NI-USRP driver. Wade On Mon, Aug 21, 2023 at 11:36 AM Marcus D. Leech wrote: > On 21/08/2023 12:24, Paul Atreides w

[USRP-users] Re: Component fpga is too new for X410

The MPM software on your device is older than the FPGA you're trying to use. Because you're using master, they haven't published updated filesystems with the new MPM yet, but there will be a release candidate very soon for UHD 4.5 you could try. Wade On Tue, Aug 22, 2023 at 10:20 AM Zacharias M K

[USRP-users] Re: Fatal: Timeout: Test "Test passing through samples" time limit exceeded

A testbench timeout is intended to prevent the test from waiting forever for something that's not working. So if it's timing out, it's either because the timeout is too short or because the thing it's waiting for is not happening. Try searching for the timeout message text to see where the timeout

[USRP-users] Re: X410 FPGA build failure with UHD-4.4

Hi Ryan, What was the problem/error message that suggested that folder wasn't being pulled in properly? The "syntax error" implies that the `RFNOC_EDGE_TBLE_FILE definition isn't being set correctly, but the makefile should pass that in based on the target you're building. Did you make modificati

[USRP-users] Re: EXTERNAL: Re: X410 FPGA build failure with UHD-4.4

y what's going on there. > > Also, the "dev_config.json" file was missing from the x400 folder, not > sure if that's another generated file, or just missing from the branch. I > copied that from the x300 folder. > > Thanks, > > Ryan > > ---

[USRP-users] Re: X410 FPGA build failure with UHD-4.4

Oh, interesting. I'd like to understand why it doesn't work for some people. This FPGA gets built quite regularly by myself and others without this issue. Wade On Fri, Aug 25, 2023 at 9:53 AM wrote: > Hello, > > The undefined *RFNOC_EDGE_TBL_FILE* macro is a typical error when you try > to buil

[USRP-users] Re: Specifications of host computer for 100 Gb/s streaming with x410

There are some general recommendations here: https://kb.ettus.com/X410#100_Gigabit_Ethernet The CPUs listed there are a bit old now. High single-thread CPU performance is important. Having several CPU cores dedicated for streaming is important too, but you can only use so many cores for streaming,

[USRP-users] Re: Specifications of host computer for 100 Gb/s streaming with x410

Yes, one QSFP gives you one 100 GbE port. So there are two 100 GbE ports with the X410_CG_400 image. Regarding other considerations, see the expected data throughput rates in that same link. Streaming performance is generally limited by the host computer. Wade On Tue, Aug 29, 2023 at 3:36 PM wro

[USRP-users] Re: ettus x410, Device is in bad state error

Hi Joe, Update the filesystem on the X410 to match the UHD version you're using on your host computer (and the bitstream you're trying to load): https://kb.ettus.com/USRP_X410_Getting_Started_Guide#Updating_Filesystems Thanks, Wade On Wed, Sep 6, 2023 at 12:30 PM wrote: > Hello, > > > I am c

[USRP-users] Re: X440 at lower sample rates

Hi Dario, There are other differences in the FPGA code as well, since X440 is designed for higher rates and channel counts. For example, the X440 doesn't have additional DDCs/DUCs in the FPGA fabric. I think the manual page does a pretty good job of summarizing the differences. https://uhd.readth

[USRP-users] Re: RFNOC TB

Yes, you can do that. Wade On Tue, Oct 10, 2023 at 7:19 AM wrote: > Hi every one, > > > I would like to use the rfnoc testbench but with my own signals and remove > this condition: > > > `ASSERT_ERROR( > > sample_out == sample_in, > > $sformatf("Sample %4d, received 0x%08X, expected 0x%08X", >

[USRP-users] Re: RFNoC/MPM: No valid clock index given (63)

Thanks for reporting Zach. This will be fixed soon. Thanks, Wade On Wed, Nov 1, 2023 at 3:49 PM Rohde, Zach (US 333G) via USRP-users < usrp-users@lists.ettus.com> wrote: > I am trying the new UHD 4.6 X440 X4_200 image and I am running into this > error after updating the host UHD and flashing t

[USRP-users] Re: RFNOC TB

You would need to replace the code that writes to the DUT with code that reads from your file and writes your data instead. Similarly for the output, replace the code that checks the output with your own code to check the output and/or write it to a file. My guess is that your changes broke some as

[USRP-users] Re: rfnoc_image_builder error with uhd4.6

Hi Enrico, The line numbers in the traceback don't seem to match UHD 4.6. Can you check if you maybe have different or multiple versions installed? And double check that the rfnoc_image_builder being called is indeed the version for UHD 4.6? For example, if you installed from source, double check

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

Hi Muhammad, It says the design doesn't fit in the FPGA. Did you modify the YAML or FPGA code? If so, you may need to reduce what you're including. If not, maybe try building the unmodified FPGA: cd fpga/usrp3/top/e31x source setupenv.sh make E310_SG3 Thanks, Wade On Tue, Dec 12, 2023 at 9:05 

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

The E310 has a very small FPGA, so fitting the replay block and DRAM logic is a challenge. You might be able to fit a single replay channel, but nothing else extra. If you're limiting the device to one channel, you might also be able to remove one of the radio channels and the corresponding stream

[USRP-users] Re: CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more evaluation cores that will cease to function after a certain period of time. This desig

Hi German, The critical warning sounds ominous but can be safely ignored. The licenses are included with Vivado, but Vivado gives the warning anyway. As long as you have a Vivado license, and a bitstream was generated, the 10 GbE IP should work fine. Wade On Thu, Dec 21, 2023 at 11:20 AM German

[USRP-users] Re: question about X410 _d images and CHDR width

Hi Dario, The _d version is optimized for use with DRAM and the non-_d version is optimized for streaming to a connected host computer over 100 GbE. On the non-DRAM versions, the wider CHDR width gets applied to the stream endpoints, which connect to the host computer via 100 GbE. In testing we've

[USRP-users] Re: Non-Unique Device MAC Address's After Mender F.S. Update

The MAC address should come from the EEPROM. You can run eeprom-dump on the device to see what MAC addresses are programmed in it. You can use eeprom-init to program the EEPROM. Run either with --help to see the syntax. https://github.com/EttusResearch/uhd/blob/master/mpm/tools/README.md I'm curi

[USRP-users] Re: Unable to Simulate RFNoC FFT Module in Questa/Modelsim

Did you look through the simulation libraries that you built to see if xfft_v9_1_6 is in there? I'm wondering if it's not there or if ModelSim just can't find it. Take a look at the manual page if you haven't already: https://files.ettus.com/manual/md_usrp3_sim_running_testbenches.html Let's assu

[USRP-users] Re: Unable to Simulate RFNoC FFT Module in Questa/Modelsim

Hmm. If the library path is correctly added in the modelsim.ini being referenced, then it should find it, or at least the error would be different. You could check the [Library] section of your modelsim.ini to make sure everything looks correct. As another option, have you tried "make modelsim" to

[USRP-users] Re: Unable to Simulate RFNoC FFT Module in Questa/Modelsim

Sure, at this moment I'm using: Vivado v2021.1_AR76780 Model Technology ModelSim SE-64 vsim 2021.3 Simulator 2021.07 Jul 13 2021 Our CI pipelines appear to be using: ModelSim SE-64 2020.4 I know we've used PE, DE, and Questa as well, but I don't know for sure when we last tested this particular I

[USRP-users] Re: RFNoC FFT block on X410

Hi Sebastian, You might be using an old YAML file and tring to apply it to a new version of UHD. Take a look at the YAML file for the version of the FPGA closest to what you want. For example, here's the default X410 image in UHD 4.6: https://github.com/EttusResearch/uhddev/blob/UHD-4.6/fpga/usrp

[USRP-users] Re: RFNoC socket error on X410

One common thing that causes this error is having cables swapped. Normally, you need to connect the host computer port with 192.168.10.1 to the SFP port with 192.168.10.2 (and they should be on the same subnet), but if you mix them up then it'll sometimes let you ping, but more complex operations l

[USRP-users] Re: x310 Not Sending Jumbo Packets (>8000 bytes) as 1 Packet on 10GigE

Hi all, 8192 bytes is the maximum frame size supported by the FPGA, but that's including all headers. So the actual RF data payload that you can send is less than this, typically closer to 8000 bytes. I often set my SPP to 1996 out of habit since this is usually a pretty safe number with jumbo fra

[USRP-users] Re: x310 Not Sending Jumbo Packets (>8000 bytes) as 1 Packet on 10GigE

For the first version can you try setting has_time_spec to false after the first packet is sent, and don't bother to set the time_spec on subsequent packets within a burst? The time_spec should really only be for the first packet. The radio will ignore the timestamp on the subsequent packets within

[USRP-users] Re: Ettus KB: Missing CE clocks

Thanks for pointing that out! I'll make sure that gets updated. Thanks, Wade On Tue, Jun 25, 2024 at 12:52 PM Rohde, Zach (US 333G) via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > > I noticed in the RFNoC Frequency Asked Questions >

[USRP-users] Re: x310 Not Sending Jumbo Packets (>8000 bytes) as 1 Packet on 10GigE

You might need to make some tweaks to your system. Take a look at the suggestions here: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks Wade On Mon, Jun 24, 2024 at 8:18 PM wrote: > Hi Wade, > > I am now receiving “U” instead of “L”. They don’t come out on the console > that o

[USRP-users] Re: Fwd: UHD 4.7 - Building X310_XG FPGA

IP generation issues tend to be caused by using the wrong Vivado version, or having stale files laying around from previous versions. Make sure you're using Vivado 2021.1 with the patch AR76780 installed. If you changed Vivado versions at some point, you may need to clean the repo to remove any sta

[USRP-users] Re: SPP, Burst Transmission and RFNoC AXI Data Signals

Hi Aditya, Each CHDR packet will be given to the block as an AXI packet, so TLAST asserts every S samples. At the end of a burst, the EOB flag in the header of the CHDR packet is asserted to indicate it's the last packet of the burst. Wade On Tue, Aug 13, 2024 at 8:08 PM Sathish, Aditya wrote:

<    1   2   3   >