In-depth VLSI guides: one topic, covered properly

The complete guide to static timing analysis

Static timing analysis (STA) checks that every signal in a synchronous design arrives neither too late (setup) nor too early (hold), on every path, without simulating a single vector. It works by breaking the design into timing paths, adding up cell and wire delays along each one, and comparing the result against the clock. Because it is exhaustive and fast, STA is the sign-off method for timing on every modern chip.

Timing paths: the unit of analysis

Every check is done on a path with a start point and an end point. There are four kinds:

• Register → register: clock pin of a launching flop to the D pin of a capturing flop. Most internal logic.
• Input → register: from a primary input, constrained with set_input_delay.
• Register → output: to a primary output, constrained with set_output_delay.
• Input → output: pure combinational feed-through, constrained by both.

The tool builds a timing graph of all these paths and propagates arrival times forward and required times backward. Slack = required − arrival. Negative slack means the path fails.

Setup and hold, with numbers

Take a launch flop and a capture flop on the same 1 GHz clock (period 1000 ps). Clock-to-Q = 80 ps, logic = 700 ps, setup = 50 ps, hold = 30 ps. The capture clock arrives 40 ps later than the launch clock (skew = +40 ps).

• Setup: arrival = 80 + 700 = 780 ps. Required = 1000 + 40 − 50 = 990 ps. Slack = +210 ps. It passes.
• Hold (fastest logic path, say 60 ps): arrival = 80 + 60 = 140 ps. Required = 0 + 40 + 30 = 70 ps. Slack = +70 ps. It passes.

Note the asymmetry. Positive skew added 40 ps of setup margin but consumed 40 ps of hold margin. And the clock period appears only in the setup check.

Constraints: telling STA what the design means

STA only knows what the SDC file tells it. The essentials:

• create_clock and create_generated_clock: every clock, with its period and source.
• set_clock_uncertainty: a guard band for jitter and, before CTS, for skew that doesn't exist yet.
• set_input_delay and set_output_delay: how much of the cycle the outside world uses.
• set_false_path: paths that can never be exercised, such as between asynchronous clock domains that are properly synchronized.
• set_multicycle_path: paths that intentionally have more than one cycle (remember to adjust hold too).
• set_clock_groups -asynchronous: declares clocks that have no phase relationship.

Wrong constraints are the most dangerous STA problem: an over-broad false path can hide a real failure and still report "clean".

Corners, modes and variation

A path must meet timing across corners (process, voltage, temperature, and interconnect extraction corners) and modes (functional, scan shift, scan capture, low-power). Setup is usually worst at the slow corner, and hold at the fast corner. At advanced nodes, temperature inversion can make low temperature the slow case, so both ends are checked.

Within one die, identical cells still differ. On-chip variation (OCV) is modelled by derating: making the data path slower and the capture clock faster for setup, and the reverse for hold. Flat OCV is simple but pessimistic. AOCV derates by logic depth and distance, and POCV/SOCV uses statistical sigma values per cell. CRPR then removes the pessimism of derating the clock path that launch and capture share.

Signal integrity

After routing, coupling capacitance between wires means a switching neighbour (the aggressor) can speed up or slow down a victim net (crosstalk delta delay), or inject a glitch into a quiet net (noise). Sign-off STA includes these effects using the extracted parasitics, which is one reason post-route timing is always worse than the estimates made at placement.

ASIC vs FPGA: a complete comparison

An FPGA is a chip full of configurable logic and routing that you program after manufacture. An ASIC is a chip manufactured for one design. The choice shapes the cost, schedule, performance and flexibility of the product, and a good engineer can argue it with numbers rather than slogans.

Where the differences come from

In an FPGA, every logic function is built from look-up tables (LUTs), and every connection passes through programmable routing switches. That flexibility costs silicon area, delay and power: the same function on an FPGA is typically several times larger, slower and more power-hungry than on an ASIC in a comparable process. In an ASIC, standard cells and wires are placed exactly where the design needs them, and nothing is spent on programmability.

The economics: NRE vs unit cost

An ASIC has a large one-time cost (NRE: engineering effort, EDA licences, IP, and above all the mask set, which at advanced nodes runs into millions of dollars), and then a low cost per chip. An FPGA has almost no NRE, but every unit costs much more.

A simple break-even: if an ASIC costs $5M in NRE and saves $40 per unit compared with an FPGA, it pays off after 125,000 units. Below that volume, the FPGA is cheaper overall. Above it, the ASIC wins, and the gap keeps growing.

Time to market and risk

An FPGA design can be running on hardware in weeks, and a bug is fixed by loading a new bitstream. An ASIC takes many months from RTL freeze to working silicon. A bug found after tape-out can mean a metal-layer fix or a full re-spin costing months and millions. This is why ASIC teams invest so heavily in verification, and why many ASICs are prototyped on FPGAs first.

