We need custom hardware for this product. How would you decide between an ASIC and an FPGA?

Short answer

Choose between an ASIC and an FPGA by comparing break-even volume, schedule risk, power, area, and how costly a late bug would be. FPGAs are faster to ship and reprogrammable, while ASICs win at stable high volume when lower unit cost, power, and size justify the upfront NRE and verification burden.

Reduce it to a break-even volume first

The two routes have opposite cost shapes, and the whole commercial argument follows from that. An FPGA is a manufactured part you buy, so the engineering cost of using one is comparatively modest and each unit you ship costs what the part costs. An ASIC has a very large one-off engineering and manufacturing set-up cost, after which each unit is a small piece of silicon that costs far less than an equivalent FPGA. So write the total cost of each route as a straight line and find where they cross.

asic total  =  asic_nre + volume * asic_unit
fpga total  =  fpga_nre + volume * fpga_unit

break-even volume  =  asic_nre - fpga_nre
                      ---------------------
                      fpga_unit - asic_unit

Nothing in that expression requires you to know any real figures, and in an interview it is more useful than a memorised volume threshold, because it makes the sensitivities visible. The break-even point moves with the difference in unit price, not with either price on its own, so a design that would fit in a small inexpensive FPGA has a much higher break-even volume than one needing the largest device in a family. And because the numerator is a fixed cost you must commit before you sell anything, the decision is as much about financing as about engineering: the ASIC is only cheaper if the volume actually materialises, and you spend the money before you find out.

There is a second-order term worth naming aloud. An FPGA's higher unit cost is not confined to the part. A larger, hotter device pushes cost into the board, the power supply and possibly the enclosure, so the true unit difference is wider than the two component prices. Candidates who mention that are usually the ones who have shipped something.

What each route actually gives you

Two rows in that table deserve their reasoning rather than just the verdict, because stating them without it is the most common way this answer sounds rehearsed.

Power and area go the ASIC's way because of what programmability physically costs. An FPGA implements your logic in lookup tables and routes signals through a network of configurable switches, and both the tables and the switches exist in silicon whether your design uses them fully or not. Every connection in your design passes through routing resources that a dedicated wire would not need, and every one of those resources has capacitance to charge. An ASIC spends transistors only on the function you asked for and connects them with wires chosen for that function, so the same logic occupies less area, switches less capacitance and can be clocked harder. This is a structural difference, not a matter of process generation.

The bug row goes the FPGA's way for a reason that dominates schedules. An FPGA is reconfigured by loading a new bitstream, so the cost of being wrong is a rebuild. An ASIC's function is fixed in the physical structure of the die, so a functional defect that escapes verification is corrected by producing new masks and new wafers, and the delay is long enough to miss a product window. This is why the verification effort for an ASIC is frequently the largest single component of its one-off cost, and why an answer that treats verification as a step at the end rather than as most of the project reads as inexperienced.

The decision is rarely a single choice

The routes are usually sequential rather than exclusive. An FPGA implementation is how an ASIC design is validated at speed against real interfaces and real software before anything is committed to manufacture, so the FPGA work happens anyway. That reframes the question from "which one" to "when, if ever, do we move".

flowchart TD
    A[Function needed<br/>in hardware] --> B{Specification<br/>still moving}
    B -- Yes --> C[FPGA and keep<br/>shipping updates]
    B -- No --> D{Volume past<br/>break-even}
    D -- No --> C
    D -- Yes --> E{Power or size<br/>a hard limit}
    E -- Yes --> F[Commit to ASIC]
    E -- No --> G[Stay on FPGA<br/>and revisit]
    C --> B

The edge worth looking at is the loop back from the FPGA branch into the specification question. That is the normal state of a product for years, and the decision to leave the loop is taken once, deliberately, when both the specification and the volume have stopped being guesses.

Two situations override the arithmetic entirely. If the product has a hard power or physical size limit that no available FPGA meets, the ASIC is not the cheaper option, it is the only option, and the break-even calculation is irrelevant. Conversely, if the function must change after units are in customers' hands — because a standard is still being finalised, or because the algorithm improves with data you have not collected yet — the FPGA's reprogrammability is the requirement, and paying more per unit is the price of meeting it.

Where the answer usually goes thin

The weak version of this answer is "high volume, ASIC; low volume, FPGA", which is not wrong and is not an engineering judgement either. What separates a strong answer is treating the specification's stability as a first-class input alongside volume.

The reason is that the two routes fail differently. Being wrong about volume on an FPGA costs you margin on every unit, continuously and visibly, and you can correct it later by starting an ASIC programme. Being wrong about the specification on an ASIC costs you the entire one-off investment and the schedule, and there is no incremental correction available. Those are not comparable risks, and a decision framework that only compares expected costs while ignoring that asymmetry recommends the ASIC too early.

The practical form of this is a question about the organisation rather than the silicon: is the interface this thing must speak defined by a published standard that is already stable, or by a customer who is still discovering what they want? A frozen, externally specified function is a good ASIC candidate at far lower volume than a function still under negotiation, because the thing that ruins ASIC projects is not usually a timing problem but a late change of mind.

What you carry either way

Both routes need the same RTL discipline, the same verification thinking and the same care about timing and clock domain crossings, which is why the skills transfer and why an interviewer can ask this question of either kind of engineer. The differences show up at the edges. An FPGA design leans on vendor-supplied blocks for memories, arithmetic and serial interfaces, and those blocks have no direct equivalent when you move; anything relying on the fabric's specific structure has to be rewritten. An ASIC design brings in a whole set of concerns an FPGA hides from you, including how the part is tested at manufacture, how it powers up, and how much of the die is spent on things that are not your logic.

The volume arithmetic tells you which route is cheaper if everything goes to plan, and the stability of the specification tells you how much you should trust that condition — the second one is what the question is really testing.

© 2026 Preptima. Originally published at preptima.com.