Typical VLSI Design Flow

Chapter 2 · Page 1.2 · Foundations

1. The Engineering Problem

It is Tuesday morning. The product team has handed you a one-page document: "We need a chip that decodes H.265 4K video at 60 fps, fits in a 12 mm² die, draws under 800 mW, and ships in 14 months." That document is the entire description of what you have to build. Everything else — the architecture, the RTL, the simulator, the synthesis tool, the layout, the silicon — is what you have to produce between Tuesday and tape-out fourteen months from now.

If you and the team improvise, you ship six months late and over budget by a factor of three. If you skip any stage, the design will fail in silicon and you will burn through a $30 million mask set before discovering the bug. The economic reality of VLSI is that every chip team needs a discipline that converts a one-page spec into a manufactured die — and that discipline is the design flow.

The flow is not a suggestion or a project-management artefact. It is the sequence of engineering transforms refined over forty years of silicon design across thousands of taped-out chips, and every stage exists because something will go wrong if you skip it. Understanding the flow — what each stage produces, what failure modes it catches, what the next stage expects — is the foundational skill of every chip engineer regardless of whether they write RTL, run synthesis, close timing, or sign off physical design.

2. Why a Flow Exists

A modern SoC carries 10–50 billion transistors. The functional verification space of even a small block is astronomically large; the timing closure space across a million paths is too large to explore by hand; the manufacturing process imposes constraints (yield, defect density, mask cost) that have nothing to do with the design's logical correctness. No single engineer, no single tool, and no single stage can address all of these simultaneously. So the industry decomposes the problem.

The VLSI flow exists because three forces converge:

1. Abstraction layering. A 14 nm SRAM macro and a UART transmit FIFO live at completely different abstractions; the flow lets each engineering team work at the layer where their judgement is sharpest. The architect reasons in performance counters; the RTL designer reasons in registers + combinational logic; the synthesis engineer reasons in gates + timing; the physical-design engineer reasons in cells + nets + routing tracks. Each layer hands off a clean artefact to the next.
2. Verification firewalls. Every stage has its own failure mode and its own verification. RTL simulation catches functional bugs before you synthesise; STA catches timing bugs before you place-and-route; sign-off DRC catches manufacturing bugs before you tape out. A bug caught at stage N is roughly 10× cheaper than the same bug caught at stage N+1.
3. Economic reality. A first-silicon mask set costs $5M–$50M depending on process node. A re-spin (second mask set after first silicon fails) doubles the cost and adds 4–6 months to the product schedule. The flow exists to drive that re-spin probability toward zero — the discipline pays for itself the first time it prevents one re-spin.

The trade-off — long calendar time, large team headcount, expensive tools — is the price of catching bugs cheaply and shipping silicon that works.

3. Mental Model

The working test for any project decision: which stage am I in, what is this stage's input artefact, and what is this stage supposed to produce? If you cannot answer the third question precisely, the stage is not done. If you cannot answer the second, you've started the wrong stage. If you cannot answer the first, the project does not yet know what it is doing.

4. The Flow at a Glance

The full path from product spec to silicon is between 12 and 18 stages depending on how you count. The compressed version — eight major phases that every working engineer holds in their head — is the map for the rest of this page.

The eight phases, in calendar order:

1. Specification — what the chip must do.
2. Architecture — block-level decomposition and performance budgeting.
3. RTL Design — Verilog implementation of the architecture.
4. Functional Verification — simulation, lint, CDC, coverage closure.
5. Synthesis — RTL to gate-level netlist.
6. Static Timing Analysis — every path meets setup and hold across PVT corners.
7. Physical Design — floorplan, place, CTS, route.
8. Sign-Off & Tape-Out — DRC, LVS, GLS, power, last STA, masks generated.

After tape-out, silicon comes back from the foundry 8–12 weeks later and the team enters bring-up — the post-silicon phase that validates first silicon meets the spec.

