FPGA Innovations

FPGAs have long been essential for high-performance computing, AI acceleration, and signal processing—but scalability and efficiency have remained persistent challenges. Enter Monolithic 3D (M3D) FPGA architecture, a breakthrough leveraging stackable back-end-of-line (BEOL) transistors to redefine FPGA design. 🔍 What Makes M3D FPGAs Game-Changing? Traditional FPGAs rely on Si-based SRAM for configuration memory, but M3D architecture integrates: ✅ N-type (W-doped In₂O₃) and p-type (SnO) amorphous oxide semiconductor (AOS) transistors in the BEOL ✅ More compact and power-efficient pass gates for reconfigurable circuits ✅ FPGA switch and connection block matrices stacked above configurable logic blocks (CLBs) 💡 The Results? 📉 3.4x reduction in area-time squared product (AT²) ⚡ 27% lower critical path latency for faster execution 🔋 26% lower power consumption in reconfigurable routing blocks 🔬 Why This Matters for Future Applications With leading foundries investing in BEOL-compatible AOS transistors, M3D FPGAs are poised to: 🧠 Accelerate hyperdimensional computing and large language models (LLMs) 🌍 Enable ultra-efficient edge AI inference and real-time signal processing 📡 Revolutionize next-gen telecom, radar, and high-frequency trading systems 🔑 The Road Ahead By interfacing with Verilog-to-Routing (VTR) tools, M3D FPGA designs in 7 nm technology are already demonstrating next-level performance gains. As device research and circuit design converge, we’re looking at a new era of FPGA efficiency, scalability, and power optimization. ⚙️ How do you see M3D FPGAs shaping the future of reconfigurable computing?

What if a chip didn’t have to be final? That’s the question Ross Freeman asked in 1984—at a time when ASICs ruled the silicon world. Back then, hardware was rigid. Changing logic meant redesigning the entire chip, waiting weeks for fabrication, and burning through budget. But Ross had a radical idea: What if we could build a chip whose function could be reprogrammed even after manufacturing? The result? He co-founded Xilinx and created the world’s first Field-Programmable Gate Array (FPGA). The first chip—XC2064—had just 64 configurable logic blocks (CLBs). It wasn’t fast, it wasn’t cheap, and it certainly wasn’t mainstream. But it worked. Engineers could now implement, test, and modify logic in hardware without going back to the fab. For the first time, hardware had software-like flexibility. In an era dominated by fixed-function chips, that was heresy. FPGAs slowly found a home in applications where change was constant: ◦ Telecom, where protocols evolved rapidly ◦ Aerospace, where reconfigurability mid-mission was vital ◦ Prototyping, where time-to-market could be shortened dramatically Over time, Xilinx expanded its product lines: □ Spartan for cost-sensitive markets □ Virtex for high-performance applications □ Zynq for integrating CPUs and logic fabric But Ross Freeman didn’t live to see the impact. He passed away in 1989—just five years after Xilinx was founded. His invention went on to power: ◦ Telecom backbone equipment ◦ Satellites and spacecraft ◦ Industrial and automotive controllers ◦ Rapid prototyping for nearly every ASIC and SoC team on the planet And in 2022, Xilinx was acquired by AMD for $49 billion—one of the largest deals in semiconductor history. Not bad for an idea everyone thought was too slow, too costly, and too complicated. Sometimes, true innovation isn’t faster or smaller—it’s more flexible. And sometimes, the riskiest ideas become the foundations we all build on. #Semiconductors #Xilinx #FPGA #HardwareDesign #ChipDesign #StartupHistory #VLSI #TechInnovation #EDA

