More or less test compression? Is that your final answer?
How much is enough? I mean, the more the better right? Shorter test time, fewer I/Os needed, what’s not to like about that?
If you were at ITC last year, and you were clued in on device-level design for test issues as I was, you may have noticed that both Mentor and Synopsys came up with papers addressing this issue. Interestingly enough, it seeemed they were coming from completely opposite points.
Chris Allsup from Synopsys brought the paper entitled The Economics of Implementing Scan Compression to Reduce Test Data Volume and Test Application Time.
Janusz Rajski of Mentor, et. al., presented a paper that describes a new test compression architecture, entitled X-press Compactor or 1000x Reduction of Test Data.
If you missed them, related articles have appeared at Test & Measurement World Online: The Mentor article called simply, Test Compression, and the Synopsys called Optimizing Compression in Scan-based ATPG DFT Implementations.
So now that you’ve clicked on the links and thoroughly read and considered each article, what do you think? Do they argue opposite points? Leave a comment below and tell me.
My take is after the click..Here’s what I took from the articles:
he main thrust of the Mentor article is that new geometries present new defect types, requiring more and more targeted ATPG patterns. Time has proven that each new defect type will take up 3, 4, maybe 5 times the vector memory as the last. Therefore, more compression is essential. Their next quantum leap in test compression technology promises 1000x compression.
Now the other side: the Synopsys paper goes to great mathematical lengths to prove that too much compression actually cuts into the bottom line. I believe the analysis is good, given the assumptions. Intuitively, here’s the point: Given an amount of scan vector memory, quality gains are made with Test Data Volume Reduction (TDVR), until that volume fits within the available memory. After that, any additional compression provides small gains in Test Application Time Reduction (TATR). But very soon, silicon costs (area and routing congestion) overshadow the benefit of the reduction (diminishing returns).
So is there common ground here? Maybe. The Synopsys analysis contains a factor called Ac (”A sub c”), or the complete set of ATPG patterns. It’s my take that the Mentor paper says that the complete set is growing as we sit idly by and read DFT blogs. And according to the Synopsys equation - the amount of compression needed is proportional to the size of the complete set of patterns.
So my simplistic view is that Allsup’s analysis can be a valuable tool when considering your next test compression implementation. However, keep in mind as we go from one geometry to the next, new defect types appear, and history shows that the complete ATPG pattern set grows accordingly.
April 11th, 2007 at 8:46 am
I believe you have correctly identified that the two articles are arguing opposite points.
I would like to add some more observations:
Test data volume and Design Size (Same Fault Model):
- Pattern count growth is relatively flat
- growth is proportional to the FF count increases
Fault models:
- failure mechanisms make good conversation.
- industry will rely on stuck-at, transition flts.
When one talks about high compression one needs to understand the need behind it. What is it? Is the need for test-data-volume or test-application-time? How much of the test problem is covered by the compressable part (digital, structural) of the test set?
April 15th, 2007 at 9:28 pm
Hi Rohit!
Thanks for commenting, and bringing your experience to this discussion. I find the test compression topic fascinating - and I find myself learning more about the basic underlying ATPG technology as I study compression.
I agree that one’s motive for compression is important. Depends upon the device, but in my world, TATR is never the primary goal - too much analog in the package for scan to be significant. But even so, with the amount of digital, and the desire to somehow get to a lower cost tester, TDVR is my main concern.
I also think failure mechanisms do make good conversation. How long do you think SA and transition faults will suffice? I don’t really know, myself, but you could be right, but my hunch is that we might be in for some different modes as we traverse the next couple of technology nodes.
I’d appreciate if you’d expand on your first observations about TDV and design size. Not sure if I got your drift - especially the first bullet.
Anyway, thanks again for reading and commenting. I you have time, take a minute to register!
JMF
April 23rd, 2007 at 10:37 am
The summary of the data that I had collected sometime back was that if you plotted pattern count (number of ATPG generated tests) against design size (gates) for a given fault model, you would find that the number of patterns does not increase much with design size. One might question this because the fault count does increase with design size. There are too many factors that play into this to be able to say anything for sure, but the depth of the combinational circuitry is not following the same trend of the design size.