An FPGA is reconfigurable hardware. Its logic is defined after the chip is manufactured and can be redefined in the field, and that single property is the reason it earns a place in an inference design. While the model or the architecture around it is still moving, the part moves with it, taking a new configuration where a fixed chip would need a new tape-out. The flexibility is paid for in power, in unit cost, and in design time, so reaching for an FPGA is a deliberate bet rather than a default starting point. A team that picks one is buying the option to change its mind after the hardware exists, and that option carries a price on every board shipped.

The bet pays in a few specific cases, and naming them honestly is the first step. One is a network that has not settled and may change after the product ships, so the datapath has to stay editable in the field. A second is a design that takes in parallel, high-rate data, several camera lanes or a wide sensor array, faster than a sequential processor can read it. A third is a production volume too low to repay the non-recurring cost of a custom chip, where the FPGA is the cheapest route to hardware at all. Step away from those cases and a processor with an NPU, or a fixed accelerator, does the same job at lower power and lower cost.

An FPGA buys time more than throughput.

When the architecture has not settled

The clearest reason to take on an FPGA is uncertainty about the algorithm. Understanding why a team reaches for an FPGA before the architecture settles comes down to the cost of being wrong in fixed silicon. If a model changes after an ASIC is committed, the chip is scrap and the schedule is gone; an FPGA takes a fresh bitstream and keeps moving. On a product whose algorithm is still in flux, or one chasing a standard that has not been ratified, the freedom to redefine the datapath after the board is built is the thing being paid for.

That freedom has an expiry date. Once the design freezes and the volume climbs, the same flexibility turns into dead weight, drawing power and costing money for a reconfiguration that never comes. Teams that use FPGAs well treat the part as a stage rather than a destination, and they plan the move to a cheaper fixed part once the architecture has stopped changing. The skill is in seeing the freeze coming and timing the switch.

Fabric with a processor beside it

A good number of inference designs need both a processor and custom logic, and an SoC FPGA puts the two on one die. The processor runs the application and the housekeeping; the fabric takes the parallel or timing-critical work that would stall a CPU. Keeping them on one part avoids a chip-to-chip link, lets the halves share memory, and keeps the latency between them low enough for a tight vision or control loop.

XC7Z020 as a Zynq part that pairs Arm cores with fabric for inference is the common shape of that idea. The Arm cores boot an operating system and run the parts of the pipeline that suit software, while the programmable logic handles the pre-processing, the windowing, or the one layer that has to run in lockstep with an incoming stream. The split is the whole design problem. Work that is regular, parallel, and bandwidth-bound belongs in the fabric; work that is irregular or control-heavy belongs on the cores; and drawing that line wrong wastes either silicon or developer months. The two sides talk over an on-chip bus and a shared memory controller, so how data crosses between them, and how often, tends to set the delivered throughput more than the size of the logic does. A design that streams pixels through the fabric and hands compact features to the cores flies; one that bounces large buffers back and forth chokes on its own interconnect. Development is the other half of the cost. Building the fabric side means high-level synthesis or hand-written RTL, a flow few embedded teams keep staffed full time, and bringing up an SoC FPGA runs longer than a microcontroller or an application processor by a wide margin. The part rewards a design that genuinely needs both halves and penalises one that chose it for headroom, which is why the honest question is whether the fabric does paying work on the first day or merely sits there as insurance.

For a design that has settled on both a processor and a fixed block of custom logic, this class of part is often the cleanest single-chip answer, and it keeps the door open to revising the logic later.

Plain fabric for a small network

When a design needs reconfigurable logic but not a hardened processor, plain fabric is lighter and cheaper to carry. XC7A35T accelerating a small network on Artix fabric fits the case where a modest model, or one stage of a larger pipeline, runs beside a separate host that handles everything else. The fabric does the regular multiply-accumulate work at the width and parallelism the network calls for, and nothing more.

