FPGA, ASIC or Microcontroller: How to Choose for the Job
The question "what do we build it on" sounds like a matter of taste, but in practice the answer almost always follows from two numbers: how many units you plan to make, and how many operations have to happen at the same time. Three options — a microcontroller, a programmable logic device, and a custom chip — solve the same problem in fundamentally different ways, and the difference between them is not a feature list but what you pay for complexity. The path from a gate to a finished device runs through the Circuit Design page.
Three ways to turn an idea into hardware
- A microcontroller is a finished processor with memory, a clock generator and peripherals in a single package. You write firmware: a sequence of instructions the processor executes one after another. The logic you need is obtained from instructions, not from connections.
- An FPGA is an array of programmable logic elements and flip-flops connected by a programmable network. You describe a circuit out of gates, and after the configuration is loaded it works like any hardware circuit: every branch runs at the same time, and the clock only marks the moments when flip-flops update. Programmability means the same board can be reconfigured for a different job.
- An ASIC is a custom chip designed around your circuit: the transistors, the metal layers and the traces are created from your drawings. Functionally it can do exactly what a board with an FPGA does, but making it costs an entire project including a mask set, and that project cannot be repeated cheaply.
| Property | Microcontroller | FPGA | ASIC |
|---|---|---|---|
| What you write | Firmware in a programming language | A circuit of gates in a hardware description language | A circuit, and then placement and routing |
| One-off cost | Low | Low | Very high: design plus mask set |
| Cost per unit | Low | Noticeable | The lowest at high volume |
| Time to a working sample | Days | Weeks | Months, and the first working part only after verification |
| Parallelism | One instruction stream; concurrency is a feature of the program | Everything you draw, at the same time | Entirely under your control |
| Predictability of time | Counted in cycles if you read the datasheet | Set by the length of a chain of elements, counted by the tool | Calculated before fabrication |
| Changing your mind | Reflash | Reconfigure | A new mask set |
The last row determines everything else. Where a change is free, the decision can be postponed, tested and corrected. Where a change means a new design cycle, a mistake becomes expensive, and the response is to invest in verification up front.
The path to a decision
When a microcontroller wins
Start with a microcontroller, because most of the time it is the right answer. Tasks like "count pulses from a sensor, read a temperature, switch outputs on a schedule, blink a lamp" require nothing beyond a ready-made chip and some firmware. All the support is already inside: program memory, data memory, a clock generator, no external power conversion, nothing to certify. The sleep current of a microcontroller is low enough that a battery lasts for months, and that is the quality that wins projects more often than anything else.
The price of that convenience is sequence. The processor executes instructions one after another, and if a task has to service twenty inputs strictly at once, a single instruction stream stops coping. Then there are three ways out: split the task across several microcontrollers, move up to a faster class of microcontroller, or take an FPGA. The first path is the most underestimated, and it is often the cheapest: two cheap microcontrollers, each with its own job, cost less than one programmable logic device and require no new tooling to learn.
When an FPGA wins
An FPGA answers the task "the logic has to run in parallel and predictably". Where a microcontroller has to guarantee response time by counting cycles and building in margin, an FPGA gives time set by the length of a chain of elements, and the tool counts it during routing. There can be as many parallel branches as you like, and their number is set by you rather than by the length of a program.
The second reason, no less important, is reconfiguration. The same board can start as a test bench, then become a bench with a different configuration, and then the product itself. That changes the economics of the whole project: instead of designing a separate circuit for every option, you rewrite the configuration. That is why FPGAs remain the standard for prototypes and not only for end products.
Two things are paid for this. The first is the price of one unit: the logic array itself costs more than a microcontroller, and at high volume that difference accumulates. The second is lock-in to the vendor's tooling: a finished project transfers to another board with difficulty, because it is tied to the resources and libraries of a specific chip. Both prices are known in advance and have to enter the calculation before the work starts, not after it.
When an ASIC wins
An ASIC makes sense when the production volume pays back the one-off cost and the requirements for power, area or frequency are no longer met on a programmable array. The economics are simple: a custom chip carries a one-off cost that already exceeds the price of the programmable part, and almost nothing beyond that on each further unit, so the larger the run, the earlier the break-even point is reached. The exact crossing depends on the die size and on how much board area it takes, so it is calculated in advance, before the first tape-out.
A significant part of the cost here is not the masks but verification. A custom chip cannot be reconfigured, so an error cannot be fixed after fabrication, and everything goes into not making one in the first place. That is where the work volume comes from, which usually surprises newcomers: modelling, writing checking tests, coverage analysis, design rule checks, comparing the layout with the source description, placement and routing, and only then the mask order. This is why an ASIC schedule is measured in months, and why the first batch arrives noticeably later than the first experimental samples.
Power deserves a separate word, because it is the main argument for a custom chip. A programmable configuration and its overhead logic consume energy even when there is almost no useful work to do, and routing inside the array adds delays that cannot be removed. A dedicated circuit consumes none of that, and at high volume that yields a saving neither an FPGA nor a microcontroller can match.
The mistakes that show up most often
- Starting with an ASIC. The first need to change after fabrication means a new design cycle. If the product is not defined yet, this is the most expensive mistake available.
- Taking an FPGA "with room to grow". An array twice the size you need costs about twice as much and gains almost nothing if the task fits in the smaller one.
- Planning an FPGA as if it were an ASIC. Assuming "we will port it later" does not work: a project written for the resources of a specific chip is hard to port and often has to be rewritten rather than moved.
- Forgetting verification. In an ASIC verification costs more than the masks, and cutting it means paying for a reworked die.
- Underestimating the microcontroller. Tasks that look complicated are often solved by a few pages of firmware, and no programmable logic gives the same result for less money.
- Comparing speed by the number on the box. Frequency, clock cycles and "a million operations per second" mean different things in different classes, and comparing them without knowing what is being counted is meaningless.
What is the difference between an FPGA and a microcontroller?
A microcontroller is a finished processor with memory and peripherals, programmed with firmware: the logic is built from instructions it executes one after another. An FPGA is a programmable array of logic elements and flip-flops, the logic is built from connections between them, and it all runs in parallel rather than in instruction order. That leads to the main difference: response time on a microcontroller is counted in cycles, while on an FPGA it is set by the delay of a chain of elements, and the number of parallel operations on an FPGA is not limited by the length of a program.
When is an ASIC better than an FPGA?
When the number of units is large enough to pay back the one-off cost of the design and the mask set, and when the requirements for power, area or clock rate are no longer met on a programmable array. Note that the cost of an ASIC is not only the masks: a significant part of it is verification, and that is usually what determines the schedule. For single units or experimental batches, an ASIC never makes sense.
When is a microcontroller better than an FPGA?
When the task reduces to sequential control: counting pulses, reading sensors, switching relays, blinking a lamp. The microcontroller already contains all the support, the program takes a day, and nothing else compares on sleep current. Paying for programmable logic only makes sense when many operations must happen at once, or when the response time has to be guaranteed more strictly than the order of instructions allows.
Why does this course build a processor first and move to a board afterwards?
Because that is the cheapest way to make mistakes. In the simulator or on a microcontroller you can build the whole processor, watch it work cycle by cycle, and see exactly where the error is without producing a single circuit board. Once the circuit works and its behaviour is understood, moving it to programmable logic becomes mechanical work instead of debugging hardware. The board also gives access to timing information that a simulator does not have.
Check yourself
Can I take a project that runs on an FPGA and simply move it to an ASIC?
Not move it, but rewrite it, and that is the main trap. A project that uses the resources of a specific chip relies on ready-made memory blocks, multipliers, PLLs and I/O standards, and a custom circuit has none of them. Even if the logic is described portably, the target is reached differently: routing inside the array is short and predictable, while in silicon trace lengths and loads decide whether the circuit closes timing. That is why a port starts by keeping the logic within the portable subset of the language and pushing the physical constraints out, and then re-running verification anyway.
How many units does it take for an ASIC to beat an FPGA?
The calculation is simple: the one-off cost of the ASIC is divided by the difference in unit cost between an FPGA and a custom chip, including package and test. The larger the die, the higher the one-off part and the later the break-even point; the smaller the product, the earlier it arrives. There is no single number: the result depends on the size of the design, on mask prices, and on what exactly you are comparing. It has to be worked out from real quotes before the design starts, because the answer is easy to reverse.
The device has to run off a battery for months. What do I choose?
First work out what actually consumes the energy. If the device sleeps between events, the deciding factor is not the chip family but the sleep current of the chosen part, and there a microcontroller usually wins outright: it already knows how to sleep, wake on an event, and avoid running logic that nobody needs. If the device has to process a data stream continuously, saving power in the logic becomes the main argument and a custom circuit starts to make sense. The general rule is to measure the load profile first and only then pick the class of part.
Why this course runs the order backwards
This course first builds a processor out of gates in the simulator, then runs it on a microcontroller, and only at the very end moves it to programmable logic — to the Tang Nano board. At first glance the order looks odd: if the topic is circuitry, it would make sense to take the board right away. In fact this is the cheapest way to make mistakes.
In a simulator or on a microcontroller you can build the whole processor, watch it work cycle by cycle, and see exactly where the error is without producing a single circuit board. A register shows its value, the clock can be stopped and stepped, and the signals on every cycle can be compared with what was expected. Once the circuit works and its behaviour is understood, moving it to a board becomes mechanical work instead of debugging hardware. More about the board and what it offers is in the Tang Nano guide, about the processor and its architecture in the material on the RISC-V architecture, and about the language for describing circuits in Verilog is not programming.
The simple-to-complex order also works in reverse: someone who has been through the simulator understands why a board is needed at all. And someone who started with a board and got stuck with a circuit that does not work usually cannot tell a logic error from a timing error, because they do not know what is supposed to happen on each clock.