THE VLSI HOMEPAGE

Traditional scan based designs employ either Muxed-scan technique or Level Sensitive Scan Design (LSSD) techniques to achieve test coverage. In scan based designs, the registers are hooked up to form serial shift register chains - this aids in capturing all the combinational logic faults between two pipelined registers.

There is a shift phase during which the ATE pattern is shifted serially through the scan chain from the IO pins. Once the ATE pattern is shifted through the scan chain, there is a capture phase that allows the flops in the scan chain to capture the combinational logic output at their input pins. Following this capture phase, the pattern is shifted out serially and compared with the expected vector from ATPG.

Each clock domain can have it’s flops stitched into a single/multiple scan chains, based on the number of flops in the clock domain - stitching multiple scan chains is an advantage as it reduces tester time since we can parallely load all the scan chains. Usually mixing clock domains or posedge and negedge flops in a scan chain is not recommended as it can cause timing issues. Use of lock-up latches is advised if crossing from posedge to negedge flops in a scan chain.

Advantages of scan based design are several - high fault coverage with moderate increase in logic, the entire insertion is automated. The main disadvantage of scan based testing is that it runs at low speed typically 50 MHz - this is very slow for high speed designs and where at-speed testing is critical.

Muxed scan

The figure below shows a muxed-scan flop and associated waveform - the D pin is the normal functional input, SI is the scan input and SE is the scan enable to shift in and shift out data out of the flop. The Q output of the flop is connected to SI pin of the next flop in the scan chain. During the capture phase, the Q latches the D input and the data is shifted out.

Muxed scan flip-flop

LSSD scan

A schematic of LSSD scan flop and waves is shown in the figure below. The relationship between clocks is also shown - the SCK1 and SCK2 are active during shift phase while the CLK is active during the capture phase.

LSSD scan flop

Differences between Muxed scan and LSSD are several - in muxed scan, the data and test paths are the same i.e. the test path is muxed with the functional path and can add additional logic on the functional path making timing closure harder. Muxed scan flops are smaller in area and are faster but the same functional clock is used for shift/capture and can cause shift violations. In contrast, the LSSD scan paths are different from functional paths, have two different non-overlapping clocks for shifting data in and out and one capture clock. LSSD flops are larger in size but the timing closure is easier as we never run into shift violations.

Main disadvantage of scan based testing is that it runs at low speed typically 50 MHz - this is very slow for high speed designs and where at-speed testing is critical.

Share This

Overview

Design for Testability (DFT) is one of the critical requirements in a design - additional test logic is added to detect any manufacturing defects such as opens/shorts on a silicon die. A chip or a die can be tested at various levels ( at wafer level, package level, board level, system level or in the field). By detecting the manufacturing defects beforehand, the manufacturing costs can be lowered.

Various fault models exist to model the defects such as “stuck-at” faults - where a particular node is either stuck at zero or one and a vector should excite the node to it’s opposite value to detect the fault. Delay fault models help in detecting sequential faults that affect timing but not the functionality.

Controllability and Observability are key concepts to DFT. Controllability is the ability to set or reset each and every internal node in the design while Observability is the ability to observe (either directly or indirectly) any node’s state.

For example, one of the requirements for DFT is that all clocks and resets in the design must be controllable from the pins - this involves adding multiplexers with additional test control logic. This falls under the Ad-hoc testing category.

Designs also integrate testability features like traditional scan, Memory BIST (Built-in Self Test) and Repair, Boundary scan (JTAG), Logic BIST and IDDQ to ease testing at wafer/package level. These features are exercised using test vectors that are generated by ATPG (Automatic Test Pattern Generation) tools. Algorithms such as D-Algorithm, PODEM, SCOAP aid the ATPG tool in reducing the number of required test vectors and thus the tester time.

Fault coverage is the measure of effectiveness of test vectors exercised on the design. In most designs, a fault coverage of atleast 98% is mandatory before taping out.

We will look at each one of the DFT features in detail in another post.

Share This

Traditional verification strategies involve writing directed testcases to exercise all known features of the Design under Test (DUT) and the environment is often written in HDL or ‘C’. This method has proved very tedious and inadequate in addressing all possible scenarios, not to mention the effort/time taken.

A solution to this productivity issue has been to raise the level of abstraction and use constrained random stimulus to stress the design - Hardware verification languages (HVL) like ‘e’ or Vera use Object Oriented Programming (OOP) features, complex data types for higher abstractions, automated configurable tasks and also understand the hardware concepts of time and concurrency.

A typical transaction level verification environment is shown below comprising of two major components - Test functions and Test Harness (from Janick Bergeron’s Writing Testbenches). The Test harness integrates all the transaction layer components necessary to exercise the DUV and is self-contained. Test functions use procedures from the test harness to generate data items and configuration constraints.

Self-checking scoreboards with data extractors, reference models and checkers are also critical parts of Test functions. The coverage analyzer with functional coverage items and cross coverage items also gathers statistics from the generator/monitor to track the verification progress.

Transaction layer verification environment

Traffic generator - As the name implies, the traffic generator generates data items (packets, cells, frames) using OOP cencepts to stimulate the design. These data items are generated randomly but with proper hard and soft constraints so that no illegal data types are generated.

Bus Functional Model (BFM) - BFMs also known as Drivers, model the physical interface of a standard protocol like PCI, SATA to exercise the DUT at one end and at the other end, offer a transaction layer level inteface to the Test functions using procedures.

Protocol Monitors - do not drive any signals, monitor the DUT outputs, identifies all the transactions and report any protocol violations.

Scoreboards - Self-checking, integrates a reference model that dynamically processes the input stimulus to generate the expected output. The transformation is purely functional and does not include any latency and physical interface behavior. The Scoreboard records all transfer function outputs and compares them against Rx BFM outputs for integrity.

Coverage - Random testcase environments are coverage driven - only coverage can track the progress of verification to check if all the possible scenarios have been covered.

Two types of coverage - functional coverage that answers if functionality of the design has been verified and code coverage that answers if particular piece of code has been exercised.

Code coverage includes FSM coverage (if all transitions from one state to another are covered), line coverage (if all the lines in a module are covered), toggle coverage (if all signals are toggling from 0 -> 1 and 1 -> 0) and conditonal coverage (cover all conditions like in a if-else statement).

We will revisit each of these modules in detail with examples in ‘e’ or Vera in another post.

Share This