Performance, power and features

• Clock speed: an ASIC reaches much higher frequencies at the same node.
• Power: an ASIC uses far less, which is critical for battery devices and dense data-centre chips.
• Analog and custom blocks: an ASIC can integrate any analog, RF or custom memory. FPGAs offer a fixed menu of hard blocks (transceivers, DSP slices, block RAM, sometimes processors).
• Flexibility: an FPGA can be updated in the field, which is valuable where standards change (networking, telecom) or algorithms evolve.

Decision guide

Middle-ground options exist too: structured ASICs and FPGA-to-ASIC conversion services trade some flexibility for lower unit cost.

The complete guide to UVM verification

The Universal Verification Methodology (IEEE 1800.2) is a SystemVerilog class library and a set of conventions for building testbenches that are reusable, configurable and scalable. Its value isn't any single feature. It's that every UVM testbench has the same shape, so engineers, VIP and whole environments move between projects easily.

The problem UVM solves

Before UVM, every team built testbenches differently, and reusing a testbench on a new project often meant rewriting it. UVM standardizes structure (which components exist and how they connect), stimulus (sequences), configuration (the config database and the factory), and reporting. Once you know one UVM testbench, you can navigate any other.

The anatomy of a testbench

Picture two paths through the environment:

• Stimulus path: test → sequence → sequencer → driver → DUT pins.
• Checking path: DUT pins → monitor → analysis port → scoreboard and coverage.

An agent packages the sequencer, driver and monitor for one interface, and can be active (it drives) or passive (it only watches). An environment holds the agents plus the scoreboard. The test sits at the top: it chooses the configuration and the sequences, and it never contains checking logic itself.

Phases: when things happen

All components run through the same phases in lockstep: build (create children, read configuration, top-down), connect (wire the ports, bottom-up), run (the only phases that consume time), then extract, check, report. The objection mechanism decides when the run phase is over: the test raises an objection while stimulus is running and drops it when done.

Reuse: the factory and the config database

The factory lets a test swap a class for a derived one (say, an error-injecting driver) without editing the environment. That requires every component and object to be created with type_id::create(). The config database passes settings and virtual interface handles down the hierarchy without hard-coded paths. Together they let one environment serve dozens of tests.

Coverage-driven verification

UVM testbenches are usually constrained-random: sequences generate legal random stimulus, and functional coverage measures which features were actually exercised. The workflow is a loop: write the verification plan, run random regressions, find coverage holes, then add constraints or directed sequences to close them, and repeat until the plan's goals are met and bug-discovery rates flatten.

Registers: the RAL

Most blocks are configured through registers. The register abstraction layer gives the testbench a model of every register and field, so tests say regmodel.ctrl.enable.write(status, 1) instead of hand-building bus transactions. An adapter translates to the real bus, and a predictor keeps the model's mirrored values in sync with the bus traffic it observes.

Clock domain crossing: a complete guide

Whenever a signal travels between flops clocked by unrelated clocks, the receiving flop can sample it while it's changing and go metastable. Clock domain crossing (CDC) design is the discipline of making those transfers safe, and CDC verification is proving every crossing is handled. CDC bugs are notorious because they often pass simulation and appear only in silicon.

Why simulation misses CDC bugs

Standard RTL simulation has no notion of metastability: a flop samples either the old or the new value, cleanly. Real silicon can produce an in-between voltage that resolves unpredictably, or bits of a bus that arrive in different cycles. That's why CDC needs structural checking tools and design rules, not just more tests.

Single-bit control signals

Pass a single, glitch-free, registered signal through a two-flop synchronizer in the destination domain (three flops for very fast clocks or strict MTBF targets). Rules:

• The source must come straight from a flop. Combinational logic before the synchronizer can glitch.
• Signals must be held long enough for the destination to sample them. A pulse from a fast domain can be missed entirely, so convert it to a toggle (a pulse synchronizer).
• Never let the same source fan out to two separate synchronizers whose outputs are then combined (reconvergence). They can resolve in different cycles.

Multi-bit data

Synchronizing each bit separately is wrong: bits can land in different cycles and create a value that never existed. Choose a method by data rate:

Resets across domains

Reset is a crossing too. Each domain needs its own reset synchronizer (asynchronous assert, synchronous de-assert), and the release order between domains may matter: a producer shouldn't start sending before its consumer is out of reset.

CDC verification

CDC tools read the RTL and the clock definitions, find every crossing, and check that it has an approved synchronizer structure. They flag missing synchronizers, combinational logic before synchronizers, reconvergence and unsafe multi-bit crossings. Designers then fix or formally waive each finding. The goal is a clean report with every waiver justified. Some teams also add metastability injection in simulation, randomly delaying synchronized signals by a cycle to shake out design assumptions.