The trade against an SoC part is integration. There is now a host somewhere else on the board and a link to design between it and the fabric, with the timing and the protocol that implies. In return the part costs less and draws less than one carrying a processor it never uses, which suits a design whose software already lives happily on a chip it is committed to. The decision is whether the saved cost and power pay for the extra board-level work.

When power is the constraint

At the low-power end the fabric is small and the job is narrow, and the figure that governs the choice is what the part draws while it holds a simple function continuously. Here an FPGA stops being a compute engine and becomes glue logic with a little intelligence: a slice of reconfigurable hardware sitting in front of a sensor, doing the work that would otherwise wake a much larger chip.

iCE40UP5K for ultra-low-power edge vision preprocessing is built for that role. It runs an always-on preprocessing stage, motion gating or a first-pass filter on a low-resolution stream, at a power low enough that the main processor stays asleep until the small part decides there is something to wake it for. The energy saved upstream, across every hour the device spends watching nothing happen, is the entire argument, and the fabric is sized to that narrow job rather than to peak throughput.

CrossLink-NX handling parallel image sensor data stands next to it with a different strength: moving and reformatting the parallel, high-rate output of an image sensor, often bridging MIPI lanes into whatever the downstream processor expects to see. It earns its place when the bottleneck is getting pixels off the sensor cleanly and into the system, not running a model on them once they arrive.

Both parts make the same case in the end. A small, low-power fabric placed at the right point removes work from a larger chip, and the whole system draws less power for having it there.

What the FPGA needs around it

An FPGA holds no logic once the power is off; it loads its bitstream at every boot. That makes the configuration memory a part of the design rather than an accessory bolted on at the end. XC17256EPCG20C as configuration memory for an FPGA design holds the bitstream that brings the fabric up, and its size and read speed set how long the part takes to become useful after power-on, which matters on a device that wakes and sleeps to save energy. Leaving it out of the early plan is a well-worn way to arrive at a board that powers up to nothing and a schedule that loses a week finding out why.

From prototype to volume

An FPGA is often the right part for the first thousand units and the wrong one for the next hundred thousand. Early on, the freedom to reflash the logic as the algorithm matures is exactly what the project needs, and the higher unit cost barely registers against the value of shipping at all. As the design settles and the numbers grow, that same cost starts to dominate, and the unused flexibility becomes a line item with no return.

The teams that handle this well design the move in from the start. They keep the parts of the system that may change inside the fabric and the parts that have settled in fixed logic or software, so that when the time comes to migrate to a cheaper part or a custom chip, the boundary is already drawn. Treating the FPGA as a permanent home, with no exit planned, is how a product ends up paying for reconfigurability it stopped using years ago.

The migration off an FPGA is rarely free, and it belongs in the calculation from the outset. Moving a proven design onto a fixed accelerator or a custom chip means re-verifying the logic in a new target, and that effort has to be budgeted against the per-unit saving it unlocks. The teams that come out ahead are the ones that counted both the running cost of staying on programmable logic and the one-time cost of leaving it, and that drew the boundary between the changeable and the settled parts of the design early enough to make the eventual move a port rather than a fresh start.

What decides it

The first question is whether the design genuinely needs reconfigurable hardware, or whether it reached for an FPGA out of habit. A fixed accelerator or an NPU does a settled job at lower power and lower cost, and inference jobs tend to be settled by the time they reach volume.

The flexibility carries a running cost, not only a design cost. An FPGA draws more than a fixed part doing the same work, and that gap appears on every unit for the life of the product, so the option to reconfigure has to earn its price on hardware that may never be reconfigured at all.

Tools and IP weigh as heavily as the silicon. The fabric is only as useful as the team's ability to build for it, and a design that leans on synthesis nobody on staff can maintain is a risk wearing the costume of a feature.

Supply runs long here, which cuts both ways. These parts tend to hold long lifecycles, a genuine advantage for a product that ships for years, while they also tie the design to one vendor's toolchain and licensing for that whole span. The part that fits is the one whose flexibility the design will put to use; bought for a real need it is hard to replace, and bought for comfort it is a tax collected on every board.