5. Front-End — Specification, Architecture, RTL

The front-end is where engineers decide what to build and capture that decision in Verilog. Three sub-stages:

5.1 Stage 1 — Product specification

The single canonical document the entire flow descends from. A product spec for a chip is rarely longer than 10–20 pages but covers:

• Functional requirements — what the chip must do (decode H.265, encrypt AES-256, run a RISC-V core at 1.2 GHz, etc.).
• Performance targets — throughput, latency, frequency, IPC if it's a CPU.
• Power envelope — TDP, leakage budget, sleep-state targets.
• Area / cost targets — die size, process node, package.
• Interfaces — PCIe Gen5, DDR5, USB4, HDMI 2.1, whatever the chip talks to.
• Compliance & safety — automotive (ISO 26262), medical, security cert requirements.
• Schedule — tape-out date, first-silicon date, mass production date.

Owner: product management + architecture team. Output: the spec document. Sign-off gate: spec review with engineering, marketing, and (for safety-critical chips) external auditors.

5.2 Stage 2 — Architecture

The translation from "what" to "how at the block level." Architecture engineers decompose the spec into blocks (decoder, memory controller, NoC, peripheral, etc.) and assign each block a performance / power / area budget. The architecture also picks the microarchitecture of each block — pipelining depth, cache hierarchy, branch prediction strategy, FIFO depths, bus widths.

The architecture artefacts:

• Block diagram — every IP block, every interface, every clock domain.
• Performance model — cycle-accurate or transaction-level simulation in C++ or SystemC. Used to validate that the architecture can hit the spec's performance numbers before any RTL is written.
• Performance / power / area budget table — every block has a line: "X mm² area, Y mW power, Z cycles latency."
• Interface protocols — chosen from standard families (AXI4, AHB-Lite, custom NoCs) and documented for the RTL teams.

Owner: architecture team. Output: architecture specification document + performance model. Sign-off gate: architecture review with RTL, DV, and physical-design leads. Calendar time: 2–4 months.

5.3 Stage 3 — RTL design in Verilog

This is where Verilog enters the flow. RTL designers translate each architectural block into synthesisable Verilog modules — the three RTL idioms from Chapter 1 §4: clocked registers, combinational next-state logic, output logic.

