https://community.element14.com/technologies/fpga-group/FPGA discusses the latest trends in programmable logic devices, and offers access to education, workshops, webinars on FPGAs, SoCs, and other programmable devices.en-USTelligent Community 12https://community.element14.com/technologies/fpga-group/b/blog/posts/bringing-up-an-ad9361-class-2t2r-transceiver-on-zynq-7000-part-1-clock-plan-data-interface-and-the-first-linkSun, 20 Sep 2026 06:42:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7099a951-bfec-4fd2-acb6-7287b8130476LeslieGuoI'm starting a project log for a wideband 2T2R RF front end built around an AD9361-class transceiver paired with a Zynq-7000 (the same class of platform many SDR boards use). The goal is a working, documented bring-up: stable clocking, a reliable digital link to the PL, calibrated RX/TX, and eventually real EVM and noise-figure numbers. Part 1 covers the three things that decide whether you even get to first base. （1）Clock plan Everything in the part is derived from a single reference — on this class of device typically a 40 MHz TCXO. That reference feeds the RF synthesizers (RX/TX LO) and the baseband PLL, which generates the ADC/DAC and data-clock rates. Two practical points: - Use a TCXO, not a bare crystal. A few ppm of drift is fatal for narrow channels and shows up as frequency error across the whole chain. - The clock tree is coupled. The chosen sample rate (up to 61.44 MS/s at the top end) and the baseband bandwidth (200 kHz to 56 MHz) are configured together with the PLL settings — you don't pick them independently. （2) Data interface The transceiver connects to the FPGA over a parallel CMOS or LVDS bus carrying I and Q for both channels, plus a data clock and framing signals. On the Zynq side this lands in the PL and feeds DMA into the PS. - Decide CMOS vs LVDS up front based on trace count and the rate you need; LVDS is the safer choice at the higher sample rates. - Treat the data interface as a timing-closure problem: meet setup/hold on the bus at your data-clock rate before worrying about RF. A swapped I/Q lane or a missed clock edge is the most common "no samples" cause. - Confirm the link with a simple pattern/loopback before attaching the full DMA path. （3) The first "is it alive?" sequence On power-up the device is not ready until an initialization and calibration sequence runs. In practice: - Apply the reference and boot the part into a known state. - Load the initialization parameters (mode, channels, rate, bandwidth, LO, gains). - Run the tracking calibrations — DC offset, LO leakage, quadrature — and wait for them to report done/pass. Polling status, not a fixed delay, is the reliable way. - Only then read I/Q on RX (or transmit a tone on TX) and check it on a spectrum analyzer / IIO-style tool. What I learned first The two things that cost us time were (a) assuming the 70 MHz–6 GHz tuning range meant simultaneous coverage — it's the LO range; you only digitize up to 56 MHz at once — and (b) moving on before the background calibrations had actually settled after an LO change, which lets DC offset and the image drift back. Next in Part 2: getting RX samples through the DMA into the PS over the 1 GbE/IIO-style path, and the no-OS vs SPI-from-the-PL decision (relevant if your FPGA has no soft processor). I'll post register/status details and the first captured spectra. Happy to be corrected by anyone who's done this — and if there's a specific part of the bring-up you'd like me to dig into, say so in the comments. (Disclosure: I work on RF and high-speed data-converter applications, including AD9361-class transceivers. This is a genuine engineering log, not a product pitch.)zynqfpgaad9361sdrrfhttps://community.element14.com/technologies/fpga-group/b/blog/posts/high-speed-fiber-optic-data-transmissionSun, 20 Sep 2026 03:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0fd89a3c-6ba3-4146-8989-b471495ca99ead0es======================================================================== Note: I am in "improve" mode. Network connectivity keeps breaking, and I loose latest changes. So I repost frequently. If this is causing a flood of emails, please excuse. ======================================================================== I have documented 3 other FPGA projects involving Software Defined Radio: Direct Fourier Conversion Software Defined Radio using Cuda Processing Direct Fourier Conversion Software Defined Transceiver Software Defined Transceiver Redux This blog will document a complete system for transfer of ADC samples from multiple remote sites to a central computer via fiber. This is really a continuation of the earlier work, tempered by the realities of moving massive amounts of data without loosing anything! Each time I start s new version I end up upgrading the FPGA cards used. This time I have updated to an Alinx AXKU3: This card is used to connect to 1 thru 4 ADC sample cards via 8GB fiber. ======================================================================================= I am refitting the previously used Alinx XC7K325 to simulate 4 separate ADC cards, each with an ADC running at 60.44MHZ/122.88MHz The real system will have 3-4 cards, each with 1 ADC. ============================================================================================= The sample transfer math (sample rate x 2 bytes per sample x 8 bits per byte x 4 ADCs) 4 2217s sampled at 61.440MHz (DC thru 10 meters) gives us: 61,440,000 × 2 × 8 × 4 = 3,932,160,000 bits per second 4 2208s sampled at 122.880MHz (DC thru 6 meters) gives us: 122,880,000 × 2 × 8 × 4 = 7,864,320,000 bits per second. To achieve this xfer speed, without loosing any data I had to: Go to a faster CPU (threadripper) enable Ubuntu low latency features ================================================================================================ The main CPU box uses an c Asus It has an MSI Gaming RTX 5070 Ti for processing ADC samples: And a VisionTek 550 for video display: It all sits in an Asus ASUS Pro WS WRX90E-SAGE SE EEB Workstation Motherboard: It all sits in a large case: ============================================================================= Getting all that hardware up and happy was a pain. This site got me thru it: https://forum.level1techs.com/t/threadripper-7000-wrx90-trx50-system-build-and-stability-issues-user-input-survey/207630/58 It seems like overkill, but the Ripper makes Vivado builds faster, the GPU provides processing power for the ADC samples, the VisionTek keeps display duties separate from the GPU. ================================================================================================================= I was looking around for info on real-time linux when I discovered Ubuntu already had low-latency features built in, They just need ed to be turned on: https://discourse.ubuntu.com/t/fine-tuning-the-ubuntu-24-04-kernel-for-low-latency-throughput-and-power-efficiency/44834 I used audio: preempt=full nohz_full=all threadirqs: # https://discourse.ubuntu.com/t/fine-tuning-the-ubuntu-24-04-kernel-for-low-latency-throughput-and-power-efficiency/44834 #GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX_DEFAULT="quiet splash preempt=full nohz_full=all threadirqs isolcpus=30-31" Simply copy paste the options above for the desired performance profile and add them to the GRUB_CMDLINE_LINUX_DEFAULT= line in /etc/default/grub (then run sudo update-grub to apply them at the next reboot). Note that I also isolated cpus 30 and 31 for exclusive use with the test program. [add info on confirming changes take effect] =================================================================================================================== These changes alone made it possible to read samples for an hour or so before loosing data. But I need days, so quest is on to use Xilinx Virtual Fifo IP: https://docs.amd.com/v/u/en-US/pg038_axi_vfifo_ctrl I tried using traditional BRAM fifos but ran out of available BRAM. The DMA read is of 65536 bytes, which is quickly overruns the read buffer. By using the virtual FIFO with DDR4 backing ram I get very large buffers. The complete fifoBrd design: There are 4 fiber channels built with Aurora IP: The reset circuit: And the clock circuits: ================================================================================================== I spent WEEKS trying to make it work without luck. Googled more sites than I thought existed. Almost all concluded that vfifo didn't really work... The secret is the design of the 2 switches The board design of the vfifo looks like: The input switch: I had assumed that if you send data into S00_AXIS it would magically come out of the 2nd switch on M00_AXIS. Not so, you have to explicitly set the TDEST for each channel when used. In our design there is no need for dynamic switching, so we set the paths with a CONST: Note the binary value of 11 10 01 00. This causes a TDEST value of 00 to be added to S00_AXIS, 01 to S01_AXIS, etc. It is configured as: This is where it gets tricky: To be able to connect the wire you have to expand S00_AXIS and attach to tdest[7:0] This is actually the 4 sets of 2 bit destinations. You only need to do this with S00_AXIS It attaches 2 bits to each of S0n_AXIS. A similar issue exists with switch 1: Here the CONST should be b'1111 Don't know how to explain, but it causes data from S00_AXIS to travel thru M00_AXIS, etc. Again, only necessary to wire M00_AXIS. It attaches 1 bit to each of M0n_AXIS. ======================================================================================================= The ADC simulation board: Each channel: This is 2 virtual ADCs, each clocked at 61.44MHz: //=========================================================================== // Module name: adcN1.v //=========================================================================== `timescale 1ns / 1ps module adcN1 ( interface_axis1_clk, interface_axis1_rst_n, interface_axis1_tdata, interface_axis1_tready, interface_axis1_tvalid, ); //=========================================================================== // PORT declarations //=========================================================================== input interface_axis1_clk; input interface_axis1_rst_n; input interface_axis1_tready; output interface_axis1_tdata; output interface_axis1_tvalid; reg [15:0] interface_axis1_tdata; reg interface_axis1_tvalid; //=========================================================================== // //=========================================================================== always @(posedge interface_axis1_clk or negedge interface_axis1_rst_n) begin if (~interface_axis1_rst_n) begin interface_axis1_tvalid = 1'b1; interface_axis1_tdata = 16'h0000; end else begin interface_axis1_tdata <= interface_axis1_tdata + 1; end end This creates a stream of 16 bit sample pairs, each spanning 0x0000 thru 0xffff. Bottom line is each of four channels producing equivalent of 1 ADC clocked at 122.88MHz. This pattern can be examined on the main board for any gaps or bad data. ===============================================================================================================https://community.element14.com/technologies/fpga-group/f/forum/57278/fpga-xilinx-spartan-6-p-n-xc6slx150-2csg484i/238236Fri, 18 Sep 2026 08:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:65745b1b-d77d-4518-a903-ad48d0fd1f3fmichaelkellettWhere did you buy them ? MKhttps://community.element14.com/technologies/fpga-group/f/forum/57278/fpga-xilinx-spartan-6-p-n-xc6slx150-2csg484iThu, 17 Sep 2026 17:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:429b98c8-78b4-4567-9631-bbba6ee615aashairichterWe are using FPGA Xilinx Spartan-6 P/N XC6SLX150-2CSG484I. We have identified two labeling configurations on the components. One with the additional labeling "NNBC9-00" (under the word TAIWAN), and the second without this additional labeling. What is the difference between them? The problem is that on the component with the additional labeling NNBC9-00 we are unable to load software to the component (there is no communication during the loading protocol! Or maybe it has different "speed grade"!). On the component without the additional labeling, we are able to load software, and we see that there is communication with the component.xilinxfpgaspartan-6https://community.element14.com/technologies/fpga-group/b/blog/posts/hardware-accelerator-for-hyperspectral-image-processingTue, 14 Jul 2026 07:12:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:098d4647-1d97-4032-a5a7-20edd71cfbcbafernandezHi, community! I’m writing this post because I’d like to share one of the projects I have been working on, a hardware accelerator written in SystemVerilog for processing hyperspectral image vectors. First of all, I want to give some context about this project. Unlike a normal RGB image, a hyperspectral image can contain tens or even hundreds of spectral bands for each pixel. This makes this technology very useful for agriculture, environmental monitoring, remote sensing or material identification, but it also generates a large amount of data that must be processed. For this reason, I wanted to explore how some vector operations could be moved from software to dedicated hardware, reducing the workload of the main processor. The accelerator The current version supports two operations: Dot product Cross product The design uses two input FIFOs and one output FIFO. Internally, a finite-state machine controls the complete process, from reading the vectors to calculating and storing the result. I also developed a wrapper with an OBI-compatible register interface, allowing the processor to configure the operation, select the number of bands, start the accelerator and read its busy, done and error status. The accelerator was integrated into the X-HEEP ecosystem, using a RISC-V processor for control and a DMA controller to transfer the input and output data without requiring continuous CPU intervention. Verification For verification, I used Verilator together with C++ testbenches. I created individual tests for: The FIFO memories The vector processing core The OBI wrapper The complete integrated accelerator The testbenches verify normal operations, invalid configurations, empty and full FIFO conditions, signed calculations and register access. The simulations achieved more than 90% coverage over the instrumented lines and signals. I also generated VCD files to inspect the internal behaviour using GTKWave. Results The functional tests confirmed that the accelerator correctly performs the dot and cross products and responds correctly to invalid operations and boundary conditions. For the cross product, the latency per pixel becomes stable once the finite-state machine has started processing data. For the dot product, the latency increases linearly with the number of spectral bands because the multiply-accumulate operations are performed sequentially. The tests also showed something very important: the vector core itself was not the main bottleneck in the evaluated workloads. The largest limitation came from moving data between memory and the accelerator. The DMA introduces a fixed startup delay for every transfer. Because each operation requires two input transfers and one output transfer, this overhead has a significant impact when processing only a small number of vectors. As a result, the software version can still be competitive for small datasets. The hardware accelerator becomes more useful with medium or large datasets, when the initial DMA cost can be distributed across more operations. The measurements up to 4000000 vectors also showed a mostly linear behaviour, without clear memory saturation or cache-related steps in the evaluated range. Image above shows the latency vs the compute data size for the vectorial product operations. Conclusions The main conclusion from this project is that developing the arithmetic unit is only one part of hardware acceleration. The complete system performance also depends heavily on the memory architecture, bus bandwidth and data-transfer strategy. The accelerator demonstrated that a custom SystemVerilog block can be successfully integrated into an open RISC-V platform and operate autonomously through an OBI interface and DMA transfers. However, using dedicated hardware does not automatically make every workload faster. For small datasets, the communication overhead can cancel out the benefit of the accelerator. For larger workloads, the hardware solution becomes more interesting because the fixed transfer cost is amortised and the CPU is released to perform other tasks. In future versions, I would like to explore double buffering and overlapping DMA transfers with computation. I also want to support larger spectral vectors, improve the internal accumulator and finally synthesise the design on an FPGA to analyse resource usage, maximum frequency and power consumption. One of the biggest lessons I learned is that a good accelerator must not only calculate quickly: it must also receive and return data efficiently. I’m very happy with the results so far, and I would love to hear your feedback and suggestions! If any person want to get mor info about this project I can share the github link.fpga_projectsfpgavhdlfpga-projectdspsystemverilogveriloghardware_acceleratorshttps://community.element14.com/technologies/fpga-group/f/forum/25947/barriers-to-designing-with-fpgas/236239Fri, 26 Jun 2026 08:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7fb1b810-129b-49de-bb49-b02570b56cb6ShishirReading all these comments, experienced developers sharing their experiences and views, looks like having found a lost treasure. Great knowledge.https://community.element14.com/technologies/fpga-group/w/setup/26642/featured-content-triptych-setup-docThu, 28 May 2026 12:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7e3dbc4b-ad3d-4d73-aeac-6597508eadc2e14sbhargavPath to Programmable III Collaborated with Path III is the third session in the element14 Community’s structured FPGA-based SoC training. The first Path was held in 2018 and focused on programmable logic devices PLDs and featured the AVNET MiniZed development board, based on AMD’s Zynq-7000 SoC. Path II convened in 2019 and offered more advanced learning opportunities and featured the AVNET Ultra96-V2 development board, based on AMD’s Zynq UltraScale+ MPSoC. Path III will double the fun by offering structured training on both the MiniZed and Ultra96-V2 boards. Each training track will be followed by a design/build phase. Learn More Achieving Deterministic Latency with the AMD Kria ™ ︎ K24 SOM Adaptive Computing The Bulls Eye® High Performance Test System Samtec Flyover® Technology for FPGA Apps Memory Storage for FPGA Applications Accelerating Embedded Vision with the CrossLink ™ -NX FPGA On Demand Webinars: Getting Started with the AMD Spartan ™ ︎ UltraScale+ ™ ︎ FPGA SCU35 Eval Kit PYNQ-Z2 Workshop Series: FPGA Experiments With Xilinx Pynq-Z2 Power Integrity Effects on FPGA Functionality and Performance Leveling-Up Your FPGA Skills: An Expert Panel Discussion Getting Started with FPGAs: An Expert Panel Discussion Summer of FPGA: Software and FPGA: How to Get the Bits to Flip? Intro to Smart Embedded Vision (SEV) Using a PolarFire ® FPGA Building Processor Based Systems on Lattice FPGAs Using Propelhttps://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235724Thu, 21 May 2026 13:46:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1cef9723-cb6b-41e0-bf69-d4cbf4ddaec3wolfgangfriedrich[quote userid="36226" url="~/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235702"]Now I'm slightly less envious of the four people who won those nice Xilinx boards recently.[/quote] The option is to use 2025.2.1 and not upgrade any further.https://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235722Thu, 21 May 2026 13:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0aa099f7-10a3-4df9-95da-d35d089ef3cfkk99Maybe hobbyists that do not want to use VM or switch environments will start with other alternatives, like Gowin.https://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235717Thu, 21 May 2026 12:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:32d1609e-0dff-4af5-a111-0275cc766308bradfordmillerParticularly if you are using PetaLinux or the new EDF. Maybe paying for EDF (too bad "classic" MicroBlaze users) is why they're pushing the paid CORE package? At least 2025.2 and before are still available free (for the smaller chips anyway)! I wouldn't mind paying for CORE so much if it was something I could do every 3 years which is about how I use the current upgrade cycle (i'm still on 2023.1). But for that "privilege" I'd have to spring for ENTERPRISE...https://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235702Thu, 21 May 2026 08:05:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:137f8965-a423-4e27-9724-8c97a405cce2jc2048Now I'm slightly less envious of the four people who won those nice Xilinx boards recently. "Are there alternatives?" Lattice, Microchip, et al. I've got the no-cost editions of Diamond (Lattice) and Radiant (Lattice) running happily on Xubuntu 22.04. Libero (Microchip) installed ok, but I haven't done the licence serving part yet, so can't say for sure it runs happily. I think the basic level of Altera's Quartus (Lite edition) is available for Linux, but the 3rd party simulator is not for 22.04 (you'd need Red Hat, or one of its derivatives). I might give it a try as I've got the Vidor 4000 board and at some point my old Windows 8.1 laptop will probably die.https://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier/235695Wed, 20 May 2026 22:25:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e560dd00-0353-4dd0-a12d-b0133a23b4bddyessggAny word as to why Linux support is excluded from the Basic tier? I would think Linux would be the primary platform people use these tools on.https://community.element14.com/technologies/fpga-group/f/forum/56972/amd-changes-vivado-license---locks-out-linux-support-from-basic-tier-edit-maybe-notWed, 20 May 2026 22:11:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8e4fe275-4a78-4bb2-9c72-c65999a11d1estantoWhat was arguably an avenue into free development, being able to use Linux and then Vivado, is now locked down into buying a supported Windows license to use free Vivado. If you want Linux support you now have to pay for it. $1,200+. Existing installations will likely still work. https://www.amd.com/en/products/software/adaptive-socs-and-fpgas/vivado/vivado-licensing-options.html Are there alternatives? Maybe it works with Wine? Edit: 1st June 2026 Looks like they changed their minds! https://www.linkedin.com/posts/vivado-licensing-options-share-7466166724040564736-4D76/ https://adaptivesupport.amd.com/s/article/Adding-LINUX-support-back-for-the-BASIC-free-version-of-Vivado?language=en_USlinux supportlicensevivadoamd