A few months ago, we shared with you our progress on developing novel decoding algorithms for qLDPC codes. That effort resulted in the Relay-BP algorithm (https://lnkd.in/eFbWNFeU), which surpassed prior state-of-the-art qLDPC decoders in terms of logical error rate while simultaneously removing barriers toward real-time implementation. In particular, we showed that a novel variation of the belief propagation (BP) algorithm was sufficient for accurate decoding of our gross code without the need of an expensive second-stage decoder to fix cases where BP failed to converge. I’m excited to tell you about some of the progress we’ve made on taking the first steps towards implementing a real-time decoder in hardware (https://lnkd.in/e8CShTmT). Our initial effort has focused on FPGAs because they are very flexible and allow for very low-latency integration into our quantum control system. FPGAs’ flexibility in supporting custom logic and user-defined numerical formats allowed us to evaluate the performance of Relay-BP across a range of floating-point, fixed-point, and integer precisions. Encouragingly, we observe a high tolerance to reduced precision. Our experiments show that even 6-bit arithmetic is sufficient to maintain decoding performance. We explored the speed limits of an FPGA Relay-BP implementation in a maximally-parallel computational architecture. Like traditional BP, the Relay-BP algorithm is a message-passing algorithm where messages are exchanged between nodes on a decoding graph. Our maximally parallel implementation assigns a unique compute resource to every node in this graph, allowing a full BP iteration to be computed on every clock cycle. This decoder architecture is resource-intensive, but we succeeded in building a Relay-BP decoder for the gross code and fit it within a single AMD VU19P FPGA. Our implementation is limited to split X/Z decoding of the gross code syndrome cycle (we decode windows of 12 cycles), a simpler implementation than we’d need for Starling. That being said, it is extremely fast, an absolute requirement for practical implementation. In fact, we can execute a Relay-BP iteration in 24ns. As physical error rates drop below 1e-3, Relay-BP typically converges in less than 20 iterations. This means we can complete the decoding task in about 480ns. This is significantly faster than what is possible with NVIDIA’s DGX-Quantum solution, which requires a 4000ns start-up cost before decoding begins. The figure below compares the logical error performance versus physical error rate of our FPGA implementation compared to a floating-point software implementation for memory experiments of the size of Loon and Kookaburra on our Innovation roadmap. This and further data shows that the reduced precision arithmetic in the FPGA matches the accuracy of a software model, while simultaneously running dramatically faster. Further details are in the pre-print: https://lnkd.in/e8CShTmT

𝗖𝗮𝗻 𝗮𝗻 𝗙𝗣𝗚𝗔 𝗶𝗺𝗽𝗿𝗼𝘃𝗲 𝗽𝗼𝘄𝗲𝗿 𝗮𝗺𝗽𝗹𝗶𝗳𝗶𝗲𝗿 𝗲𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗰𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝘁𝗵𝗲 𝗥𝗙 𝗵𝗮𝗿𝗱𝘄𝗮𝗿𝗲? 𝗖𝗿𝗲𝘀𝘁 𝗙𝗮𝗰𝘁𝗼𝗿 𝗥𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 (𝗖𝗙𝗥) is one of the key DSP techniques that makes it possible. Modern 𝗢𝗙𝗗𝗠 waveforms used in 4G, 5G NR and Wi-Fi exhibit a high Peak-to-Average Power Ratio (PAPR) because many subcarriers can add constructively, producing large signal peaks. To avoid nonlinear distortion, power amplifiers must operate with significant output back-off, reducing efficiency and increasing power consumption. Crest Factor Reduction reduces these peaks while introducing only minimal distortion. Several techniques have been proposed, including 𝗣𝗲𝗮𝗸 𝗖𝗹𝗶𝗽𝗽𝗶𝗻𝗴, 𝗣𝗲𝗮𝗸 𝗪𝗶𝗻𝗱𝗼𝘄𝗶𝗻𝗴, 𝗣𝗲𝗮𝗸 𝗖𝗮𝗻𝗰𝗲𝗹𝗹𝗮𝘁𝗶𝗼𝗻, 𝗔𝗰𝘁𝗶𝘃𝗲 𝗖𝗼𝗻𝘀𝘁𝗲𝗹𝗹𝗮𝘁𝗶𝗼𝗻 𝗘𝘅𝘁𝗲𝗻𝘀𝗶𝗼𝗻 (𝗔𝗖𝗘), 𝗧𝗼𝗻𝗲 𝗥𝗲𝘀𝗲𝗿𝘃𝗮𝘁𝗶𝗼𝗻 (𝗧𝗥) 𝗮𝗻𝗱 𝗧𝗼𝗻𝗲 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 (𝗧𝗜). Peak Windowing and Peak Cancellation are especially attractive for FPGA implementations because they provide excellent real-time performance with low hardware cost. In FPGA transmitters, CFR is typically implemented before the DAC to reduce waveform peaks. It is usually combined with 𝗗𝗶𝗴𝗶𝘁𝗮𝗹 𝗣𝗿𝗲𝗱𝗶𝘀𝘁𝗼𝗿𝘁𝗶𝗼𝗻 (𝗗𝗣𝗗), which compensates for power amplifier nonlinearities, allowing the PA to operate with reduced output back-off while maintaining linearity. This 𝗖𝗙𝗥-𝗗𝗣𝗗 combination has become the standard architecture in modern 5G transmitters. CFR is no longer exclusive to FPGA designs. 𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗥𝗙 𝘁𝗿𝗮𝗻𝘀𝗰𝗲𝗶𝘃𝗲𝗿𝘀 such as the Analog Devices ADRV9040 and ADRV9029 integrate dedicated CFR and DPD engines, reducing FPGA workload while improving transmitter efficiency. The attached figure shows a 𝗣𝗲𝗮𝗸 𝗪𝗶𝗻𝗱𝗼𝘄𝗶𝗻𝗴 𝗮𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺 simulated in MathWorks MATLAB. The left side illustrates an FPGA-oriented implementation, while the spectrum compares the transmitted signal with and without CFR. For readers interested in Crest Factor Reduction using FPGA IP Cores, the following references provide practical implementations and algorithms for improving 5G transmitter efficiency. 𝗣𝗲𝗮𝗸 𝗖𝗮𝗻𝗰𝗲𝗹𝗹𝗮𝘁𝗶𝗼𝗻 𝗖𝗿𝗲𝘀𝘁 𝗙𝗮𝗰𝘁𝗼𝗿 𝗥𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗜𝗣 𝗖𝗼𝗿𝗲 – Lattice Semiconductor https://lnkd.in/eJd_6tCk 𝗦𝗶𝗺𝗽𝗹𝗲 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺 𝗳𝗼𝗿 𝗣𝗲𝗮𝗸 𝗪𝗶𝗻𝗱𝗼𝘄𝗶𝗻𝗴 𝗮𝗻𝗱 𝗶𝘁𝘀 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗶𝗻 𝗚𝗦𝗠, 𝗘𝗗𝗚𝗘 𝗮𝗻𝗱 𝗪𝗖𝗗𝗠𝗔 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 – Institution of Engineering and Technology (IET) https://lnkd.in/eE_A-vRi 𝗧𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲𝘀 𝘁𝗼 𝗜𝗺𝗽𝗿𝗼𝘃𝗲 𝗣𝗼𝘄𝗲𝗿 𝗔𝗺𝗽𝗹𝗶𝗳𝗶𝗲𝗿 𝗘𝗻𝗲𝗿𝗴𝘆 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆 𝗳𝗼𝗿 𝟱𝗚 – IEEE https://lnkd.in/e8x3d8nv #FPGA #DSP #5G #OFDM #Wireless

Two years ago I started using AI to design FPGAs. Most people told me to fine-tune a private hardware model. The math said otherwise. 20 years hand-writing VHDL/Verilog for satellite image compression. A year and a half at UCLA's VAST Lab watching CS students treat FPGAs as a software problem. That was the first abstraction lift: RTL to HLS. The next one is here: HLS to AI. You write the architecture. AI writes the Verilog. Three lessons after running this at real scale. ▸ Use frontier public models. Claude Opus 4.6 hits 89.74% on VerilogEval with a lightweight reflection loop. Every base-model upgrade lifts your RTL quality for free. Private fine-tunes buy ~10% gain and need re-training on every version jump. ▸ Three pillars for productization: functional correctness, hardware efficiency, output stability. DSP cascades, BRAM vs SRL, zero bit-growth, truncation not rounding. Miss any one, the rest is wasted. ▸ Three LLM weaknesses will eat you alive: hallucination, forgetting, knowledge gaps. Fight them with structured generation, automated validation, and retrieval. General industry patterns, not domain tricks. Real results on Xilinx UltraScale+ RFSoC: N=1024 Radix-2² FFT at 445 MHz, 1021 LUT. For N=8192 the framework auto-picked a hybrid that hits 28 DSP instead of 52. A 46% saving a human under deadline might have skipped. If you're still hand-writing Verilog in 2026, you are solving the wrong problem at the wrong layer. #FPGA #AIforHardware #HardwareDesign #AIEngineering #Semiconductors

𝗔 𝟭.𝟭-𝗯𝗶𝗹𝗹𝗶𝗼𝗻-𝗽𝗮𝗿𝗮𝗺𝗲𝘁𝗲𝗿 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗺𝗼𝗱𝗲𝗹 — 𝘁𝗵𝗲 𝗸𝗶𝗻𝗱 𝘆𝗼𝘂'𝗱 𝗿𝘂𝗻 𝗼𝗻 𝗮 𝗽𝗵𝗼𝗻𝗲 — 𝘀𝗮𝘁 𝗶𝗻𝘀𝗶𝗱𝗲 𝗮𝗻 𝗙𝗣𝗚𝗔 𝗱𝗲𝘀𝗶𝗴𝗻 𝗳𝗹𝗼𝘄, 𝘄𝗿𝗼𝘁𝗲 𝘁𝗵𝗿𝗲𝗲 𝗵𝗮𝗿𝗱𝘄𝗮𝗿𝗲 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗼𝗿𝘀, 𝗮𝗻𝗱 𝗿𝗮𝗻 𝘁𝗵𝗲𝗺 𝗼𝗻 𝗮 𝗿𝗲𝗮𝗹 𝗯𝗼𝗮𝗿𝗱. A small model, designing the silicon that small models run on. That's not a thought experiment; it's one of four papers that landed on arXiv in a single week. For most of computing's history the arrow ran one way: humans design the chips, the chips run the models. SAINTS Edition 26-24 is about the week the arrow bent back. In the same seven days, a language model 𝗿𝗮𝗻 𝘁𝗵𝗲 𝗻𝗲𝘂𝗿𝗮𝗹-𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 that decides what to compute, a small model 𝗮𝘂𝘁𝗵𝗼𝗿𝗲𝗱 𝘁𝗵𝗲 𝗙𝗣𝗚𝗔 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗼𝗿𝘀 that do the computing, and automated search reached all the way down to the 𝗦𝗥𝗔𝗠 𝗰𝗲𝗹𝗹 𝗮𝗻𝗱 𝘁𝗵𝗲 𝘁𝗿𝗮𝗻𝘀𝗶𝘀𝘁𝗼𝗿 underneath. Architecture, accelerator, circuit — the loop that designs the hardware is starting to close on itself, rung by rung down the stack. But here's the part worth staying for: it closes 𝘂𝗻𝗲𝘃𝗲𝗻𝗹𝘆, and the unevenness is the whole point. 𝗗𝗲𝘀𝗶𝗴𝗻 𝘁𝗵𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 (𝗨𝗛-𝗡𝗔𝗦). Put GPT-4.1 in the driver's seat of a neural-architecture search for optical hardware — let it read the search history and the failure modes and rewrite the strategy each round — and it earns its seat by 𝘦𝘹𝘱𝘭𝘰𝘳𝘪𝘯𝘨: 203 distinct valid designs out of 250 tries, versus 26 without it. Where the problem is messy and physically constrained, a model that can reason about the search beats one that can only sample it. 𝗗𝗲𝘀𝗶𝗴𝗻 𝘁𝗵𝗲 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗼𝗿 (𝗦𝗘𝗖𝗗𝗔-𝗗𝗦𝗘). This is the recursive one. A 1.1B model drives the design of FPGA accelerators and validates each on real silicon. It doesn't take a frontier model to design the hardware; it takes a model the size of the workload the hardware exists to serve. 𝗗𝗲𝘀𝗶𝗴𝗻 𝘁𝗵𝗲 𝗰𝗶𝗿𝗰𝘂𝗶𝘁 (𝗢𝗽𝗲𝗻𝗢𝗽𝘁) — 𝘄𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗱𝗿𝗼𝗽𝘀 𝗼𝘂𝘁. One rung lower, at the SRAM cell, the language model 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. This problem is well-posed, and on a well-posed problem, mature optimization still wins. That absence isn't a gap in the story. It 𝘪𝘴 the story. The models are starting to design the silicon. Just not everywhere — and knowing where is the most useful map the field drew this week. SAINTS 𝘌𝘥𝘪𝘵𝘪𝘰𝘯 26-24 — 𝘵𝘩𝘦 𝘣𝘳𝘪𝘦𝘧𝘪𝘯𝘨 𝘱𝘭𝘶𝘴 𝘵𝘩𝘳𝘦𝘦 𝘥𝘦𝘦𝘱 𝘥𝘪𝘷𝘦𝘴 (𝘥𝘦𝘴𝘪𝘨𝘯 𝘵𝘩𝘦 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 / 𝘵𝘩𝘦 𝘢𝘤𝘤𝘦𝘭𝘦𝘳𝘢𝘵𝘰𝘳 / 𝘵𝘩𝘦 𝘤𝘪𝘳𝘤𝘶𝘪𝘵), 𝘸𝘪𝘵𝘩 𝘢 𝘧𝘢𝘣𝘳𝘪𝘤𝘢𝘵𝘦𝘥 𝘤𝘰𝘮𝘱𝘶𝘵𝘦-𝘪𝘯-𝘮𝘦𝘮𝘰𝘳𝘺 𝘤𝘩𝘪𝘱 𝘢𝘴 𝘵𝘩𝘦 𝘦𝘯𝘥𝘱𝘰𝘪𝘯𝘵, 𝘢𝘳𝘦 𝘭𝘪𝘷𝘦 𝘯𝘰𝘸. Find the link in the comments. #EdgeAI #SmallAI #OnDeviceAI #MachineLearning #SAINTS #AI_Substrate

One follower asked me: “Where are FPGAs actually used today ?” Short answer: Almost everyplace where performance, latency, or determinism matters. FPGA applications in 2026 are much broader than most people think FPGAs are no longer niche devices only for RTL engineers. They are becoming system accelerators for AI, communications, robotics, finance, aerospace, and edge computing. The interesting part: Most people use FPGA-powered systems without realizing it. 1️⃣ Embedded IoT and Edge Systems FPGAs fit well where you need: • low latency • deterministic processing • hardware-level interfaces Typical applications: • industrial automation • smart cameras • edge gateways • medical devices Why FPGA? Because microcontrollers eventually hit performance limits. 2️⃣ AI / ML inference This area exploded recently. FPGAs are used for: • small AI models at the edge • optimized inference pipelines • custom accelerators Especially when: • power matters • latency matters • cloud GPUs are too expensive Typical examples: • robotics vision • object detection • sensor processing • AI-assisted control systems 3️⃣ Robotics Robotics needs: • real-time response • parallel processing • deterministic timing Perfect FPGA territory. Examples: • motor control • SLAM acceleration • image preprocessing • sensor synchronization The robot cannot wait for software jitter. 4️⃣ Financial trading systems One of the most demanding FPGA markets, because nanoseconds matter. FPGAs handle: • ultra-low latency trading • market data processing • packet filtering • hardware acceleration of strategies In this world: lower latency = competitive advantage 5️⃣ Communications and networking This has always been a strong FPGA domain. Examples: • 5G infrastructure • software-defined radio (SDR) • satellite communication FPGAs process massive data streams in real time. 6️⃣ Aerospace and space Space systems rely heavily on FPGAs because they offer: • flexibility • deterministic behavior • hardware acceleration • long lifecycle support Typical use cases: • telemetry • image processing • communication systems • onboard AI inference And yes radiation mitigation become critical here. 7️⃣ Data centers and acceleration Modern FPGA cards accelerate: • networking • storage • AI preprocessing • compression • encryption Not always visible to users, but heavily used behind the scenes. Meme line: Engineer: “Where are FPGAs used?” Reality: “Probably inside the system you used today.” The real takeaway FPGAs win where systems need: • parallelism • low latency • efficiency • deterministic behavior And these requirements are growing, not shrinking. That is why FPGA engineering is still expanding in the AI era. Curious which FPGA application area people here find the most exciting right now: AI? Robotics? Finance? Space? Communications? Something else?

You can design a Linux capable SoC in an FPGA using mostly Python. LiteX is another bright example of the power of open-source. It is a Python based HDL framework created by Florent Kermarrec of Enjoy Digital, that simplifies the development of complex systems in FPGAs. It is designed to be portable and has an extensive list of supported boards from all the major FPGA vendors, and even some of the smaller ones. In fact, it is portable enough that it is also starting to be used with open-source ASIC flows. LiteX leverages Migen to describe digital logic with Python and has a growing library of portable IP that already includes all the pieces needed for a Linux capable SoC. The Linux on LiteX-VexRiscv project demonstrates this and already supports more than 40 different FPGA boards. This powerful tool makes FPGAs accessible for Python developers. #FPGA #opensource #python #LiteX #Linux

Hot off the press our new paper co-authorwd with students and colleagues from Manhattan University, has just been published in IEEE Access. The paper presents a comprehensive overview of FPGA-based CNN accelerators, their architectural innovations, real-world deployments, and optimization techniques. These accelerators are highly applicable for countless edge computing applications including smart surveillance systems, autonomous vehicles, traffic monitoring systems, and drone applications.