How Much Does FPGA Development Cost? A Realistic Breakdown from an FPGA Design Company

FPGA cost is two questions wearing one keyword: what a device or a development board costs, and what it costs to have the logic designed. The first has published answers, and the next section gives them with sources. The second, FPGA development cost, depends on scope, and this page explains exactly which parts of scope move the budget.

Key Takeaways

• Board and device prices are public and comparatively small; the engineering around the part is usually the larger line in the total cost.
• Four things drive FPGA development cost: the shape of the job, the verification regime, device selection, and the vendor toolchain.
• For a standard function, buying a chip that already does it can cost less than licensing an IP core and building it in an FPGA.
• FPGA engineers are scarce, and the demand inside most companies is episodic, so a single project rarely justifies a permanent hire.
• InTechHouse scopes FPGA work fixed-price, per project, and does not publish a rate, because the price depends on scope.

FPGA cost: what you are actually asking

If you need a price for a part or a board, the next section answers that and links to where you can check it yourself. If you need a budget for a project, read on past it.

Start with an honest premise. "An FPGA is the more expensive solution, and it is used where it is necessary," says Adam Szychulec, Head of Hardware / Embedded at InTechHouse. A project that does not need programmable logic should not pay for it, and a good supplier will say so before scoping anything.

What follows covers the four drivers that set the budget, one case where the whole project is the wrong shape, the hire-or-contract question, and the commercial model. This page does not publish a price for FPGA engineering. The range depends on the complexity of the work, and any figure printed here without your scope would be a guess.

FPGA boards and development board prices: the hardware question

FPGA pricing at the device level follows what is inside the package. The main factors that affect pricing are the number of logic cells, the amount of embedded SRAM (block memory), high speed transceivers, hard blocks for PCIe and memory interfaces, the package, the speed grade and the temperature grade. Manufacturers split their portfolios into market segments: low cost families for control and glue logic, mid range FPGAs for most industrial work, and high-end families where transceivers, logic density and performance capabilities set the price.

Some reference points, all public:

• A small Lattice iCE40 UltraPlus device (ICE40UP5K-SG48I) lists at $11.23 at quantity one (LCSC, accessed October 2026).
• An entry-level FPGA development board such as the Digilent Basys 3, built on an AMD/Xilinx Artix-7, lists at $165 (Digilent, accessed October 2026).
• A more capable Artix-7 board, the Digilent Arty A7-100T, lists at $314 (Digilent, accessed October 2026).
• An evaluation kit for a high-end SoC, the AMD ZCU102 for Zynq UltraScale+, lists at $3,234 (AMD, accessed October 2026).

Additional features (more peripherals, faster transceivers, larger devices such as the Virtex family) push boards past a thousand dollars and into several thousand dollars. Open source FPGA boards and Terasic boards sit at the low cost end of the market, where most student and hobby users start.

To check current prices yourself, go to distributors such as Digikey and Avnet, or directly to the vendors: AMD/Xilinx, Intel/Altera, Lattice and Microchip. Prices move with supply, so treat any published figure as a dated snapshot.

The point for a product budget: the board is usually the cheapest line in the project. The rest of this article is about the line that is not.

What drives FPGA development cost

FPGA development cost comes down to four drivers. None of them is a rate, and all of them are decided before anyone writes code.

1. The shape of the job: a scoped IP core, or a mid-life upgrade

The first question is what kind of project this is. A custom IP core, or a function implemented on a Zynq-class SoC, is a bounded piece of work: the inputs, outputs and interfaces can be specified up front. InTechHouse built a Precision Time Protocol v2 IP core for an aerospace customer on that basis.

Porting an existing design, or a mid-life upgrade, is a different shape. The original documentation may not exist, so reverse engineering comes first, and that discovery phase is unbounded until the existing design is understood. For a UK rail supplier, InTechHouse migrated a legacy Spartan-3 safety design to a supported platform: reverse engineering, platform selection, porting, and verification across two hardware variants. Knowing which shape you have is worth more to your budget than any published figure. More on the upgrade route in the article on FPGA obsolescence and mid-life upgrade.

2. The verification regime: the line item nobody budgets

The same functionality costs different amounts depending on what the customer requires beyond it working. A regulated buyer typically requires the design to be testable, repeatably tested with evidence, and written to their own code standard.

The contrast is wide in practice. One aerospace customer InTechHouse worked with required nothing special of the code. A rail customer required all of it. Same kind of engineering, very different scope of work.

