GPU Tsunami and FPGAs: AI Compute Programmable Fabric
Why the control plane around AI compute may be a larger market than merchant FPGA units suggest
One of our favorite things to do at vendor events or broader trade shows is get up close and personal with compute trays and inspect the semiconductor content and adjacencies that show up across different boards. We know this labels us as geeks. We prefer technologists at heart, and we are ok with either label. There is much to learn in this process. Tracking whose names show up, how much content is present, and which functions are being added can signal trends we are watching for. This exercise led us to our report on power semis, and now to a vastly misunderstood and perhaps under appreciated bit of silicon called FPGAs.
We have followed Lattice Semiconductor for some time, spoken with management regularly, and attended numerous customer and developer events. The company had been outlining a datacenter opportunity, and the story was plausible yet unproven. Then we started seeing Lattice on AI accelerator boards, networking boards, and AI CPU boards. You get the point. Lattice has talked about FPGA ratios growing to multiples on compute boards, and observationally we can see it happening. The interesting part is why, and what increasing programmable content tells us about AI infrastructure design.
The rack has become one brain
We think this is well known and obvious, but modern day AI compute requires rack-scale architecture. The full AI compute rack system connects through a common fabric and functions as one brain.
As rack density increases, control work rises around the main processors and lets them focus on their core job. More variables have to be managed, monitored, or secured, which increases semiconductor attach per rack. The GPU tsunami is also pulling more FPGAs into the AI rack system.
All compute boards have a BMC (baseboard management controller) which is a dedicated processor that monitors and manages a server independently of the main CPU and operating system. While crucial, its I/O is fixed. A more complex board creates signals and interfaces the BMC may not cover cleanly. A small FPGA can sit beside it as a companion and handle a wider range of work. The BMC relationship with an FPGA is why we so often see an ASPEED processor (BMC) in close proximity to a Lattice FPGA.
We have spent time in years past trying to explain why FPGAs are so valuable. Engineers understand the value proposition. The broader market has a harder time seeing it because an FPGA looks like a blank slate to a degree. We think it is helpful to frame FPGAs as silicon that enables flexible specialization. Its programmable fabric becomes specific in its job once the customer designs it into a board. That flexibility has real value as AI infrastructure becomes more customized.
Understanding the rack as a compute system requires viewing it as planes in which silicon has specific roles. Accelerators and CPUs form the compute plane. Networking provides the fabric that lets the rack operate as one system. Power and cooling keep it within operating limits. The control plane sits across all of it, sequencing power, configuring boards and interfaces, monitoring system state, enforcing security policy, and isolating failures.
As AI infrastructure becomes more purpose-built, that control work becomes specific to each system. Programmable fabric makes those design variations practical while the architecture is still changing. The deeper this co-design goes, the stronger the need for flexible specialization.
Source: Creative Strategies analysis of public rack documentation, OCP specifications, company technical materials, and primary research.
Counting packages misses the point
That creates a value-capture problem. FPGA units and ASPs measure how much standalone silicon was sold, while our thesis follows programmable control content across the rack. Today, both are rising as more boards and control work increase FPGA attach. Some functions could eventually move inside combined devices, which would leave a chip count missing programmable content and the firmware that makes it reliable. We have not seen evidence that integration is reducing attach, so we treat it as a downside risk rather than the base case.
We created Programmable Infrastructure Content, or PIC, to measure programmable control wherever it sits. The model counts each function once and includes firmware only where a supplier can charge for it. PIC per rack, megawatt, or gigawatt lets us compare deployments of different sizes without losing the system-level view.
Our view today is that AI infrastructure is creating more places for programmable logic across the board and rack. Liquid cooling, 800 VDC, and more optical content should add new control work. Faster product cycles and greater customization favor a device that can solve a specific control problem without forcing a larger system redesign. The board-level evidence is still developing, which is why the full report builds the case from the architecture up and tests how far FPGA content can rise.
Inside the Full Report
The PIC model from individual control domains through rack, megawatt, and gigawatt values
A disaggregation sensitivity that tests new board boundaries against BMC, SMC, and eFPGA consolidation
Lattice’s verified server attach history and the mechanism behind the increase
A use-case map showing how flexible logic becomes specialized control on each board
A TCO bridge from faster design cycles and lower board-support burden to rack manageability
A four-layer software map separating design tools from board firmware and rack orchestration
A role-based market map covering established FPGA leaders, specialist challengers, Chinese suppliers, and fixed-function substitutes
A downside and monitoring framework with thresholds that can confirm or break the thesis