ASIC, FPGA and RTL-to-silicon foundations

Explanation

From Boolean behavior to a product

Digital logic lives in several representations:

Term	Meaning
Gate	Logical operation such as NAND, XOR, or a flip-flop abstraction
Standard cell	Characterized physical implementation from a target library
Macro	Larger fixed or generated block such as SRAM, PLL, or analog IP
RTL	Clocked behavioral description of registers, transfers, and logic
Netlist	Instances and connections after synthesis or implementation
Library	Cell functions, timing, power, and physical views for a technology
PDK	Foundry process rules, device models, verification decks, and data
Die	Fabricated piece of silicon containing the integrated circuit
Package	Mechanical and electrical connection between die and board
PCB	Printed circuit board connecting packaged components

The same RTL can produce different netlists for different libraries, constraints, and targets.

ASIC and FPGA

An ASIC implements the design using fabricated cells, wires, and macros for a particular process. It can optimize performance, power, area, interfaces, and volume cost, but fabrication has high cost and long turnaround.

An FPGA implements logic in prebuilt configurable blocks and programmable routing. It supports quick iteration and field updates but usually has different speed, power, density, clocking, memory, and I/O behavior from the final ASIC.

An FPGA prototype can validate much functional behavior and software interaction. It cannot prove final ASIC timing, power, scan, analog behavior, pad/ESD design, IR drop, electromigration, or PVT closure.

Connected development flow

1. Requirements: define behavior, interfaces, performance, clocks, resets, safety, test, and operating assumptions.
2. Architecture and microarchitecture: partition blocks, select datapaths, storage, protocols, pipelines, and error handling.
3. RTL: describe synthesizable state and combinational behavior.
4. Functional verification: use simulation, assertions, formal methods, coverage, and review to check intended behavior.
5. Synthesis: map RTL and constraints into target cells or FPGA primitives; review timing, area, power estimates, warnings, and unmapped logic.
6. DFT: add and verify scan, memory test, test control, and production-test structures as required.
7. Implementation: place cells, build clock networks, route connections, and optimize physical constraints. FPGA tools perform analogous mapping, placement, and routing into programmable resources.
8. Sign-off: analyze timing, physical rules, connectivity, power integrity, signal integrity, and other approved checks across required modes and corners.
9. Fabrication and packaging: manufacture wafers, test dies, package good devices, and perform production tests.
10. Bring-up: power the real device safely, confirm clocks and reset, run diagnostics, compare against expected behavior, and investigate hardware/software interactions.

Iteration occurs throughout. A timing or power problem can require changes to architecture or RTL, while verification findings can change requirements and tests.

Functional verification and physical sign-off

Functional verification asks whether the design does the intended thing under relevant scenarios. Physical sign-off asks whether its implemented geometry and electrical behavior satisfy manufacturing and operating requirements.

Passing RTL simulation does not prove timing closure. Passing static timing does not prove protocol correctness. Both use assumptions and constraints that must be consistent.

Process, voltage, and temperature

Device delay and leakage vary with manufacturing process, supply voltage, and temperature. Sign-off uses approved PVT corners and variation models. A corner that is worst for setup may not be worst for hold or leakage.

PPA summarizes power, performance, and area. These objectives interact:

• increasing drive strength can improve delay but add power and area;
• deeper pipelining can raise frequency but add latency, registers, and clock power;
• resource sharing can reduce area but lower throughput;
• lower voltage can save dynamic power but reduce timing margin.

Power concepts

Dynamic power grows approximately with switched capacitance, voltage squared, frequency, and activity. Leakage power exists even without switching. Clock trees and high-activity datapaths can dominate dynamic power.

Power delivery also matters. IR drop reduces local voltage due to current through resistance. Electromigration concerns long-term metal damage from current density. These are physical effects that RTL simulation does not establish.

Design and verification responsibility

A useful handoff includes:

• traceable requirements;
• clock, reset, and CDC definitions;
• interface and register specifications;
• width and numeric assumptions;
• verification plan and coverage evidence;
• synthesis and implementation constraints;
• waiver rationale and known limitations;
• reproducible tool versions, commands, reports, and artifact identifiers.

Warnings should be explained, corrected, or formally waived. “The tool completed” is not evidence that the design is ready.

Worked example

Consider a timer peripheral with a 32-bit counter, programmable limit, interrupt, and memory-mapped control.

• Requirements define tick frequency, reset values, limit behavior, interrupt clearing, and overflow.
• Microarchitecture chooses counter width, compare logic, enable, and status registers.
• RTL implements the counter and register interface.
• Verification tests reset, disabled retention, limit values 0/1/maximum, interrupt timing, simultaneous clear and expiry, and bus errors.
• Synthesis maps the counter, comparator, and registers and reports critical paths and area.
• Timing analysis checks register paths and I/O constraints across required modes and PVT corners.
• DFT analysis ensures counter flops and controls satisfy the test strategy.
• Physical implementation places and routes cells and closes clocks, power, and signal integrity.
• Bring-up reads the identity register, checks reset, measures tick timing, and exercises interrupts with software.

Each stage uses the same behavioral intent but supplies different evidence.

Check yourself

Why does successful FPGA prototyping fail to prove ASIC sign-off? What different questions do functional verification and static timing analysis answer?