FPGA vs Microcontroller vs ASIC: Which Should You Use?

Detailed Explanation

The choice between an FPGA, a microcontroller, and an ASIC is one of the most consequential platform decisions in an electronics product design. Getting it wrong means either an overpowered, over-complex solution, or a platform that fundamentally cannot meet the application's performance requirements.

The Three Platforms: What Makes Each Unique

Microcontroller (MCU)

A microcontroller is a sequential processor — a CPU core, flash, RAM, and hard peripherals on one chip. It fetches instructions one at a time (or a few with pipelining) and executes them in order. The core strengths are the breadth of hard-IP peripherals (SPI, I2C, UART, ADC, CAN, USB, PWM timers), low unit cost (typically $0.50–$10 for most production MCUs), and a mature software ecosystem (C/C++, RTOS, HAL). For embedded control, state machine firmware, protocol parsing, and sensor acquisition, an MCU is the right tool.

FPGA

An FPGA implements digital circuits as configurable hardware rather than running software on a CPU. The fabric consists of thousands to millions of look-up tables (LUTs) and flip-flops wired by a programmable interconnect — any digital circuit can be described in Verilog or VHDL and mapped to those resources. The core strength is massive parallelism: 1,000 operations can happen in a single clock cycle because they are independent physical circuits, not queued instructions. For a detailed explanation of how FPGAs work internally — LUTs, BRAM, DSP blocks, the design flow — see What Is an FPGA and How Does It Work?.

ASIC

An ASIC (Application-Specific Integrated Circuit) is a custom chip designed for one specific purpose, fabricated by a semiconductor foundry. Unlike an FPGA (which is a general-purpose device configured by the user), an ASIC's logic is fixed at manufacture. The gate network, metal layers, and interconnects are optimised for the specific application, producing the best possible power efficiency and performance at scale. The trade-off is a large upfront NRE cost and a long development timeline — typically 12–24 months from RTL to silicon.

---

Decision Framework: The Right Questions to Ask

Before selecting a platform, work through these questions:

1. Is the algorithm sequential or parallel? If it runs as a series of steps — read sensor, compute PID, drive output — an MCU handles it cleanly. If it processes many channels or streams simultaneously — decode 32 serial signals at once, run a 1,024-point FFT every 10 µs — an FPGA is typically the better fit.
2. What are the data rate requirements? MCUs with DMA can sustain roughly 100–800 Mbps throughput on a single data bus. Custom high-speed digital interfaces (PCIe, 10 GbE, MIPI CSI-2, JESD204B, DisplayPort) exist only as FPGA or ASIC IP.
3. What is the expected production volume? At low volumes (hundreds to tens of thousands of units), ASIC NRE is rarely justified. At high volumes (millions of units), the unit-cost saving over an FPGA may recover the NRE investment.
4. What is the power budget? MCUs in deep sleep draw nA–µA. FPGAs in active operation typically draw tens to hundreds of milliwatts from the core supply. ASICs achieve the best power efficiency per computation because the logic is custom-optimised.
5. Does the hardware need to be reconfigurable post-deployment? MCU firmware can be updated over-the-air. FPGA bitstreams can be reprogrammed in the field. ASIC logic is fixed permanently at manufacture.

---

When to Choose a Microcontroller

MCUs are by far the most common choice in embedded product designs. They are the right platform when:

• The application is fundamentally sequential: sensor acquisition, protocol stack, control loop, display UI.
• The data rates fit within MCU peripheral throughput (SPI at up to typically 50–80 Mbps with DMA, I2C up to 3.4 Mbps Fast Mode Plus, UART up to a few Mbps).
• Standard hard peripherals cover the interface requirements (USB FS/HS, CAN, I2S, SPI, ADC, PWM timers).
• A software-first development workflow is preferred — C/C++, RTOS, debugger, HAL.
• Unit cost, PCB area, and BOM complexity must be minimised.

MCU use case examples:

• Industrial PLC controller: Modbus RTU over RS-485, CAN, 12-bit ADC on 8 channels, PWM outputs → STM32G4
• BLE wearable: sensor acquisition, BLE advertising, deep-sleep duty cycling → nRF52840
• Wi-Fi IoT node: MQTT over TLS, OTA firmware update, cloud telemetry → ESP32-S3

For a structured MCU selection guide covering peripherals, flash/RAM sizing, power, wireless, and toolchain, see How Do You Choose the Right Microcontroller?. For embedded firmware architecture decisions — bare-metal vs RTOS — see Bare-Metal vs RTOS: Which Should You Use?.

---

When to Choose an FPGA

An FPGA becomes the right tool when the MCU cannot meet the application's requirements. The most common triggers are:

Data rates beyond MCU capability

Custom high-speed digital interfaces running at hundreds of Mbps to multiple Gbps — MIPI CSI-2, PCIe Gen 1/2, Gigabit Ethernet, JESD204B ADC interface, DisplayPort — exist only as hard IP in FPGAs or ASICs. An MCU cannot implement these interfaces.

