[USRP-users] Drop packets and sequence errors during X410 DPDK benchmark test
Hi, I’m trying to conduct the UHD benchmark test using DPDK on X410 radio. I’m using the NI Dual 100 Gigabit Ethernet PCIe NIC card, using the Mellanox drivers, and have the UC_200 fpga image loaded on the radio. However, I keep experiencing packet drops and sequence errors when I do that. Any idea why that’s happening? /usr/local/lib/uhd/examples$ sudo ./benchmark_rate --args "type=x4xx,product=x410,addr=192.168.20.3,mgmt_addr=192.168.1.3,use_dpdk=1" --priority "high" --multi_streamer --rx_rate 245.76e6 --rx_subdev "B:1" --tx_rate 245.76e6 --tx_subdev "B:0" \[INFO\] \[UHD\] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; UHD_4.7.0.HEAD-0-ga5ed1872 EAL: Detected CPU lcores: 32 EAL: Detected NUMA nodes: 1 EAL: Detected shared linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available 1048576 kB hugepages reported EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.0 (socket 0) EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.1 (socket 0) TELEMETRY: No legacy callbacks, legacy socket not created \[00:00:00.000109\] Creating the usrp device with: type=x4xx,product=x410,addr=192.168.20.3,mgmt_addr=192.168.1.3,use_dpdk=1... \[INFO\] \[MPMD\] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.3,type=x4xx,product=x410,serial=328AFD7,name=ni-x4xx-328AFD7,fpga=UC_200,claimed=False,addr=192.168.20.3,use_dpdk=1 \[INFO\] \[MPM.PeriphManager\] init() called with device args \`fpga=UC_200,mgmt_addr=192.168.1.3,name=ni-x4xx-328AFD7,product=x410,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'. Using Device: Single USRP: Device: X400-Series Device Mboard 0: x410 RX Channel: 0 RX DSP: 0 RX Dboard: B RX Subdev: 1 TX Channel: 0 TX DSP: 0 TX Dboard: B TX Subdev: 0 \[00:00:01.970153754\] Setting device timestamp to 0... \[00:00:01.971248509\] Testing receive rate 245.76 Msps on 1 channels Setting TX spb to 1992 \[00:00:01.972147276\] Testing transmit rate 245.76 Msps on 1 channels U\[D00:00:02.502074084\] Detected Rx sequence error. U\[D00:00:03.501866063\] Detected Rx sequence error. U\[D00:00:04.501965973\] Detected Rx sequence error. U\[D00:00:05.501905705\] Detected Rx sequence error. U\[D00:00:06.501533956\] Detected Rx sequence error. U\[D00:00:07.501567020\] Detected Rx sequence error. U\[D00:00:08.501554331\] Detected Rx sequence error. U\[D00:00:09.501610267\] Detected Rx sequence error. U\[D00:00:10.501971471\] Detected Rx sequence error. U\[D00:00:11.501931301\] Detected Rx sequence error. \[00:00:11.973155250\] Benchmark complete. Benchmark rate summary: Num received samples: 2344330478 Num dropped samples: 113209128 Num overruns detected:0 Num transmitted samples: 2335492512 Num sequence errors (Tx): 0 Num sequence errors (Rx): 10 Num underruns detected: 10 Num late commands:0 Num timeouts (Tx):0 Num timeouts (Rx):0 Done! ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test
I got it work. It seems RT_RUNTIME_SHARE disabled was the culprit. I re-enabled it using these instructions and the benchmark worked without packet drops or underruns:\ \ **Underruns Every Second with DPDK + Ubuntu** With Linux kernels 5.10 and beyond, we have observed periodic underruns on systems that otherwise have no issues. These Linux kernel versions are the default for Ubuntu 20.04.3 LTS and later. The underrun issue is due to the `RT_RUNTIME_SHARE` feature being disabled by default in these versions of the Linux kernel (shown as `NO_RT_RUNTIME_SHARE`). The following procedure can be used to enable this feature. This process was tested on Linux kernel version 5.13; the procedure may be slightly different on other kernel versions. To determine the Linux kernel version of your system, in a terminal issue the command `uname -r`. ``` $ sudo -s $ cd /sys/kernel/debug/sched $ cat features | tr ' ' '\n' | grep RUNTIME_SHARE NO_RT_RUNTIME_SHARE $ echo RT_RUNTIME_SHARE > features $ cat features | tr ' ' '\n' | grep RUNTIME_SHARE RT_RUNTIME_SHARE ``` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test
Here is the cpuinfo from the terminal:\ \ $ sudo cpufreq-set -c 11 -g performance $ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 1: driver: intel_pstate CPUs which run at the same hardware frequency: 1 CPUs which need to have their frequency coordinated by software: 1 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 2: driver: intel_pstate CPUs which run at the same hardware frequency: 2 CPUs which need to have their frequency coordinated by software: 2 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 3: driver: intel_pstate CPUs which run at the same hardware frequency: 3 CPUs which need to have their frequency coordinated by software: 3 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 4: driver: intel_pstate CPUs which run at the same hardware frequency: 4 CPUs which need to have their frequency coordinated by software: 4 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 5: driver: intel_pstate CPUs which run at the same hardware frequency: 5 CPUs which need to have their frequency coordinated by software: 5 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 6: driver: intel_pstate CPUs which run at the same hardware frequency: 6 CPUs which need to have their frequency coordinated by software: 6 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 7: driver: intel_pstate CPUs which run at the same hardware frequency: 7 CPUs which need to have their frequency coordinated by software: 7 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 5.70 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 8: driver: intel_pstate CPUs which run at the same hardware frequency: 8 CPUs which need to have their frequency coordinated by software: 8 maximum transition latency: 4294.55 ms. hardware limits: 800 MHz - 6.00 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 5.70 GHz and 5.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 5.70 GHz. analyzing CPU 9: driver: intel_pstate CPUs which run at the same hardwar
[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test
Yes, its a bare metal system (no VM involved). I have the RF cable connected from A:0 to A:1 and I’m using the Mellanox cable connected from OSFP28-1 (right port on X410) to right port on 100G NIC card. I’m using Xubuntu 22.04.\ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 22.04.5 LTS Release:22.04 Codename: jammy $ ethtool -g enp1s0f0np0 Ring parameters for enp1s0f0np0: Pre-set maximums: RX: 8192 RX Mini:n/a RX Jumbo: n/a TX: 8192 Current hardware settings: RX: 4096 RX Mini:n/a RX Jumbo: n/a TX: 4096 $ sudo sysctl -w net.core.rmem_max=25000 net.core.rmem_max = 25000 $ sudo sysctl -w net.core.wmem_max=25000 net.core.wmem_max = 25000 $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 46 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list:0-31 Vendor ID:GenuineIntel Model name: Intel(R) Core(TM) i9-14900K CPU family: 6 Model:183 Thread(s) per core: 2 Core(s) per socket: 24 Socket(s):1 Stepping: 1 CPU max MHz: 6000. CPU min MHz: 800. BogoMIPS: 6374.40 Flags:fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge m ca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 s s ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nons top_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma c x16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt t sc_deadline_timer aes xsave avx f16c rdrand lahf_lm ab m 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp i brs_enhanced tpr_shadow flexpriority ept vpid ept_ad f sgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rd seed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk av x_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_ window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke wai tpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr ibt flush_l1d arch_capabilities Virtualization features: Virtualization: VT-x Caches (sum of all): L1d:896 KiB (24 instances) L1i:1.3 MiB (24 instances) L2: 32 MiB (12 instances) L3: 36 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds:Not affected Meltdown: Not affected Mmio stale data:Not affected Reg file data sampling: Mitigation; Clear Register File Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prct l Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointe r sanitization Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditiona l; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S Srbds: Not affected Tsx async abort:Not affected ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: LED quickly turns back off X410
Its a high-end ASUS desktop machine with 128 GB RAM:\ description: Desktop Computer product: System Product Name (SKU) vendor: ASUS version: System Version serial: System Serial Number width: 64 bits capabilities: smbios-3.5.0 dmi-3.5.0 smp vsyscall32 configuration: boot=normal chassis=desktop family=To be filled by O.E.M. sku=SKU uuid=f3e615b3-efb6-49fa-381a-581122bbff40 \*-core description: Motherboard product: ROG MAXIMUS Z790 HERO vendor: ASUSTeK COMPUTER INC. physical id: 0 version: Rev 1.xx serial: 221011025300497 slot: Default string \*-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 2202 date: 04/17/2024 size: 64KiB capacity: 16MiB capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial int17printer int10video acpi usb biosbootspecification uefi \*-memory description: System Memory physical id: c slot: System board or motherboard size: 128GiB \*-bank:0 description: DIMM Synchronous 4200 MHz (0.2 ns) product: KF556C40-32 vendor: Kingston physical id: 0 serial: CE344740 slot: Controller0-DIMM0 size: 32GiB width: 64 bits clock: 4200MHz (0.2ns) \*-bank:1 description: DIMM Synchronous 4200 MHz (0.2 ns) product: KF556C40-32 vendor: Kingston physical id: 1 serial: E1345EF2 slot: Controller0-DIMM1 size: 32GiB width: 64 bits clock: 4200MHz (0.2ns) \*-bank:2 description: DIMM Synchronous 4200 MHz (0.2 ns) product: KF556C40-32 vendor: Kingston physical id: 2 serial: D0349087 slot: Controller1-DIMM0 size: 32GiB width: 64 bits clock: 4200MHz (0.2ns) \*-bank:3 description: DIMM Synchronous 4200 MHz (0.2 ns) product: KF556C40-32 vendor: Kingston physical id: 3 serial: 4A348668 slot: Controller1-DIMM1 size: 32GiB width: 64 bits clock: 4200MHz (0.2ns) \*-cache:0 description: L1 cache physical id: 1d slot: L1 Cache size: 384KiB capacity: 384KiB capabilities: synchronous internal write-back data configuration: level=1 \*-cache:1 description: L1 cache physical id: 1e slot: L1 Cache size: 256KiB capacity: 256KiB capabilities: synchronous internal write-back instruction configuration: level=1 \*-cache:2 description: L2 cache physical id: 1f slot: L2 Cache size: 16MiB capacity: 16MiB capabilities: synchronous internal write-back unified configuration: level=2 \*-cache:3 description: L3 cache physical id: 20 slot: L3 Cache size: 36MiB capacity: 36MiB capabilities: synchronous internal write-back unified configuration: level=3 \*-cache:4 description: L1 cache physical id: 21 slot: L1 Cache size: 512KiB capacity: 512KiB capabilities: synchronous internal write-back data configuration: level=1 \*-cache:5 description: L1 cache physical id: 22 slot: L1 Cache size: 1MiB capacity: 1MiB capabilities: synchronous internal write-back instruction configuration: level=1 \*-cache:6 description: L2 cache physical id: 23 slot: L2 Cache size: 16MiB capacity: 16MiB capabilities: synchronous internal write-back unified configuration: level=2 \*-cache:7 description: L3 cache physical id: 24 slot: L3 Cache size: 36MiB capacity: 36MiB capabilities: synchronous internal write-back unified configuration: level=3 \*-cpu description: CPU product: Intel(R) Core(TM) i9-14900K vendor: Intel Corp. physical id: 25 bus info: cpu@0 version: 6.183.1 serial: To Be Filled By O.E.M. slot: LGA1700 size: 5696MHz capacity: 5700MHz width: 64 bits
[USRP-users] LED quickly turns back off X410
I’m receiving a wide bandwidth signal (\~250 MHz sample rate using DPDK) on X410 using GNURadio and I notice that the green LED light turns ON and quickly turns back off whenever I have signal processing blocks (e.g. filter block) connected to the UHD source block. You have 1-2 overflows at the beginning but the GUI seems to work fine showing the signal with the time/freq sink plots. Whenever I just have the time/freq sink blocks only connected to the uhd_source, the green light stays on. My question is would the green light turning quickly off be still an issue? If so, any ideas how to resolve that one? I’m wondering because I will need to re-transmit the signal again using UHD sink block and am experiencing underflows (not been able to resolve this yet and the red transmit light doesn’t turn on). I’m wondering if that’s partly due to the green light turning back off. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Trying to run rfnoc blocks in example uhd folder
I’m attempting to run some of the example rfnoc flowgraphs in Gnruadio using X410. I keep getting an error that’s similar to the following: line 114, in __init__ self.uhd_rfnoc_addsub_0 = uhd.rfnoc_block_generic( RuntimeError: Cannot find block with ID: AddSub Device/Instance: -1/-1 I’m using the latest Gnuradio v3.11.0.0 Does anyone know what that means and how to fix? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Trying to run rfnoc blocks in example uhd folder
Ok, i’ll give that a try ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Build custom fpga image for x410
Hi, I would like to build an fpga custom fpga image for x410. I would need to be able to TX/RX anywhere between 250 to 300 MHz. The prebuilt UC_200 is too low and the CG_400 can’t be adjusted and a bit overkill. Any recommendations on how to best do that? Which version of Vivado would I need? I currently am using UHD 4.7 and have Vivado 2023.1 installed on my machine. I was wondering if its possible to tweak the UC_200 prebuilt image to do that? Thanks ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Build custom fpga image for x410
Hi, thanks for the reply. I’m using UHD 4.7. I ran the following and it worked fine:\ \ $ source ../setupenv.sh --vivado-path=/opt/tools/Xilinx/Vivado/ Setting up a 64-bit FPGA build environment for the USRP-X4xx... \- Vivado: Found (/opt/tools/Xilinx/Vivado//2021.1/bin) Installed version is Vivado v2021.1_AR76780 (64-bit) Environment successfully initialized.\ \ However, from there, I ran rfsoc_image_builder:\ \ \ $ rfnoc_image_builder -y x410_CG_400_rfnoc_image_core.yml -t x410_CG_400 --vivado-path /opt/tools/Xilinx/Vivado/ Using FPGA directory /home/computer/uhd/fpga Selected device: x410 Launching build with the following settings: \* FPGA Directory: /home/computer/uhd/fpga/usrp3/top/x400 \* Build Artifacts Directory: /home/computer/uhd/fpga/usrp3/top/x400/build-usrp_x410_fpga_CG_400 \* Build Output Directory: /home/computer/uhd/fpga/usrp3/top/x400/build \* Build IP Directory: /home/computer/uhd/fpga/usrp3/top/x400/build-ip Executing the following command: /bin/bash -c ". ./setupenv.sh --vivado-path=/opt/tools/Xilinx/Vivado/ && make x410_CG_400 BUILD_DIR=/home/computer/uhd/fpga/usrp3/top/x400/build-usrp_x410_fpga_CG_400 IMAGE_CORE_NAME=usrp_x410_fpga_CG_400" Setting up a 64-bit FPGA build environment for the USRP-X4xx... \- Vivado: Found (/opt/tools/Xilinx/Vivado//2021.1/bin) Installed version is Vivado v2021.1_AR76780 (64-bit) Environment successfully initialized. make: \*\*\* No rule to make target 'x410_CG_400'. Stop.\ \ I’m guessing its supposed to make the .bit file but not able to. I also tried running the Makefile.inc in the build folder (make -f Makefile.inc)\ $ make -f Makefile.inc make: \*\*\* No targets. Stop.\ \ This is what it looks like:\ LIB_DIR := $(HOME)/uhd/fpga/usrp3/lib include $(LIB_DIR)/rfnoc/blocks/rfnoc_block_radio/Makefile.srcs include $(LIB_DIR)/hwutils/Makefile.srcs include $(LIB_DIR)/rfnoc/transport_adapters/rfnoc_ta_x4xx_eth/Makefile.srcs include $(LIB_DIR)/rfnoc/transport_adapters/rfnoc_ta_chdr_dma/Makefile.srcs RFNOC_XDC_SRCS = \\ constraints/pins/qsfp0_0.xdc \\ constraints/pins/qsfp0_1.xdc \\ constraints/pins/qsfp0_2.xdc \\ constraints/pins/qsfp0_3.xdc \\ constraints/pins/qsfp1_0.xdc \\ constraints/pins/qsfp1_1.xdc \\ constraints/pins/qsfp1_2.xdc \\ constraints/pins/qsfp1_3.xdc \\ RFNOC_IMAGE_CORE_SRCS += $(abspath \\ $(BUILD_DIR)/rfnoc_image_core.sv \\ $(RFNOC_CORE_HEADERS) \\ $(RFNOC_BLOCK_RADIO_SRCS) \\ $(HWUTILS_SRCS) \\ $(RFNOC_TA_X4XX_ETH_SRCS) \\ $(RFNOC_TA_CHDR_DMA_SRCS) \\ ) RFNOC_IMAGE_CORE_DEFS = RF_BW=400 RF_CORE_400M=1 DRAM_BANKS=0 DRAM_CH=0 DRAM_W=64 QSFP0_0=5 QSFP0_1=0 QSFP0_2=0 QSFP0_3=0 QSFP1_0=5 QSFP1_1=0 QSFP1_2=0 QSFP1_3=0\ \ \ Any idea what the issue is? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Build custom fpga image for x410
Hi, Thanks for the recommendations. I installed Vivado 2021.1 on my machine and ran the rfnoc_image_builder command found in the documentation using the yaml file x410_CG_400_rfnoc_image_core.yml. It generates a folder build-usrp_x410_fpga_CG_400 with the following files: device_tree.dts Makefile.inc rfnoc_image_core.sv rfnoc_image_core.vh How do I generate the bit fpga image file with this to load onto the x410? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Build custom fpga image for x410
That worked for me. Thank you. However, I’m running into error at the end when its generating the bitstream: \[01:49:04\] Starting Write Bitstream Command\ ERROR: \[Common 17-69\] Command failed: This design contains one or more cells for which bitstream generation is not permitted:\ \[01:49:12\] Current task: Write Bitstream +++ Current Phase: Starting\ \[01:49:13\] Current task: Write Bitstream +++ Current Phase: Finished\ \[01:49:13\] Process terminated. Status: Failure Is this a licensing issue? I’m using the nodelocked trial license for Vivado_ML_Enterprise_Edition. Is there any other license I would need to download to generate the bitstream? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