`default_nettype none
 
module load_counter #(
    parameter WIDTH = 8
) (
    input  wire              clk,
    input  wire              rst_n,
    input  wire              load,
    input  wire [WIDTH-1:0]  load_value,
    output reg  [WIDTH-1:0]  count_q
);
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n)     count_q <= {WIDTH{1'b0}};
        else if (load)  count_q <= load_value;
        else            count_q <= count_q + 1'b1;
    end
endmodule

The RTL must be synthesisable — no initial blocks, no #delays, no system tasks in the synthesis hierarchy. Testbenches live in separate files. Every register has a defined reset path. Every signal name follows the project convention.

Owner: RTL design team. Output: Verilog source tree + design constraints (SDC). Sign-off gate: RTL freeze — no more functional changes accepted; only bug fixes from this point. Calendar time: 4–8 months.

6. Front-End — Verification (Simulation, Lint, CDC, Coverage)

RTL without verification is a draft. The verification stage runs in parallel with RTL and validates that the design matches the spec.

6.1 Functional simulation

The DV (design-verification) team writes testbenches — typically in SystemVerilog with the UVM methodology for complex blocks, in plain Verilog for simple ones — that exercise the RTL with constrained-random stimulus and check responses with reference models / assertions. A typical SoC's regression suite runs thousands of tests across hundreds of CPU-hours every night.

Simulator choice: VCS (Synopsys), Xcelium (Cadence), Questa (Siemens) for ASIC sign-off; Verilator for fast nightly runs; Vivado XSim / ModelSim for FPGA.

6.2 Lint, CDC, reset, X-propagation checks

Structural checks that run on RTL source without simulating:

• Lint — coding-style violations, simulation-vs-synthesis mismatches, unused signals, multi-driver nets. Tools: SpyGlass, Verissimo, Verilator's --lint-only.
• CDC (clock-domain crossing) — every signal that crosses from clock domain A to clock domain B must go through a synchroniser (2-flop sync, handshake, async FIFO). CDC tools flag missing synchronisers. Tools: Real Intent Meridian, Synopsys SpyGlass CDC.
• Reset analysis — every reg has a defined reset path; no reset signal crosses domains without synchronisation.
• X-propagation (XPROP) — checks for X states leaking through downstream logic in unintended ways.

6.3 Coverage closure

Functional coverage measures which design behaviours have actually been exercised by the regression. Code coverage measures which lines / branches / FSM states have been hit. Both must reach project-defined targets (typically 95–99%) before the verification team signs off the block.

Owner: DV team. Output: passing regression + coverage report + assertion sign-off. Sign-off gate: functional sign-off — block is ready to enter synthesis. Calendar time: runs in parallel with RTL design; coverage closure typically extends 1–3 months past RTL freeze.

7. Mid-Flow — Synthesis

The synthesis tool reads the synthesisable subset of the Verilog RTL plus the SDC (Synopsys Design Constraints) file and produces a gate-level netlist — a structural Verilog file consisting only of standard-cell instances and wires between them.

7.1 What synthesis does

1. Elaboration — flattens parameter bindings, resolves generate blocks, expands hierarchical references.
2. Translation — maps language constructs to a generic gate-level intermediate (technology-independent).
3. Technology mapping — replaces generic gates with library-specific standard cells (AND2X1, DFFRX1, MUX4X2, etc.) from the foundry's .lib (Liberty timing model).
4. Optimisation — sizing cells, restructuring combinational logic, retiming registers, inserting clock-gating to reduce dynamic power.

# Read the design and constraints
read_verilog [glob rtl/*.v]
current_design top_chip
link
 
# Load the standard-cell library for the target process
set_app_var target_library "tsmc_n7_stdcell.db"
set_app_var link_library   "* tsmc_n7_stdcell.db"
 
# Read timing constraints (clock period, IO delays, false paths)
read_sdc constraints/top_chip.sdc
 
# Synthesise
compile_ultra -gate_clock -retime
 
# Write outputs
write -format verilog -hierarchy -output gate-level/top_chip.v
write_sdc gate-level/top_chip.sdc
report_timing -path full -delay max -max_paths 50 > reports/timing.rpt
report_area > reports/area.rpt
report_power > reports/power.rpt

7.2 What the synthesis tool produces

Owner: synthesis / implementation team. Output: gate-level netlist + reports. Sign-off gate: synthesis timing closure — every path meets setup at the target frequency (typically with 5–10% margin). Calendar time: weeks per major synthesis run; full chip synthesis can take days of CPU time.

8. Mid-Flow — Static Timing Analysis (STA)

STA is the exhaustive timing check that runs on the post-synthesis (and later post-route) netlist. Where simulation samples a few thousand test scenarios, STA mathematically proves that every path in the design — every register-to-register, every input-to-register, every register-to-output, every combinational path — meets the setup and hold timing constraints across every PVT corner.

8.1 The setup / hold model

For each register-to-register path, STA computes:

• Data arrival time — clock-to-Q delay of the launch flop + combinational logic delay through the path.
• Data required time — clock period − setup time of the capture flop − clock skew.
• Slack = required − arrival. Positive slack = passing; negative slack = timing violation.

The same calculation runs for hold: data must remain stable after the capture edge until the hold window closes.

8.2 What STA reports

STA runs across multiple PVT (Process / Voltage / Temperature) corners — typically slow-slow-cold (worst setup), fast-fast-hot (worst hold), and several in between. A "clean STA" report means zero negative slack on every endpoint across every corner.

Owner: STA / timing closure team. Output: timing reports, ECO suggestions. Sign-off gate: clean STA at target frequency across PVT corners. Calendar time: weeks to months of iteration with the synthesis / PD teams.

9. Back-End — Physical Design

Physical design (PD) takes the gate-level netlist and turns it into a layout — a 2D placement of every cell, every wire, every via, on the actual silicon area. The PD flow has four major sub-stages:

After routing, the layout has actual wire lengths and via counts; parasitics can be extracted accurately. Timing is re-analysed (this is post-route STA), and any newly-introduced violations get fixed via engineering change orders (ECOs).

Owner: physical-design team. Tools: Cadence Innovus, Synopsys ICC2, Siemens Aprisa. Output: placed and routed layout in OpenAccess / DEF / GDSII format. Calendar time: 2–6 months for a typical SoC block; longer for full-chip integration. Sign-off gate: post-route STA clean + DRC / LVS clean (see §10).

10. Sign-Off — DRC, LVS, GLS, Power, Final Timing

Sign-off is the last-line verification before tape-out. Every sign-off check is exhaustive (not statistical) and gates the chip's exit from the design flow into manufacturing.

Every check must pass before tape-out. A single DRC violation on a single metal layer is enough to send the design back into PD for an ECO.

Owner: sign-off / DFT / DFM teams. Output: sign-off package — clean reports for every check above. Sign-off gate: the project's tape-out review. Calendar time: the final 4–8 weeks before tape-out are dominated by sign-off iteration.

11. Silicon — Tape-Out and Bring-Up

When sign-off is clean, the GDSII layout file (and the associated metadata package — pad rings, test vectors, mask-data-prep files) is shipped to the foundry. This is tape-out — the project's most consequential milestone.

The foundry takes 8–12 weeks to produce first silicon — a small number of wafers (typically 3–6) on the target process. First silicon arrives in the bring-up lab.

11.1 First-silicon bring-up

The bring-up team's job is to validate first silicon matches the spec:

1. Power-on test — chip enters reset, comes out, draws current within spec.
2. JTAG access — internal test ports respond, identification register matches.
3. Block-level smoke tests — each major IP block responds to its basic interface (boot from ROM, decode an instruction, talk to DDR, etc.).
4. Performance characterisation — measure actual frequency, IPC, power across voltage / temperature.
5. Production-test pattern generation — generate the test vectors that ATE (Automated Test Equipment) will run on every die during production.

11.2 Re-spin or production

If bring-up reveals a functional bug or a critical performance miss, the team enters a re-spin — patch the RTL, re-synthesise, re-route, re-tape-out, wait another 8–12 weeks. A re-spin costs $5M–$50M and adds 4–6 months to the schedule. If bring-up is clean, the chip enters production — the foundry ramps wafer volume, packaging vendors build packages, and the chip ships to customers.

Owner: silicon bring-up team. Output: silicon-validated product. Calendar time: 2–4 months from first silicon to production release.

12. ASIC Flow vs FPGA Flow

The same Verilog source can target either an ASIC or an FPGA, but the downstream flows diverge significantly.

The key differences:

The choice between ASIC and FPGA is a volume × performance decision. High volume + tight power/area constraints → ASIC. Low volume + fast iteration → FPGA. The same RTL targets both; the discipline of writing it cleanly enough to retarget is one of the bedrock skills of working chip engineers.

13. Calendar, Costs, Teams

Real numbers for a real silicon project. The economics drive the flow.

13.1 Calendar time

13.2 Costs (rough order of magnitude)

13.3 Team composition

Typical 50-engineer ASIC team for a mid-complexity SoC:

The flow's stages map directly to the team's roles. Understanding the flow tells you who you'll be working with — and who owns what when something breaks.

14. Where Verilog Fits Across the Flow

Verilog is the canonical artefact of Stage 3 (RTL Design). It is also the input format for Stages 4 (simulation), 5 (synthesis), and a read-only input to Stages 6 (STA) and 8 (sign-off GLS). The chip's behaviour from RTL to silicon is uniquely determined by the Verilog source plus the synthesis tool's translation rules.

Three observations every engineer should internalise:

1. The synthesisable subset is the contract. Everything after Stage 4 reads the synthesisable subset only. RTL that uses initial, #delays, $display in synthesis hierarchy fails at Stage 5 and breaks the entire downstream flow.
2. Verilog is the project's source of truth. Every downstream tool re-derives its view from the same .v files. A change to RTL invalidates everything downstream and forces re-synthesis / re-route / re-sign-off.
3. Different stages read different Verilog. Stages 5–9 read the gate-level netlist (a different Verilog file, autogenerated by the synthesis tool) — not the original RTL. The original RTL is the human-authored artefact; the gate-level netlist is the tool-authored derivative.

15. Debugging Across Stages

When something breaks in the flow, the debug workflow depends on which stage broke. The general rules:

1. Find the stage where the bug first appears. If RTL simulation passes but GLS fails, the bug is in synthesis or in the simulation-vs-synthesis mismatch. If GLS passes but bring-up fails, the bug is in synthesis, in physical-design optimisation, or in a real-world condition (analog, EMI, supply ripple) the digital flow does not model.
2. Bisect on intermediate artefacts. Every stage produces an output. Compare the output to the prior stage's input. A mismatch isolates the failure to that stage's transform.
3. Use the cheapest verification first. RTL sim is cheap; GLS is 100× slower; silicon test is 10 000× slower. Reproduce the failure at the cheapest layer where it shows up.
4. Read every tool's report. Synthesis reports timing violations; STA reports per-path slack; PD reports congestion and DRC; sign-off reports DRC / LVS / power. The report files contain the bug's coordinates — read them before opening a waveform.

15.1 Failure modes by stage

16. Design Review Notes

What a senior chip-design lead checks at every major stage gate:

1. Spec review. Are the performance / power / area targets feasible at the chosen process? Is the schedule realistic? Are interface protocols frozen (or do upstream specs still float)?
2. Architecture review. Does the performance model actually hit the spec targets? Are the block budgets summed correctly? Are clock domains defined and CDC paths called out?
3. RTL freeze review. Is `default_nettype none everywhere? Are all regs reset? Are CDC synchronisers in place? Is the testbench infrastructure ready for coverage closure?
4. Synthesis sign-off. Is timing closed at the target frequency with 5–10% margin? Are clock-gating opportunities exploited? Is area within budget?
5. STA sign-off. Are all PVT corners clean? Are all false paths and multi-cycle paths documented?
6. Physical design sign-off. Is the floorplan stable across iterations? Is power-grid IR drop within spec? Is the chip routable (no over-congested regions)?
7. Sign-off package review. Are DRC / LVS / GLS / power / final-STA reports clean? Is the tape-out checklist complete? Are mask-data-prep files generated?
8. Bring-up plan review. Are the first-week bring-up tests prepared? Are JTAG / boundary-scan / scan-chain access ports verified? Is the ATE pattern set generated?

