FPGA vs ASIC vs SoC: How to Choose the Right Architecture for Your Product

FPGA vs ASIC: the question behind the question

The real question behind FPGA vs ASIC is not which architecture is better, but which one is wrong for your product. An application specific integrated circuit (ASIC) is one of the two dominant families of integrated circuits: more optimised, lower power, but its function is fixed the moment it is fabricated. An FPGA, built from programmable logic, stays changeable after the design process is finished. That trade-off alone does not resolve into a rule you can apply blind, since the right answer depends on volume, product lifetime, and how likely the function is to change after the product ships.

What does resolve is this: an FPGA is the more expensive solution, and it earns its place only where that flexibility is actually required. This article sets out the key differences that decide ASIC vs FPGA in practice, where each architecture loses, and the one case where an FPGA design house tells a customer to buy the chip instead.

Key takeaways

• An ASIC is fixed once fabricated and more power-efficient; an FPGA stays changeable at the hardware level after deployment.
• InTechHouse advises against an FPGA for standardised functions such as an H.264 codec or an HDMI interface, where buying a chip that already does it beats building it in the fabric.
• Some FPGA families stay in production for 20-30 years, longer than any processor's availability window, which makes long-term part purchasability a selection criterion on its own.
• Most current FPGA designs are SoC FPGAs, programmable logic plus one or more processor cores on a single chip, such as AMD/Xilinx Zynq, not standalone fabric.
• Regulated industries add requirements beyond function: code formatting, testability, and repeatable, evidenced verification.

What a field programmable gate array actually is

A field programmable gate array is built from configurable logic blocks and programmable interconnects that you configure into a circuit, not a processor you feed an instruction stream. The programmable logic blocks hold arrays of logic gates; the programmable interconnects wire them together into whatever function the design calls for. In digital system design, the source describes a circuit, not a sequence of instructions, which is exactly why the mental model differs from software, and why fpga implementation feels closer to circuit design than to programming.

That structural difference produces a selection criterion that matters commercially, not only technically: spare resources are deliberately left unused in the fabric during the design process so that hardware-level functions can be added later, without changing the PCB. A processor arrives with a defined set of interfaces and a defined set of functions, and the design process works inside that envelope. Programmable logic removes that boundary: you can add functions nobody had thought of when the board was laid out. These are hardware-level additions, not a firmware update, an important distinction for anyone budgeting a product's second and third revisions.

InTechHouse sees this play out with an aerospace customer and in space applications more broadly, where a board that shipped years ago still needs new capability without a respin.

What an application specific integrated circuit actually is

An application specific integrated circuit is custom silicon commissioned for one product: a specific function committed to dedicated hardware on a single chip, and frozen there. Adam Szychulec, Head of Hardware/Embedded at InTechHouse, calls it "set in silicon," and that phrase is worth keeping in mind for the rest of this article. Once an asic application specific integrated design is fabricated, the circuit is what it is.

The consequence matters more than the fabrication process itself: asic development runs one way. The function cannot be revised after fabrication, and every later change is a new device, a new set of masks, a new run. That is a different commitment from reflashing an FPGA. A custom asic makes sense when a specific function is fixed, proven, and will not need to change for the life of the product, and when volume justifies the custom implementations required to get there.

To be direct about the position this article is written from: InTechHouse does not design ASICs. What follows in this section and the next is a comparison written by an FPGA design house, not a pitch for an ASIC service, and it should be read as exactly that.

When an FPGA design company tells you to buy the chip instead

InTechHouse has told customers not to use an FPGA. That is not a hedge, it is a real recommendation the company makes when the FPGA route is the worse option for a customer's product.

Adam Szychulec gives two concrete cases: an H.264 codec and an HDMI interface. Both are standardised, frozen functions, and for both, a chip that already implements them in dedicated hardware usually beats building the same function in the fabric. The mechanism is what makes the advice checkable rather than a matter of taste: build it on FPGA and you pay twice, once for the device itself and again for an intellectual property core licence, to reproduce something already available off the shelf as silicon, with worse power efficiency and more board area to show for it. When the specific function is standard and the market already sells it, that math rarely favours programmable logic.

