Test Compression Series - Installment #2
Just a note to re-iterate what this site is all about: discussing the technology, methodology and best-practices of IC design-for-test. It’s as simple as that. I don’t pretend to keep up with the wrinkles in the EDA industry - even though I depend upon them for my next tool. I’m to busy trying to make the ones I got work.
That said, I was trying to explain how test compression works, as concisely as possible, to provide a backdrop for understanding what is available to help implement it on an IC that needs it. In my previous installments, the introduction and installment #1, I briefly explained why one might use test compression, and how it provides its benefits.
In this installment, I’d like to explain some of the different methods of broadcasting data from a very few scan inputs across many internal parallel scan chains; the terminology for this implementation varies from tool to tool.
No matter the implementation, they all stem from a technique called “Illinois Scan”, so called because of its origins at the University of Illinois, Urbana-Champaign, a few years ago. This method spreads data from a few scan chain inputs to several maybe hundreds of internal scan chains. It provides decent fault coverage and huge test time and TDV reductions. The reason for only “decent” fault coverage is correlation between scan cells, that is,it’s impossible to sensitize some faults because the same data is loaded into all the scan chains. But it still works pretty good.
The current commercially available decompression implementations come in two basic flavors: combinational and sequential. Some consist of some combination of XOR-gates and MUXes, some are implemented by some sort of LFSR. Either way, the aim is to randomize the input data to reduce the correlation present in a straight broadcast system such as Illinois scan.
The success of the implementation depends upon the combination of hardware and software involved, which brings up an important point: Today, if you use test compression IP from a particular EDA company, you also use their ATPG tool. Synopsys’ TetraMAX will not be able to generate patterns given a test compression implementation generated by Mentor’s TestKompress. Or vice-versa. Or any other combination. This gets sticky when a design might go to more than one different foundry; different foundries support different EDA flows (and compression implementations).
However, on the horizon is an effort by Accellera called the Open Compression Interface (OCI), which would provide a way for different compression implementations to mate up with different ATPG tools. Draft version 1.0 was released as a publicly digestible document late last month. You can read about the effort here.
Exciting times ahead..
Stumble It!
[...] When I last left off in this series, we were talking about the broadcasting of scan data from a few external scan chains across many internal parallel scan chains, and some of the ways it is implemented. Not too much detail, but enough to present the concept. So far, all high-level DFT. Well, once the data has propagated through these much shorter chains, the data must be compressed back into the width of the external scan data paths. Like in the case of decompressing the data, there are a couple of alternatives here, some combinational, some sequential. The combinational implementations are XOR-trees, and the sequential implementations are as you might expect, some sort of MISR. Each has it’s advantages and disadvantages. [...]
[...] Back in Test Compression Series - Installment #2, I made brief mention of OCI, which is an effort that was undertaken by Accellera due to a need in the industry for flexibilty in test compression solutions. At this time, test compression implementations come in tightly bound pairs consisting of compression IP and ATPG software; both must come from the same company. This poses problems especially for silicon targeted for more than one foundry, where the different foundries support different yield diagnostics software. The OCI breaks the need for pairing the IP and software by defining a common interface, which provides just enough information about the compression IP so that any ATPG tool can understand how to generate vectors, but not so much as to give away the secrets of the IP’s implementation. Next stop, IEEE standards process. Who’s on board? [...]