ASIC Design Flow Explained: From RTL to Tapeout Interview Prep

ASIC design flow: what each stage hands to the next, and the interview question it tends to trigger

Frequently asked questions

What are the main stages of the ASIC design flow?

The digital ASIC flow runs from intent to silicon: (1) specification and microarchitecture — define function and the power, performance, and area (PPA) targets; (2) RTL design in Verilog or SystemVerilog (see /topics/rtl-design); (3) functional verification — testbenches, constrained-random and UVM, coverage, assertions, and formal (see /topics/uvm-verification-explained); (4) logic synthesis — map RTL to a gate-level netlist against a standard-cell library under timing constraints (SDC); (5) design-for-test insertion — scan chains and ATPG (see /topics/design-for-test-dft-scan-atpg); (6) physical design (the back end) — floorplan, power plan, placement, clock-tree synthesis, and routing (see /topics/physical-design-backend-flow); (7) signoff — static timing across corners (see /topics/static-timing-analysis-sta), plus DRC, LVS, and power/IR checks; and (8) tapeout — hand the final GDSII to the foundry. The first half is the front end (RTL through synthesis); the second is the back end (physical design through signoff).

What is the difference between front-end and back-end ASIC design?

Front-end design is everything that produces a verified gate-level netlist: architecture, RTL coding, functional verification, and logic synthesis with constraints and DFT. It is technology-aware but not yet placed in silicon. Back-end design (physical design or "place and route") takes that netlist and realizes it on the die: floorplanning, power distribution, cell placement, clock-tree synthesis, routing, and the parasitic extraction that feeds signoff timing. The two halves use different tools, different expertise, and a different cost-of-error profile — a front-end RTL bug is an edit, while a back-end timing or DRC problem found late can cost weeks of iteration. Many candidates own one half; strong ones can explain the handoff (the netlist plus SDC constraints) and why a clean front end makes the back end converge faster.

What does logic synthesis actually do?

Logic synthesis translates RTL into a gate-level netlist of standard cells from the target library, optimizing for the timing, area, and power constraints you give it in an SDC file (clocks, input/output delays, false paths, multicycle paths). It performs technology mapping, timing-driven optimization, and usually scan-chain (DFT) insertion. The output is a netlist plus constraints handed to physical design. A key signoff step that pairs with synthesis is logical equivalence checking (LEC), a formal proof that the gate-level netlist still implements the same function as the RTL — important because synthesis and later optimizations transform the design and you must guarantee they did not change behavior.

What gets "signed off" before tapeout?

Signoff is the set of final checks that must pass before committing to masks. Timing signoff is static timing analysis (see /topics/static-timing-analysis-sta) across all PVT corners and on-chip-variation, confirming every path meets setup and hold. Physical verification is DRC (design rules), LVS (layout matches the schematic/netlist), plus antenna and ERC checks. Power signoff covers IR-drop on the power grid and electromigration. Functional signoff includes logical equivalence between RTL and the final netlist, and DFT/ATPG coverage targets. Only when timing, physical, power, and functional signoff are all clean does the design go to tapeout — because after masks are cut, fixing anything means a respin.

What is tapeout, and why is a respin so expensive?

Tapeout is the moment the final layout (GDSII or OASIS) is handed to the foundry to make photomasks and fabricate wafers. It is the point of no return: a respin — fixing a bug found in silicon and re-fabricating — costs a new or modified mask set (which at advanced nodes runs into millions of dollars) plus months of fab and bring-up time. That economic reality is why pre-silicon verification and signoff are so thorough, and why the flow front-loads so much checking. It also explains the value of DFT and of pre-silicon emulation/FPGA prototyping (see /topics/pre-silicon-vs-post-silicon): catching a bug before tapeout is an edit; catching it after is a respin.

How does the ASIC flow differ from the FPGA flow?

