What is an ASIC?
An application-specific integrated circuit is a chip whose logic and physical implementation are created for a defined application or product family. The term covers a broad range: a small controller, a networking device, a sensor interface, a custom system-on-chip or a specialised accelerator. The design may combine standard-cell logic with memory macros, analogue blocks and interfaces. Once fabricated, its logic is generally fixed; changing functionality usually requires a new design revision and another manufacturing run.
ASIC design normally involves specification, RTL, verification, synthesis, physical design, signoff, tape-out, fabrication, packaging and test. This commitment can support tight integration and product-specific optimisation, but creates substantial upfront engineering and manufacturing work. The broader context appears in ASARK’s VLSI overview and ASIC design flow guide.
What is an FPGA?
A field-programmable gate array is a manufactured device containing configurable logic blocks, programmable interconnect, input/output resources and often embedded memory or arithmetic units. A configuration bitstream controls how those resources are connected and behave. Engineers can load a new bitstream to change the implemented circuit, subject to the device’s resources and configuration model.
An FPGA is not an empty chip that becomes arbitrary hardware without limits. Its logic and routing resources are finite, and the programmable fabric has overhead. Still, reconfiguration is valuable when the design is evolving, when one device must support several functions, or when building an early prototype before a custom implementation is justified.
The basic architecture difference
In an ASIC, the final layout contains purpose-built cells and wires for the intended circuit. In an FPGA, general-purpose configurable resources are joined through programmable switches. The FPGA must accommodate many possible circuits, so part of its silicon and signal path supports flexibility rather than only the application’s logic. An ASIC can remove that generality, but only after the design is stable enough to commit.
This distinction influences performance and power, but it does not guarantee a particular result. A carefully selected FPGA can meet a demanding requirement, while a poorly planned ASIC can miss timing or consume more power than expected. The implementation, process, architecture, constraints, packaging and workload matter.
Programmability and flexibility
FPGAs support repeated changes after delivery: a bug fix, protocol update or new feature may be deployed as a new configuration if the product permits it. That can reduce the cost of correcting mistakes and help products respond to changing standards. It also introduces configuration management, bitstream security, compatibility and field-update responsibilities.
ASIC functionality is less flexible after manufacture. Some products include firmware-controlled functions, programmable fuses, microcode or configurable accelerators, but those features operate within the chip’s designed capabilities. A new hardware function outside those capabilities may need a respin. This makes requirements discipline and verification especially important before tape-out.
ASIC vs FPGA comparison
| Dimension | ASIC | FPGA |
|---|---|---|
| Logic after manufacture | Generally fixed to the designed implementation | Can be reconfigured by loading a supported bitstream |
| Architecture | Product-specific cells, memories, wires and interfaces | Configurable logic blocks and programmable routing fabric |
| Performance | Can be optimised for a known data path and target constraints | Often has extra routing and configuration overhead; still capable for many uses |
| Power | May avoid general-purpose fabric overhead for a stable workload | Programmable resources and routing can add switching and static power |
| Initial effort | High: design, verification, physical implementation and manufacturing readiness | Lower path to hardware evaluation; RTL and verification remain important |
| Upfront economics | Includes non-recurring engineering and mask/fabrication commitments | Usually avoids a custom mask set, but device and board costs apply |
| Per-unit economics | Can become attractive at sufficient volume, depending on design and supply costs | Device cost may be higher per unit, offset by flexibility and lower upfront cost |
| Change after release | Limited to designed features, firmware or a new silicon revision | Reconfiguration may add or modify supported hardware functions |
| Time to first hardware | Longer path through design closure and fabrication | Often faster for prototypes when a suitable board and device are available |
| Typical role | Stable, high-volume or tightly optimised product function | Prototype, evolving design, low-volume function or reconfigurable product |
The table describes tendencies, not guarantees. Device families and project conditions differ. “ASIC” can mean a small low-volume design or a complex system-on-chip; FPGAs also span different capacities and power envelopes.
Development cost, NRE and unit cost
Non-recurring engineering (NRE) is spending associated with creating a design rather than repeating each unit. For an ASIC it can include architecture and RTL effort, verification, EDA access, physical implementation, masks, prototype lots and qualification. These items vary greatly with process, complexity, reuse and the intended product. There is no responsible universal price for “an ASIC.”
Unit cost is the recurring cost associated with each produced device and its assembly, test and supply chain. An ASIC’s unit economics may improve as production volume grows, but yield, package, test, die size, capacity commitments and lifecycle all affect the result. FPGA economics include the programmable device, board and possibly a royalty or support arrangement; a higher device cost can still be worthwhile when it avoids a large NRE commitment.
A simplified break-even model compares total programme cost. Let N be units, F fixed development and launch cost, and u recurring cost per unit. Then total cost is approximately F + N × u. This omits schedule risk, financing, support, inventory, redesign and the business value of flexibility. Use project quotes and realistic volumes rather than treating the equation as a purchasing answer.
Production volume is only one input
A high-volume product can justify custom silicon when the function is stable and integration or efficiency has product value. A low-volume instrument may remain on an FPGA for its entire life because updateability, specialised interfaces or long-tail support matter more than unit cost. Aerospace prototyping may use an FPGA to validate a design before a later radiation-tolerant or custom implementation is chosen. Networking hardware may use FPGA logic to support evolving protocols, while mature high-volume functions may move to ASICs. AI accelerators can use either approach depending on workload stability, memory bandwidth, integration and deployment model.
Design effort and verification
Both paths benefit from sound requirements, RTL quality and verification. An FPGA can make hardware experiments accessible, but it does not make verification optional. Engineers still need to test reset behaviour, corner cases, interfaces, clock crossings and performance under realistic conditions. Timing closure must account for the chosen FPGA device and board constraints.
ASIC work adds a longer chain of implementation concerns: technology libraries, synthesis constraints, floorplanning, clocks, routing, power integrity, physical verification and manufacturing test. Functional verification checks intended behaviour; static timing analysis checks timing paths under constraints. Neither replaces the other. See Verilog vs SystemVerilog for language roles and STA fundamentals for timing analysis.
Prototyping ASIC RTL on an FPGA is common in some projects, but it is not a perfect preview. FPGA memories, clocking, interfaces and arithmetic resources differ from an ASIC library; timing and area results do not directly predict the final chip. A prototype can test behaviour and software integration while separate ASIC flows evaluate implementation.
When should you use an ASIC?
Consider an ASIC when the required function is sufficiently stable, product volumes or integration needs support the investment, and the organisation can complete verification, implementation and supply planning. Custom silicon may suit a networking pipeline, a product-specific controller, a custom SoC or a specialised AI accelerator whose workload and interfaces are well understood. Assess lifecycle support and revision risk alongside potential unit economics.
When should you use an FPGA?
Consider an FPGA when requirements are changing, production volume is uncertain, rapid prototyping has high value, the design needs field reconfiguration, or custom-silicon investment is not justified. A development board is a practical way for students to observe real clocked logic, interfaces and constraints. A deployed FPGA product may remain the right answer where flexibility is a feature rather than a temporary bridge.
There is no universally better choice. Some systems combine CPUs, FPGA fabric and custom ASIC components; teams can also begin with an FPGA and later migrate selected stable functions. Decide by comparing requirement stability, engineering capacity, power/performance targets, risk, supply needs and total programme economics.