Every chip that ships has had each of these reviews done explicitly. The reviews are the project's checkpoints — skipping one is exactly the way a re-spin gets planted.

17. Interview Insights

The flow is the single most-asked topic in entry-level chip-design interviews — every interviewer wants to confirm you understand where the work you'll do lands in the larger context.

18. Learning Roadmap

The Verilog track sequences the language layer; the VLSI flow as a whole is bigger than what one curriculum can cover. The roadmap from here:

18.1 Continue the Verilog track

• Chapter 3 — RTL Designing. The three RTL idioms applied to a real FSM.
• Chapter 4 — Lexical Conventions. Comments, identifiers, keywords, operators, numbers, strings, whitespace.
• Chapter 5 — Variables & Data Types. Nets and variables; physical data types like wire and tri.

The Verilog track stops at the RTL layer. To follow the artefact further into the flow, branch into the parallel curricula:

18.2 Adjacent curricula on VLSI Mentor

A working RTL designer needs Chapter 1–6 of Verilog plus the SystemVerilog verification track at minimum. A senior chip engineer adds STA and at least one of front-end or back-end design.

19. Exercises

Three exercises to lock in the flow's shape.

Exercise 1 — Map the artefacts

For each of the following artefacts, name (a) the stage that produces it, (b) the stage that consumes it, and (c) what kind of failure it catches.