Physical design sign-off, explained

Sign-off is the set of final checks that decides whether a layout is safe to manufacture. Every one of them must pass, or be formally waived, before the GDS goes to the foundry, because problems found after tape-out cost months and millions. Sign-off is less about any single tool and more about thoroughness and correlation.

Timing sign-off

Final STA runs on the routed design with extracted parasitics (SPEF), across all modes and corners, with signal integrity and OCV derates enabled. Setup, hold, maximum transition, capacitance and fanout, clock pulse width, and recovery/removal checks must all be clean. Timing ECOs close the last violations, and each ECO is re-extracted and re-checked.

Physical verification

• DRC: every foundry rule for width, spacing, enclosure and density.
• LVS: the layout's extracted connectivity matches the netlist (no shorts, opens or missing devices).
• Antenna: no gate is exposed to excessive charge from long wires during fabrication.
• ERC: floating gates, missing well ties, and wrong supply connections.
• Density and fill: metal and poly density within the windows the foundry requires for planarity.

Power integrity and reliability

IR drop analysis (static, and dynamic with realistic switching activity) confirms that every cell sees enough supply voltage. Timing is often re-checked with the IR-drop-annotated voltages. Electromigration checks current density on power and signal wires against the foundry's lifetime limits. Designs with power gating also check the power switches, the in-rush current at turn-on, and that isolation and retention cells work.

Logical equivalence and low power

A formal equivalence check proves that the final netlist, after all the optimizations, CTS buffers, scan insertion and ECOs, still implements the same logic as the golden RTL. Low-power static checks verify the UPF intent: every crossing between power domains has the right isolation or level shifter, and every cell is connected to the correct supply.

Correlation: the hidden skill

Implementation tools estimate timing, parasitics and IR drop while they optimize. Sign-off tools compute them more accurately. If the two disagree, the design "closes" in implementation and then fails at sign-off, late in the schedule. Good teams correlate early: the same corners, derates, extraction settings and constraints in both, and regular spot-checks, so sign-off holds no surprises.

DFT: a complete guide to design for testability

Every manufactured chip must be tested, because fabrication introduces defects: shorts, opens, and marginal transistors. Design for testability (DFT) adds structures that let a tester control and observe the internal logic quickly and cheaply, so defective parts are caught before they ship. DFT decisions affect area, timing, power and test cost, so DFT engineers work with every other team.

Controllability and observability

Testing a flip-flop deep inside a design through its primary pins alone could take an astronomical number of cycles. DFT improves controllability (setting internal nodes to known values) and observability (seeing their values) directly. Almost every DFT technique serves one of those two goals.

Scan design

Each flip-flop is replaced with a scan flop that has a mux on its input. In test mode, the flops are connected into long shift registers called scan chains. The tester shifts a pattern in, applies one or more capture clocks to let the logic respond, then shifts the result out while shifting the next pattern in. This turns a sequential design into a combinational test problem that software can solve.

Fault models and ATPG

• Stuck-at: a node permanently at 0 or 1. It's the baseline model, and it catches many physical defects.
• Transition (delay): a node that switches too slowly. It needs at-speed testing with launch-on-capture or launch-on-shift.
• Path delay, bridging and cell-aware models target specific defect types at advanced nodes.

ATPG (automatic test pattern generation) tools create patterns that detect these modelled faults, and report fault coverage (detected faults ÷ total faults). Production targets are commonly well above 95% for stuck-at.

Test compression

A modern chip may have millions of scan flops. Shifting that much data through a few tester pins would take too long and too much tester memory. Compression puts a decompressor on-chip that feeds many short internal chains from a few pins, and a compactor that combines their outputs. This cuts test time and data volume by an order of magnitude or more.

Memories, boundaries and the rest

• MBIST: on-chip engines run algorithmic tests (for example March tests) on embedded memories, and repair logic can swap in redundant rows or columns.
• LBIST: an LFSR generates pseudo-random patterns and a signature register checks the response, useful for in-field self-test (common in automotive).
• Boundary scan (IEEE 1149.1 JTAG): test cells on every I/O, for testing board-level connections and accessing on-chip debug.
• IEEE 1500 and 1687: standards for wrapping cores and accessing embedded instruments.

DFT's effect on the rest of the design

Scan muxes add area and a little delay. Scan shift toggles many flops at once, causing high power and IR drop, so shift speed is usually limited. Test modes need their own timing constraints and STA runs. Scan chains are re-ordered after placement to shorten wiring. That's why DFT is planned from the start of a project, not bolted on at the end.