Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Industry Insights > logic built in self test lbist is back but not for manufacturing test
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Logic Built-in Self Test (LBIST) is Back – But Not for Manufacturing Test

Comments(1)Filed under: Industry Insights, Encounter, RTL Compiler, DFT, ATPG, test, ATE, Encounter Test, MBIST, Logic BIST, memory BIST, scan, JTAG, LBIST, automotive electronics, in-system testing, MISR, built-in self test

Memory providers have long used built-in self test (BIST), a technology that builds self-testing circuitry directly into an IC. Logic BIST (LBIST), which tests the functional logic, has been around for a long time too -- but it did not get much traction except for some high-end CPU server and networking chips. Now, LBIST is back -- but generally not for manufacturing test, as you might expect.

First, some quick background. An LBIST macro, as shown below, includes a pseudorandom pattern generator (PRPG) and a multiple-input shift register (MISR). The LBIST macro generates and runs stimulus derived from a seed, and then checks "signatures" of bits to verify the expected operation of the circuit. The stimulus can be driven over scan chains. LBIST can use JTAG circuitry to initiate the testing, or it can use a direct method where a pin changes state and LBIST automatically runs.

LBIST macro block diagram

LBIST sounds like a neat way to allow chips to test themselves, and to potentially reduce reliance on expensive testers. So what could possibly go wrong? Dale Meehl, staff product engineer at Cadence, noted several limitations that became clear in the 1980s and 1990s.

One is that it took a lot of work to insert the LBIST circuitry. Another is that LBIST takes a lot longer to run on the tester, which translates directly into cost, and it limits test coverage because it only uses random patterns. "In the 2000s, test compression came on board, and it became a lot more cost effective to use compression technologies at the tester rather than LBIST," he noted.

In-System Testing

Fast forward to 2012, and there's a lot of interest in mission-critical markets - military, medical, and especially automotive - in LBIST. But it's generally not for a one-time manufacturing test. It's for repeated testing in the field (or "in system" testing) to ensure that a car or a satellite or medical device is working as expected.

For example, if you have an electronically-controlled braking system, LBIST could run every time you turn your car on. If it doesn't see the right signatures and it can't verify that the logic is working correctly, the car's electronic controls can alert the driver or perhaps prevent the transmission from going into drive.

Of course logic ICs still run through the usual manufacturing tests, but most likely the LBIST will not be turned on in production testing.  Meehl observed that LBIST requires more test patterns than conventional testing, may take an extra millisecond or two to work, and probably won't provide high enough test coverage without additional test vectors. For manufacturing test, the most common approach is still ATPG driven tests for the majority of users.  LBIST is turned off and treated like functional logic.

There's also an area penalty for the LBIST controller, but this could be in the 1-2% range for a large chip, Meehl said. He noted that Cadence has been able to reduce the size of the LBIST macro that Cadence tools generate to about 120 flip-flops, a reduction of nearly half compared to the original macro.  This solution allows for a smaller macro when designs use small digital logic.

An Automated LBIST Insertion Flow

The Cadence Encounter Test product has supported automatic test pattern generation (ATPG) for LBIST for many years. A new capability with the recent Encounter 11.1 release, however, is the automatic insertion of the LBIST macro with the Cadence RTL Compiler (RC). The automated flow first builds scan chains, then inserts compression channels, and then builds the LBIST circuitry. Designers can check coverage and manually add more test points to improve coverage.

Encounter Test then validates that the PRPG and MISR are working properly, generates the final signature, and provides the fault coverage for a given LBIST run. The diagram below shows the flow in more detail (OPCG is on-product clock generation).

Automated LBIST insertion with Cadence RTL Compiler (RC) and Encounter Test (ET)

With LBIST, therefore, an old technology has found new life, thanks in large part to the prevalence of electronic control systems in automobiles. LBIST today isn't just about simplifying manufacturing test - it's about improving mission-critical reliability and potentially saving lives.

Richard Goering

 

 

Comments(1)

By Nikhil Dakwala on May 14, 2012
There's nothing dramatic going on with Lbist. Its usage has been steadily increasing because more EDA tools are coming online. Those companies with resources and Lbist-know-how are using it in production and have done so since early 1990s. With correct implementation, few thousand vectors will provide at-speed coverage in high 90s. Only through a major screwup can Lbist consume more test time than ATPG. Silicon Debug has always been the achilles heel for Lbist. It is even more so now due to process variations. CHeers

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.