So answer two questions before you ask anyone for a quote: what evidence will you need at the end of the project, and who has to accept it? A supplier who does not ask this before quoting is about to be wrong. Where verification sits in the flow is covered in the article here.

3. Device selection, and the headroom you pay for twice if you skip it

Adam's working rule holds three constraints at once: a device that is reasonably priced, that meets the requirements, and that leaves headroom for the project to grow.

The headroom clause is the one buyers cut. Buying exactly enough fabric looks efficient until the next feature arrives. Then the design no longer fits, the device has to change, and a different device usually means a different board. That is how a project pays twice. The flexibility argument is covered in [LINK: FPGA vs ASIC vs SoC and FPGA vs microcontroller, and the family decision in Choosing an FPGA vendor and family.

4. The vendor toolchain: time you buy or time you pay for

FPGA design flows look similar across vendors, but names, tools and failure modes differ. Adam is blunt about the tools: they carry real bugs and are in constant development, and what works at one vendor does not at another. He also splits the workflow in two: the logic itself, and how software is loaded onto the device and with which tools.

For a budget, that means vendor-specific experience is time you either buy from a supplier or pay for in your own team's learning curve. Software licensing is a separate line. Vendor tool editions differ in price and in which devices they support; some entry-level boards work with a free edition (AMD's Vivado Standard edition supports the Basys 3, per Digilent, 2026), while larger devices need paid editions. Check the vendor's own licensing page for current terms.

The IP core trap: when licensing costs more than buying a chip

Here is the cost argument that works against an FPGA sale, which is why it belongs early in your decision.

For example, for a standard function such as an H.264 codec or an HDMI interface, buying a chip that already does it often beats building it in an FPGA and licensing an IP core on top. The FPGA route means paying twice: once for the device, and again for the IP licence, to reproduce something already available as dedicated silicon. The result usually draws more power and takes more board area than off-the-shelf components would.

IP licensing is a normal part of FPGA development. The trap is specific: a standard function, available as a standard part, rebuilt in programmable logic because the project already had an FPGA.

A supplier worth hiring costs your problem, not their own scope. The wider comparison between programmable logic, custom silicon and SoCs is in FPGA vs ASIC vs SoC.

Hire an FPGA engineer or contract the project?

The labour market is the cost driver behind this question, and it is structural.

"The main factor is that there are not many of these engineers, and the ones there are tend to be expensive and hard to reach. And if you do find someone, it is hard to set up the collaboration or to hire them, all the more so if you have one project or one function. Hiring someone long-term for that doesn't quite add up, so it is better to find it externally and get it done."

‍

Adam Szychulec, Head of Hardware / Embedded, InTechHouse

Two things make this more than a complaint about hiring. First, demand inside most companies is episodic: one project, one function, a mid-life upgrade once in a decade or two. A permanent hire is the wrong instrument for that, not just an expensive one. Second, the pool of developers does not refill on its own. The entry barrier is high, learning material is thin, and most embedded engineers never move into FPGA engineering, so market demand keeps outrunning supply.

With continuous FPGA work, a team of your own may make sense; with one project, the arithmetic usually points outward. How to evaluate the companies you might contract is covered in How to choose an FPGA design company.

Total cost across the product life, and how we scope the work

The comparison that matters is rarely device price against device price. It is total cost across a product life that may run twenty years. In long-lifecycle industrial and aerospace programs, customers accept a device roughly an order of magnitude dearer than a processor that would do the job (Adam's estimate), because it keeps the product in production and in support for decades. Adam has seen that trade at an oil & gas customer and elsewhere. Reliability, availability and long-term ownership of the product can outweigh the bill of materials. The long view is covered in FPGA vs ASIC vs SoC and FPGA obsolescence and mid-life upgrade.

A buyer asking what it costs is also asking on what basis. Some suppliers work on rate-card or time-and-materials models; InTechHouse scopes FPGA work fixed-price, per project. The price follows the scope: the shape of the job, the verification regime, the device and the toolchain. That is why it is set per project rather than published as a rate, and why the budget balance between those drivers is worth settling first.

InTechHouse case study: costing a mid-life upgrade of a legacy safety design

A UK rail supplier needed a legacy Spartan-3 safety design moved to a platform that is still supported. Because the job was a mid-life upgrade, the work began with reverse engineering of the existing design rather than with a specification. InTechHouse then selected the target platform, ported the logic, and verified the new implementation across two hardware variants of the product. The project shows why job shape drives cost: the discovery phase had to be completed before the rest of the work could be scoped with confidence.

‍