The same 5G lower-PHY and digital-front-end function can ship on an FPGA, an SoC, or a full-custom ASIC — and the right choice is a volume-and-lifetime decision long before it is a technical one.
A 5G radio’s lower PHY and digital front end — the channel filtering, the crest-factor reduction and digital pre-distortion, the fronthaul framing — is a fixed piece of signal processing. What changes is the silicon it runs on. An FPGA implements it in reconfigurable logic. An SoC combines that logic with hard processor cores and often hardened radio-specific blocks. An ASIC casts it into fully custom silicon.
All three can meet the same specification. They differ in what they cost to develop, what they cost per unit, how much power they burn, how fast they reach the field, and how easily they change afterwards.
An FPGA has near-zero non-recurring engineering cost and reaches the field fast, and it stays reconfigurable — you can fix or upgrade the PHY after deployment. You pay for that in higher unit cost and higher power. An ASIC is the opposite: large NRE and a long, high-stakes design cycle, in exchange for the lowest unit cost and the lowest power at volume, frozen once taped out.
An SoC sits between them — hard cores and hardened accelerators for the parts that are stable, with reconfigurable logic where flexibility still earns its place. It is often the pragmatic answer for products that need some of an ASIC’s efficiency without surrendering all of an FPGA’s adaptability.
The crossover is economic. ASIC NRE is amortised across units, so the per-unit saving only beats the FPGA once volume is high enough — below that break-even, the FPGA is cheaper overall despite its higher unit price. Power tells a parallel story: at a dense deployment of many radios, the ASIC’s lower power per unit becomes a serious operating-cost argument; at low volume it rarely justifies the NRE.
Product lifetime and standards churn pull the other way. 5G is still evolving; a part that cannot be reconfigured after deployment is a bet that the requirements will not move. Reconfigurability is insurance, and whether it is worth its unit-cost premium depends on how settled the target is.
A common and sensible route is to prove on FPGA, then migrate: field the function on an FPGA or SoC to validate it on real hardware and real traffic, then move the stable parts to an ASIC or a hardened SoC once volume and requirements justify the NRE. The FPGA de-risks the design; the ASIC harvests the volume savings later.
We work across that whole path — lower-PHY and DFE on FPGA or SoC, and the FPGA-to-ASIC migration when the business case closes — so the silicon choice follows the volume, the power budget and the product’s lifetime rather than a default.
Yes. The lower PHY and digital front end are a fixed piece of signal processing that any of the three can implement to the same specification. They differ in development cost, unit cost, power, time-to-field and how easily the design can change afterwards, not in whether they can meet the spec.
When volume is high enough that the per-unit cost and power savings amortise the ASIC's large non-recurring engineering cost, and when the requirements are settled enough to freeze in silicon. Below that break-even, or where the standard is still moving, an FPGA or SoC is usually the better call.
A system-on-chip that combines reconfigurable logic with hard processor cores and often hardened radio-specific accelerators. It sits between FPGA and ASIC: more efficient than a pure FPGA for the stable parts, while keeping reconfigurability where flexibility still matters.
Because 5G is still evolving. A part that cannot be updated after deployment is a bet that requirements will not change. FPGA and SoC logic can be reconfigured in the field; an ASIC cannot, so choosing it is choosing to freeze the design.
Non-recurring engineering cost: the one-time cost of designing and taping out an ASIC. It is large and is amortised across units, so an ASIC only wins on total cost once volume is high enough to spread that NRE below the per-unit saving versus an FPGA.
Field the function on an FPGA or SoC first to validate it on real hardware and traffic and keep it changeable, then move the stable parts to an ASIC or hardened SoC once volume and settled requirements justify the NRE. The FPGA de-risks; the ASIC captures volume savings later.
FPGA, SoC or ASIC for the lower PHY and digital front end — and the migration path between them when the business case closes. Tell us the numbers and we'll tell you where the crossover is.