In short: Every chip is tested on expensive automated test equipment to catch manufacturing defects and verify it meets spec, using functional tests (does the logic behave?) and parametric tests (are voltages, currents and timing within limits?), after which each die is sorted into a pass/fail "bin" that decides whether it ships, and at what grade.
Why do we even test chips?
Modern silicon is manufactured in batches of hundreds of dies on a single 300 mm wafer, and no fabrication process is perfect. A stray particle, a slightly misaligned lithography layer, a thin-oxide pinhole, or electromigration-prone metal can turn one die into scrap while its neighbor works flawlessly. Industry yields for a mature node often sit between 85% and 98%, which still means many dies per wafer are defective. If those bad parts reach a customer, the cost of a field failure can be 1000× the cost of catching it at wafer sort.
This is the classic "rule of ten": a defect that costs cents to catch at wafer test costs dollars at package test, tens of dollars on a board, and potentially thousands once it fails in a car's airbag controller or a data-center GPU. Testing is not a formality; it is the economic firewall between the fab and the customer.
⚙️ A single high-end Advantest V93000 or Teradyne UltraFLEX tester can cost well over US$1 million, so test time is measured in milliseconds and every extra 100 ms per device directly erodes margin.
Where testing happens in the flow
Testing is not one event. It happens at several stages, each with a different purpose:
- Wafer sort (probe test): needles on a probe card touch each die's pads while it is still on the wafer. Bad dies get an ink dot or a digital bin so they are never packaged.
- Final test (package test): after dicing and packaging, the part is retested in its real package to catch assembly-induced faults (bond-wire opens, cracked solder).
- Burn-in: parts run hot and at elevated voltage for hours to force "infant mortality" failures to surface before shipment.
- System-level test (SLT): the chip runs real firmware in a mock application board, catching subtle issues that structured tests miss.
Functional test: does the logic actually work?
A functional test asks a behavioral question: given a set of inputs, does the chip produce the correct outputs? The tester applies stimulus vectors to the device's pins and compares the measured response against a "golden" expected pattern, cycle by cycle. For a microcontroller this might mean loading a tiny program and checking that an ALU add returns the right result; for a memory it means writing patterns like walking-1s and reading them back.
Pure functional vectors, however, are hard to generate with high coverage for millions of gates. That is why structured, scan-based testing dominates: flip-flops are chained into scan chains, and tools such as Siemens Tessent, Synopsys TestMAX (formerly TetraMAX) or Cadence Modus generate ATPG (Automatic Test Pattern Generation) vectors targeting a fault model. Stuck-at and transition-delay fault models let a team claim, for example, 99.2% stuck-at coverage, meaning the pattern set would detect 99.2% of all modeled single-point faults.
? A built-in self-test (BIST) block like Memory BIST lets a RAM test itself at full clock speed without the tester supplying every vector — essential when a chip has thousands of embedded SRAM instances.
Parametric test: are the electrical numbers in range?
A chip can be logically correct yet still out of spec electrically. Parametric tests measure analog quantities and check them against datasheet limits:
- DC parametrics: leakage current (IDDQ), input/output levels (VIL/VIH/VOL/VOH), continuity (checking a pin isn't open or shorted), and quiescent supply current.
- AC parametrics: setup/hold timing, propagation delay, rise/fall times, and maximum operating frequency (Fmax).
IDDQ testing is a classic example: a healthy CMOS circuit draws almost no current when static, so an abnormally high quiescent current (say 50 µA where the limit is 5 µA) flags a bridging defect even when every logic output looks correct. For more on how these two test types complement each other, see our deeper dive on functional vs parametric test.
| Aspect | Functional test | Parametric test |
|---|---|---|
| Question answered | Is the logic correct? | Are the volts/amps/timing in spec? |
| Measured quantity | Digital pass/fail of a vector | Analog value vs. a limit |
| Typical example | Scan/ATPG, memory BIST | IDDQ, VOH, Fmax, setup/hold |
| Catches | Stuck-at, transition faults | Bridging, leakage, speed binning |
Pass/fail binning: sorting the good from the bad
When testing finishes, each device is assigned a bin number — a software category that records the outcome. Bin 1 is almost always "good part, all tests passed." Higher bins encode specific failure reasons: Bin 5 might mean "failed scan," Bin 7 "failed IDDQ," Bin 12 "continuity open." This binning is what makes test data actionable: engineers study the bin histogram (a Pareto of failures) and the wafer bin map to see whether failures cluster at the wafer edge (process gradient) or appear randomly (particle defects).
Binning is not only pass/fail. Speed binning turns parametrics into revenue: a CPU that passes at 4.2 GHz is binned and sold as a premium part, while an otherwise identical die that only passes at 3.6 GHz is binned as a lower SKU. The same wafer thus yields a spread of products.
Putting it together with a concrete example
Imagine a wafer of 500 dies. At sort, 60 fail scan (Bin 5) and 20 fail IDDQ (Bin 7), giving 420 good dies — an 84% sort yield. Of those 420, final test and speed binning sort 150 into a fast grade and 270 into a standard grade. The bin map shows the Bin 7 failures hugging the wafer edge, pointing the process team toward an etch non-uniformity. None of that insight exists without disciplined binning — it is the data backbone of yield engineering, feeding back to design-for-test choices made with tools from Avecas's silicon design services and the fab alike.
Want to run real ATPG, read a wafer bin map, and set up a test program hands-on? Our Post-Silicon Validation & Test course walks you through it on industry tooling — or explore the scan and ATPG basics primer first.
Frequently asked questions
Is functional test the same as verification?
No. Verification (pre-silicon, with simulators and UVM) checks that the design is correct. Functional test (post-silicon, on real parts) checks that a manufactured chip is free of defects. A perfectly verified design can still produce defective dies.
Why can't one test type do everything?
Functional/structural tests find logic defects but say nothing about whether a pin's output voltage is in spec; parametric tests measure electrical limits but don't exercise deep logic states. Both are needed for a shippable part.
What does "Bin 1" mean?
By convention Bin 1 is the fully-passing, top-grade device. Other bins encode either specific failure causes or performance grades (speed bins) used to create different product SKUs from one wafer.
How much coverage is "enough"?
It depends on the application. Consumer parts may ship at ~98–99% stuck-at coverage, while automotive (ISO 26262) parts push toward 99.9%+ with additional fault models and burn-in to hit single-digit DPPM defect rates.