True hardware parallelism

Running a 256-tap FIR filter at 125 MHz effective sampling rate, processing 32 ADC channels simultaneously, or running multiple independent PWM controllers with sub-microsecond deadtime precision: these tasks map onto FPGA hardware naturally and are impossible or impractical in sequential MCU firmware.

Custom timing and protocol control

A timing-critical proprietary protocol with sub-cycle latency requirements that standard MCU peripherals cannot replicate. For example: a custom 100 MHz parallel bus with sub-10-ns setup and hold requirements, or a real-time encoder feedback decoder that must respond within one clock cycle.

ASIC prototyping

FPGAs are the standard vehicle for prototyping ASIC logic. The RTL written in Verilog or VHDL for the FPGA target is typically portable to an ASIC standard-cell target with re-targeting of physical cells and timing constraints. This allows the FPGA prototype to validate logic correctness before committing the full ASIC NRE.

FPGA use case examples:

• SDR receiver processing I/Q samples from an ADC at 100+ MSPS → Lattice ECP5 or Xilinx Artix-7
• Machine vision: real-time image preprocessing (demosaic, histogram, edge detection) on a 4K@30fps stream → Xilinx Zynq-7000 (FPGA fabric for preprocessing, ARM core for higher-level pipeline)
• Multi-axis servo controller with sub-µs PWM update latency → small FPGA running parallel PWM engines and incremental encoder decoders
• High-energy physics data acquisition: 512 simultaneous ADC channels with PCIe streaming → Xilinx Virtex Ultrascale+

FPGA power considerations: FPGA power is significantly higher than MCU active power. A moderately utilised Xilinx Artix-7 at 100 MHz typically draws 100–500 mW from the core supply, depending on logic utilisation — figures confirmed by the Vivado Power Estimator tool. The Lattice iCE40 UltraPlus is the exception at the low end, drawing as little as 3–10 mW in active operation, but it has limited logic resources. Mainstream FPGAs are generally poor choices for battery-powered products where an MCU solution exists.

---

When to Choose an ASIC

An ASIC makes sense when all of the following are true:

• Volume is large enough to amortise NRE: typically 100,000 units and above at minimum for older process nodes; modern node ASICs require far higher volumes to justify the investment.
• Performance or power requirements cannot be met by FPGA: an ASIC's custom silicon typically outperforms an equivalent FPGA by 5–10× in power efficiency and 3–5× in raw speed, because the circuit is custom-optimised rather than mapped to generic LUTs.
• BOM cost must be minimised at scale: the custom ASIC implementing the same function as an FPGA typically occupies far less die area and costs less per unit at volume.
• IP protection is required: FPGA bitstreams can be read back from the device depending on the device's security features. An ASIC's netlist and layout are not recoverable from the silicon by external parties.

ASIC NRE economics:

NRE is the one-time upfront investment: mask sets, physical design, verification, characterisation, and test program development. The following are approximate industry ranges — actual costs vary significantly by foundry, design complexity, IP licensing, design service company, and re-spin risk:

These figures should be treated as order-of-magnitude starting points for planning, not quotes. Get commercial quotes from foundries and design service companies before making financial commitments.

Break-even calculation:

If the unit-cost saving of the ASIC over the equivalent FPGA solution is $U per unit, the ASIC breaks even at NRE ÷ U units. As an illustrative example: if an FPGA solution costs $15 per unit and the equivalent ASIC costs $2 in production (saving $13/unit), with a $500,000 NRE, the break-even is approximately 38,500 units. Below that quantity, the FPGA is cheaper over the product lifetime; above it, the ASIC saves money each unit. Real projects require real cost quotes at each stage — this is a framework, not a formula.

---

Full Platform Comparison

---

Hybrid Approaches

The MCU, FPGA, and ASIC categories are not mutually exclusive.

FPGA + MCU (dual-chip): Many production designs pair an FPGA with a small MCU: the FPGA handles the high-throughput, time-critical hardware functions (ADC data acquisition, custom interface protocol, parallel I/O), while the MCU handles the control plane, host communication, and configuration (writing FPGA registers over SPI, managing USB or Ethernet host protocol). The MCU also handles tasks that require a rich software ecosystem — file systems, display stacks, OTA — that would be complex to implement in HDL.

FPGA SoC (single-chip): Devices such as the AMD/Xilinx Zynq-7000 and Zynq Ultrascale+, and the Intel Cyclone V SoC, embed hard ARM Cortex-A processor cores alongside the FPGA fabric on the same chip. The ARM core runs Linux, RTOS, or bare-metal firmware; the FPGA fabric handles real-time data paths. This architecture eliminates the chip-to-chip communication overhead of a dual-chip design and is common in industrial machine vision (camera → FPGA preprocessing → ARM OpenCV pipeline), software-defined radio (RF → ADC → FPGA baseband → ARM protocol stack), and high-speed test equipment.