"It happens that an FPGA is not the best choice for a project. Take an H.264 codec, or an HDMI interface - sometimes it is better to buy a chip that already does it than to build it in the fabric and licence an IP core."

Adam Szychulec, Head of Hardware / Embedded, InTechHouse

That is one half of the decision. The other half is the reason customers stay on FPGA at all: what they are actually buying is a custom IP core implementing a function that no off the shelf part delivers, or one a processor does inefficiently. InTechHouse has built exactly this kind of custom IP core for an aerospace customer, where no standard chip covered the requirement.

Put the two together and the whole decision compresses into one line: buy the chip when the function is standard and available; build it in programmable logic when it is not.

FPGA and ASIC: the key differences that actually decide it

The key differences between FPGA and ASIC show up cleanly once you stop asking which is better and start asking what each row of a comparison actually costs you.

‍

Read those rows together and the pattern in ASICs and FPGAs is consistent: an ASIC wins on power efficiency and low power consumption because every gate on the die is doing the one job it was built for. An FPGA wins on development cycles: rapid prototyping and iteration happen inside the same design flow, build after build, without waiting on a fabrication run. That is why programmable logic dominates anywhere the specification is still moving.

What the table cannot tell you is which option is cost effective for your product, because that depends on the function itself, not the device class. An ASIC is cheaper per unit once you are committed and building at volume. An FPGA is usually the more expensive solution up front, and it stays that way per unit for as long as the design lives on programmable logic instead of silicon.

ASIC vs FPGA at high volume, and why volume is not the whole question

The standard framing for ASIC vs FPGA is a volume question, and it deserves a fair explanation before it gets undercut. ASIC development carries non recurring engineering costs and a fabrication mask set before a single working part exists, so the decision is conventionally built around production volumes. At high volume production, the lower unit cost of a custom chip recovers that upfront cost structure; at low volumes, or without sufficient volumes to spread the tooling cost across, it does not. That is the reason mass production categories such as consumer electronics default to custom silicon rather than staying on programmable logic, and it is also why an off the shelf microcontroller, not an ASIC and not an FPGA, is the right answer for most simple products.

Volume is the textbook axis, and for the products discussed on this page, it is rarely the deciding one. Telecom, aerospace and oil & gas hardware is built in volumes that would look thin next to a consumer product, yet the architecture decision still has to be made correctly, because a wrong call here shows up as a certification failure or a field return years later, not as a missed unit-cost target. Lifetime, changeability, and whether the function can be bought off the shelf at all decide more of these cases than the unit count does. The next two sections cover exactly those criteria.

Twenty-year availability: the criterion that decides more of these cases than volume

Some FPGA families stay in production far longer than volume alone would predict. AMD/Xilinx's Spartan-3 family was introduced in the early 2000s and is only being withdrawn now. The mechanism behind that longevity is not sentiment, it is demand: these families get designed into military and space programmes, and that demand keeps the part alive for every other buyer on the same production line. Adam Szychulec's comparison is direct: you will not find a processor that stays on the market for twenty years, or that carries any availability declaration at all.

That changes what belongs in a system specification. InTechHouse has seen customers select an FPGA purely for long-term chip availability, in cases where a processor an order of magnitude cheaper, by Adam's own estimate, would have done the same job, including for an oil & gas customer. Both patterns show up in the company's project history: cases where InTechHouse made or influenced that device selection during the design process, and cases where the selection was already made before the project arrived.

That decision has a failure mode InTechHouse gets paid to fix. The rest of the board obsoletes before the FPGA does, the FPGA outlives it anyway, and a mid-life upgrade becomes necessary regardless of the production volumes or low volumes assumed at the original design stage. InTechHouse migrated a legacy Spartan-3 safety design for a public transport supplier onto a supported platform: reverse engineering of the existing design, target platform selection, porting, and verification, with the safety documentation preserved throughout.