They share the front end — synthesizable RTL, verification, and synthesis — but diverge at the back end and in economics. An ASIC targets a standard-cell library and a foundry process, closes timing against signoff corners, passes DRC/LVS, and ships through a tapeout where changes cost mask spins. An FPGA maps the same RTL onto fixed vendor resources (LUTs, block RAM, DSP slices, hardened transceivers) and produces a bitstream that can be re-flashed in the field — iteration is cheap, so the verification and timing-closure culture is lighter. ASICs win on power, performance, area, and unit cost at volume; FPGAs win on time-to-market and flexibility. The interview signal is whether you can reason about that tradeoff, not just recite the steps.

How do power, performance, and area (PPA) trade off across the flow?

PPA is the optimization target that every stage negotiates. Architecture sets the ceiling — pipelining and parallelism buy performance at an area and power cost. RTL and synthesis trade timing against area and dynamic/leakage power through clock gating, multi-Vt cell selection, and constraint tightening. Physical design trades area (utilization, floorplan) against routability and timing, and clock-tree synthesis trades skew against power. You cannot maximize all three; a real project fixes the binding constraint (often a clock-frequency or power budget) and optimizes the others around it. Strong candidates name the specific lever at each stage rather than treating PPA as a slogan.

Where do verification and DFT fit in the flow?

They are parallel disciplines, not a single late step. Functional verification (see /topics/uvm-verification-explained) runs alongside RTL development to prove the design is functionally correct before synthesis — testbenches, constrained-random stimulus, coverage closure, assertions, and formal property checking. Design-for-test (see /topics/design-for-test-dft-scan-atpg) is about manufacturing test: scan chains inserted at synthesis let ATPG generate vectors that detect fabrication defects, and BIST covers memories. Verification answers "did we build the design right?"; DFT answers "can we tell a good die from a bad one after fab?" Both must be planned early — retrofitting either late in the flow is painful.

What happens after tapeout — is the flow really done at GDSII?

GDSII ends the design flow, but not the product flow. The foundry uses the layout to build photomasks and fabricate wafers; first silicon then returns for post-silicon validation and bring-up (see /topics/pre-silicon-vs-post-silicon) — powering the part up, running it on a bench and in a real system, and characterizing it across voltage, temperature, and frequency. Bugs that escaped pre-silicon verification surface here, and fixing one means an engineering change order (ECO): a small change can sometimes be a metal-only ECO that reuses the base-layer masks and edits just routing plus spare cells, while a deeper logic change forces a full base-layer respin with a new mask set. Test-program development on ATE, yield ramp, and qualification (reliability and burn-in) also live in this post-silicon phase. So tapeout is the point of no return for the design, but bring-up, characterization, test, and qualification still stand between first silicon and volume production.

Why is the ASIC flow iterative rather than a straight line?

The stage list reads linearly, but real projects loop back constantly, and interviewers listen for whether you know where the back-edges are. Functional verification feeds bugs back to RTL until coverage closes. Synthesis and physical design share a timing-closure loop: when placement and routing cannot meet the timing that synthesis assumed, the design iterates — re-synthesize with revised constraints, re-floorplan, or restructure the RTL on critical paths. Late fixes after a netlist is frozen go in as ECOs rather than a full re-run, to limit disruption. Even signoff can bounce the design backward: an IR-drop or electromigration violation sends you back to the power grid, a DRC or LVS failure back to layout. The model to describe is a flow with back-edges — verification to RTL, the synthesis-to-place-and-route timing-closure loop, and ECO loops near the end — all converging on a clean signoff, not a one-way pipeline.

What are the back-end (physical design) steps, in order?

Physical design (the back end, see /topics/physical-design-backend-flow) realizes the synthesized netlist on the die in a defined order: (1) floorplanning — set the die size, place macros and I/O, and define power-domain regions; (2) power planning — build the power and ground grid (rings and straps) that feeds every cell; (3) placement — position the standard cells, optimizing for timing and routability; (4) clock-tree synthesis (CTS) — build a balanced clock distribution that controls skew and insertion delay; (5) routing — connect all signal nets through the metal stack while honoring design rules; and (6) parasitic extraction and signoff — extract RC, then run static timing across corners (see /topics/static-timing-analysis-sta) plus DRC and LVS. The ordering is the tell: CTS comes after placement because it needs cell locations, and before final routing; describing routing before CTS, or CTS before placement, signals no hands-on back-end exposure.

Related topics