FPGA → ASIC migration path: A common product development trajectory is to prototype and validate in FPGA, then migrate to ASIC at volume. The RTL written for the FPGA target is re-synthesised for an ASIC standard-cell library. This approach validates logic correctness before committing full ASIC NRE and allows an FPGA-based product to ship while the ASIC is in development.

---

Design Considerations

• Team skills and learning curve: FPGA development requires Verilog or VHDL, a synthesis and place-and-route toolchain (Vivado, Quartus), and expertise in timing analysis and clock domain management. These are distinct skills from embedded C firmware development — clock domain crossing and metastability are FPGA-specific failure modes that have no direct MCU equivalent. For a practical introduction to writing synthesisable HDL — module structure, always blocks, blocking vs non-blocking assignments, latch avoidance, and test bench simulation — see How Do You Write Verilog and VHDL for an FPGA?. Factor the FPGA learning curve into project timelines.
• FPGA toolchain costs: Xilinx Vivado (now AMD Vitis) and Intel Quartus both offer free tiers for smaller devices. Lattice Diamond and Radiant are free for all supported devices. Paid licences are required for larger FPGAs, partial reconfiguration, and advanced hard-IP (PCIe, high-speed SERDES). For ASIC development, toolchain costs (Cadence, Synopsys) are themselves in the millions of dollars per licence.
• ASIC development timeline: full-custom ASIC development — RTL, verification, synthesis, physical design, timing closure, foundry tape-out, post-silicon bring-up — typically takes 12–24 months for an experienced team, longer for a first project. This timeline must be factored into product planning. FPGA prototypes bridge the gap during ASIC development.
• FPGA board-level signal integrity: FPGAs using SERDES transceivers, DDR memory interfaces, or high-frequency I/O produce signals with sub-nanosecond edge rates. At those speeds, PCB trace impedance, reference-plane continuity, and via stub length directly determine signal integrity. See signal integrity in PCB design for the transmission-line effects, termination strategies, and return-path rules that apply when routing a high-speed FPGA board.
• FPGA configuration and debug methodology: FPGA logic is not debugged with GDB or a serial console. The primary tools are JTAG for bitstream loading and accessing embedded logic analyser IP (Xilinx ILA, Intel Signal Tap). Simulation (ModelSim/Questa, Vivado Simulator, Icarus Verilog) is the primary debug environment — catching logic errors before hardware is critical, as FPGA hardware bring-up without simulation is slow. For the complete toolchain workflow from synthesis through timing closure to bitstream generation, see FPGA Development Flow: From HDL to Working Hardware.
• FPGA configuration volatility: SRAM-based FPGA configuration is lost on power-off. The bitstream must be reloaded from an external SPI flash on every power-up. Configuration time ranges from under 100 ms to several seconds depending on bitstream size and SPI clock. Systems with fast boot requirements (automotive, industrial) must account for this.

For designs requiring both FPGA digital hardware and embedded firmware, Zeus Design's engineering team covers digital design from RTL through to FPGA bring-up, validation, and production integration.

Common Mistakes

• Reaching for FPGA when an MCU would do: FPGA development takes significantly longer than MCU firmware development for the same function. If the task is sequential — read sensor, compute, drive output — benchmark it on a fast MCU first. An STM32H7 at 480 MHz with DMA is faster than most engineers expect at data-path operations. Measure before concluding an MCU is insufficient.
• Underestimating ASIC NRE: engineers who have not worked on ASICs often dramatically underestimate both the cost and the timeline. A low quote from a design house may not include verification, characterisation, test program development, or mask re-spins if silicon is buggy. Budget conservatively and include contingency for multiple silicon iterations.
• Ignoring FPGA power sequencing requirements: FPGAs require multiple supply rails (core, I/O, auxiliary, VCCO per I/O bank, DDR termination for memory interfaces) that must be powered up in a specific sequence. Violating the vendor power-up sequencing requirements causes the FPGA to fail configuration or latch up. This is a common FPGA bring-up failure that is avoidable by following the power supply sequencing guidance in the device datasheet.
• Choosing FPGA too early in the design process: a design that appears to require FPGA parallelism at the requirements stage may be achievable with a high-performance MCU once the algorithm is profiled. Write the algorithm in software first and profile it on target hardware. Move to FPGA only if software benchmarking confirms the MCU cannot meet the throughput or latency requirement.
• Forgetting to plan for bitstream updates in the field: if the product may need FPGA logic updates post-deployment, the system must include a mechanism for receiving and programming a new bitstream — SPI flash update over UART/USB, partial reconfiguration, or a remote update path. Retrofitting this mechanism after hardware is manufactured is expensive. Plan for it in the original PCB design.