What regulated buyers change about the design flow

The two design flows diverge at the level of consequence, not tooling. An asic design flow commits once: verification has to be complete before fabrication, because there is no second chance once the masks are cut. An FPGA design flow keeps development cycles open after the hardware already exists, so a defect found in the field can often be fixed with a new configuration rather than a new board.

Regulated buyers change that comparison by adding requirements that sit alongside the system specification rather than inside it. Adam Szychulec's own phrasing captures it best: beyond the fact that a design has to work, it must be testable, repeatably tested, and written in the prescribed way, in line with the customer's requirements. That covers code formatting rules, testability built in from the start, and verification that produces evidence as part of the design process, not just a passing result.

InTechHouse has delivered FPGA logic under exactly this kind of customer requirement, including safety-integrity (SIL) requirements, on a rail project. Meeting a customer's performance requirements against a documented process is not the same claim as holding a certification, and this article is careful to keep that distinction. The toolchains involved are the usual ones for this kind of work: Vivado, Vitis, Quartus, Lattice Radiant, and Lattice Diamond, with VHDL and Verilog as the hardware description languages and RTL as the deliverable.

Beyond the binary: SoC FPGA, and how the work gets split

"System on chip" has become broad enough to say almost nothing on its own, so this section means one specific thing by fpga vs soc: SoC FPGA, or CPU and FPGA on a single chip. That distinction matters because plain FPGA is no longer the normal choice. Most current devices combine programmable logic with one or more processor cores, sometimes an integrated GPU and fast peripherals, on one piece of silicon. That has been the direction of the market for roughly a decade, and it is what InTechHouse works on day to day.

AMD/Xilinx's Zynq and Zynq UltraScale+ are the family to name here: Cortex-A application cores alongside Cortex-R real-time cores, next to the programmable fabric, on a single chip. InTechHouse has delivered several Zynq-based systems for telecom, aerospace and oil & gas customers, work that spans IP integration on the programmable-logic side and the dedicated hardware around it, and it is where a system specification usually lands once the ASIC vs FPGA vs SOC question gets asked seriously.

The partitioning rule that follows from this is a decision rule, not a feature list. Highly parallel operations on large data volumes, image processing among them, belong on the programmable logic, where the fabric will always be faster than a sequential core. Complicated sequential operations belong in the processor. The counter-example worth remembering is that an FFT, which looks like the obvious fabric candidate, often computes better in the CPU than the textbook answer suggests. In practice, that means operating system and control flow sit on the processor, while parallel data and image processing sit in the fabric.

Structured-ASIC style intermediate paths (loosely, FPGA ASIC hybrids) exist between full-custom silicon and programmable logic.

How to run this decision on your own product

Run the decision in this order against your own system specification, not against a general rule.

1. Is the function standard and already buyable as silicon? Buy it.
2. Does it need to change at the hardware level after the product ships? That points to programmable logic.
3. Does the product need a part that is still purchasable in fifteen years? That points to programmable logic as well.
4. Are the performance requirements parallel and data-heavy, or sequential? That decides how the work splits across a SoC.
5. Only once the first four are answered, look at production volumes.

InTechHouse performs architecture assessments, the CPU vs FPGA vs SoC decision, as a service.

Not sure whether your product needs an ASIC? Request an FPGA architecture assessment.

InTechHouse case study: FPGA mid-life upgrade for a a public transport manufacturer safety system

A a public transport manufacturer was running a safety-related design on a Spartan-3 FPGA that had outlived the rest of the board around it, and needed the function moved onto a supported platform without breaking the safety case. InTechHouse reverse-engineered the existing design, selected the target platform, and ported and verified the logic across the hardware variants in use, keeping the safety documentation intact throughout. The result was a maintainable platform replacing a part that was becoming difficult to source, with the original safety-related behaviour preserved and evidenced.

‍