1. Verilog RTL .v files
2. SDC constraints file
3. Gate-level netlist
4. SDF (Standard Delay Format) file
5. GDSII layout
6. Sign-off STA report
7. Test vectors for ATE
8. Performance model (C++ / SystemC)

What to produce. A 3-column table with one row per artefact.

Exercise 2 — Diagnose the failure

For each of the following symptoms, name the most likely stage that planted the bug and the most likely root cause. (Hint: refer to §15.1.)

1. "RTL simulation passes 100%. Gate-level simulation shows X-propagation on an internal signal after the third clock cycle."
2. "Synthesis closes timing at the target frequency. Post-route STA reports −150 ps WNS on a single path."
3. "Sign-off DRC is clean. First silicon shows current draw 3× spec and the chip overheats within 200 ms of power-on."
4. "The functional simulation regression hits 100% line coverage but 87% functional coverage."

What to produce. A one-paragraph diagnosis per symptom: which stage planted the bug, what to check first, what tool report to read.

Exercise 3 — Build a cost model

A team is debating whether to ship their chip on a 7 nm process (expected $50M total project cost, 95% chance of clean first silicon, 12-month schedule) or a 28 nm process (expected $15M total project cost, 99% chance of clean first silicon, 14-month schedule). The expected re-spin cost is $35M on 7 nm or $8M on 28 nm.

