FPGA-to-ASIC migration: the lessons we keep relearning

A working FPGA prototype is a great morale boost. It is also a poor predictor of ASIC success. We have shipped twelve customer ASICs that started life as Xilinx or Intel FPGA designs, and the same five categories of problem show up almost every time. None of them are exotic. All of them are easy to miss if your team has not lived through a tape-out.

The first is clock-domain crossing hygiene. FPGA fabric is forgiving — synchroniser FFs are cheap, glitch energy is bounded by the routing track, and the Vivado timing engine will warn you about most cross-domain paths. On a 22 nm ASIC, the same RTL becomes a metastability hazard. We now require an explicit CDC report from a structural tool (we use SpyGlass CDC) before any RTL freezes for ASIC sign-off — even if the FPGA build has been clean for months.

The second is reset strategy. Many FPGA designs use a global synchronous reset wired everywhere. On ASIC, that reset tree becomes a routing nightmare and a power-up race. The fix is a structured async-reset / sync-deassert pattern with a documented reset domain hierarchy, ideally generated rather than hand-written.

The other three: memory inference (LUTRAM does not exist on ASIC; explicit memory wrappers and a memory compiler from day one), DFT readiness (scan insertion, MBIST, and at-speed BIST coverage targets cannot be retrofitted in week 38), and analog interface assumptions (the FPGA transceiver and PLL hide a lot of analog complexity that becomes your problem on ASIC).

Our standard FPGA-to-ASIC engagement now opens with a one-week structural audit before any porting work begins. It typically catches 60-80% of the issues that would otherwise surface during sign-off, when fixing them is ten times more expensive.