Calculate the expected total cost of each option, including the probability-weighted cost of a re-spin. Which process should the team choose if their goal is to minimise expected cost? Identify the one factor not in the calculation that would change the decision.

Hint. Expected cost = (base cost) + (P(re-spin) × re-spin cost). Then think about what the calculation misses (hint: revenue, not cost).

20. Summary

The VLSI design flow is the discipline that converts a one-page product spec into a manufactured silicon die over 12–24 months and $45M–$100M of engineering effort. Eight major phases — specification → architecture → RTL → verification → synthesis → STA → physical design → sign-off — each with a defined input, an owning team, a class of failure, and a sign-off gate that gates the next phase. Verilog is the canonical artefact of phase 3 and the input to everything downstream; everything else in the flow exists to refine, verify, and physically realise what the RTL described.

The takeaways every later chapter assumes:

• Every stage has its own verification. RTL simulation is just one of them.
• A bug caught at stage N is ~10× cheaper than the same bug at stage N+1. The flow exists to push bugs leftward.
• The synthesisable subset is the contract. Constructs outside the subset belong in testbenches, not RTL.
• ASIC and FPGA share the front-end but diverge at synthesis. Same RTL, different downstream flows.
• Tape-out is the most consequential milestone. Sign-off exists to make tape-out non-negotiable.

Reading the flow as a refinery rather than an assembly line is the working engineer's framing — every stage is a transform, every transform irreversible, every output a sign-off artefact for the next stage. From Chapter 3 onward this curriculum drills into the RTL phase itself — the three RTL idioms, the lexical layer, the type system, FSMs, pipelines, CDC — but everything that follows assumes the flow you mapped here.

Related Tutorials

• Introduction & Overview — Chapter 1; what Verilog is and where it fits.
• RTL Designing — Chapter 3; the three RTL idioms applied to a real FSM.
• Variables & Data Types — Chapter 5; the type system every RTL declaration draws from.
• Physical Data Types — Chapter 5.1; the deep drill into the net family.
• wire and tri Nets — Chapter 5.1.1; the two workhorse net keywords.