How do you spell BIST?
[editors note: This post is a first in a regular series of featured contributions from Stephen Pateras of LogicVision. I look forward to bringing you his, (and hopefully other's, in the future), knowledge on the DFT Digest blog - John]
Sometimes I think BIST should be written BKST. Even though both proprietary and commercial solutions for Built-In Self-Test, sometimes called embedded test, have been around literally for decades now, the capabilities and benefits of using these solutions remain in large part one of the Best Kept Secrets in Test.
I started my career almost twenty years ago (god, has it really been that long?) at IBM, and BIST was the main test methodology used…even back then. However, despite being around for so long, many forms of BIST are still very much misunderstood by a large part of the semiconductor and electronics industries. Sure, most designs today include some basic form of BIST for embedded MEMORIES. When it comes to OTHER parts of the chip, only a relatively small number of more advanced designs take advantage of existing BIST capabilities…those that cover logic, low and high-speed I/O and even mixed-signal circuitry. (Yes, they do exist). The state of affairs is even worse at higher package levels. Consider that although BIST is generally reusable, it is almost never taken advantage of during board or system test. Makes you wonder. Clearly, there’s a lot of room for improvement here.
So MY goal, as a new and regular contributor to this blog (BTW – thanks, John, for the opportunity) is to be a BIST evangelist and spread the word about BIST. I plan to explain different existing BIST capabilities as well as explore new and future BIST developments. Also, whenever possible, I’m going to present and analyze real user experiences and results. There’s nothing like understanding what others have done and experienced. Oh and one more thing I’m really looking forward to is debunking a lot of the urban myths (or is it urban legends) about BIST…and believe me, there are a whole bunch of them. I figure it’s like those NBC commercials “The More You Know…” What’s important is to understand what’s available and what trade-offs exist between different forms of BIST and between BIST and other forms of DFT so that better test strategy decisions can be made.
Well, I’m guessing you now know how to spell BIST, and hopefully as we explore this field in future posts you will come to appreciate it as much as I do.
[Steve Pateras is VP of marketing at LogicVision. Steve performed his graduate work in test and has spent his entire career involved in either using, defining, or marketing DFT and BIST products and technologies]
Stumble It!
Consider that although BIST is generally reusable, it is almost never taken advantage of during board or system test. Makes you wonder.Clearly, there’s a lot of room for improvement here.
John,
Let me explain why this is so.
I work in Hewlett-Packards Ink Jet group on consumer and low-end office products. We do 2-4 asics a year with a variety of vendors.
We give our vendors a list of all the sram cuts needed in an asic and they deliver a set of simulation and synthesis models. They may deliver one module per cut or they may group several srams into a single bist group.
I instantiate these into our chip top level and connect all of our mission mode signals. We have a mode pin dedicated to muxing all the pads between mission mode and vendor IC test mode. This is pulled low on the pca and the vendor drives it high during their tests to gain access to all their different tests.
The vendors DFT engineer will designate 3 or 4 pins as inputs in asic_test_mode and decode them into their various tests ( ATPG_SCAN, MEM_BIST,IDDQ, Logic_BIST etc).
They will also use these signals to mux the needed control and observation signals into and out of the chip when the test is selected and to configure the clock system for the test. They then connect these signals to their bist connections on the srams.
During IC_TEST they will put the chip in MEM_BIST mode , kick off the test and monitor the error/fail bits that emerge.
This is useless for board test.
We use a full 1149.1 boundary scan on our chips so my PCA test enginner probably doesn’t have a test point on the pins needed to run the test and if they did they wouldn’t have any way to disable the board components that are also driving the node.
What I do in my job is that I create the needed control and observ signals using internal jtag registers so that I can mux these in while the chip is on the PCA in mission mode. Then they can be run during board test.
We have done this with enough vendors so that now they come to us with their own jtag control and all I have to do is daisy chain their tap with mine.
If you give a dft engineer a big iron tester that can drive every pin then they will make use of all the pins. You have to train them to only use the bare minimal jtag set if you want to reuse the test in board test.
System test is a whole other can of worms. We execute system tests by loading code into internal sram and having it toggle gpios when finished.
Between needing to remove the sram containing the code from the test and designing the bist to run on the mission mode clock configuration it is a real mess. We gave up trying to do this.
John Eaton
Thanks for the feedback John. Based on your description of how the BIST you are using is integrated and accessed, I can certainly see how difficult it would be to reuse these capabilities for board or system test. But this goes precisely to the point I was making. There exist commercial BIST solutions out there that support far more structured integration and access, yet many people don’t seem to be aware of it. There is no need for example to require anything more that the 1149.1 TAP pins to access and run any chip-level BIST. So support for standard 1149.1 boundary scan is all that would be needed at the board level. There are also commercial solutions for accessing the chip-level TAP signals using a simple CPU interface so that system level reuse is straightforward. There is also hope for less structured forms of BIST. The upcoming IEEE P1687 standard will define a standard access infrastructure and protocols for any embedded instrument IP (including BIST). This will lead the way for 3rd party tools that can integrate any BIST IP and thus provide a standard way for accessing it at any package level.
Steve,
Interesting thread … and you haven’t even really started your series yet
It’s always good to keep abreaast of what is going on because the tradeoff between LBIST and ATPG and Compressed ATPG is pretty dynamic as capabilities are being added.
I have 2 questions, and perhaps you will cover these in future posts:
1) It seems to me that board-level BIST is only really useful if you believe that a chip can go bad after it’s initially tested good. I realize that IO can go bad (e.g. ESD) and that will be caught by boundary scan testing. But how common is it that a chip goes bad internally in a way that is not also manifested in the IO?
2) The ATPG tools now support the ability to test for bridging faults and small delay defects and can also be modified to be power aware. To what extent do LBIST tools support this?
harry
Hi Harry:
Very good questions. You’re right that each one is a topic worthy of a separate post. However let me give you at least a quick answer to each:
1) There’s ample data that shows how environmental conditions (e.g. temperature, noise, power) can affect the operation/performance of a device. This is especially true for higher performance parts. I’ve seen several cases where tests (both BIST and functional) passed on the tester yet failed when applied in system.
2) Although LBIST does not target faults, it is typically able to provide very high coverage of many different fault models due to the large number of patterns it is able to apply (much more on this in an upcoming post). Average power can be controlled through a number of techniques that control activity across different cores and across different clock domains.
1) It seems to me that board-level BIST is only really useful if you believe that a chip can go bad after it’s initially tested good. I realize that IO can go bad (e.g. ESD) and that will be caught by boundary scan testing. But how common is it that a chip goes bad internally in a way that is not also manifested in the IO?
Harry,
Once you solder a BGA down it is a real pain to remove it, reball it and retest it. Any time you can rerun a IC test without disturbing the part you can gain some very useful debugging info. Sometimes knowing what works is as useful as knowing what doesn’t.
Also your bist and atpg tests can be the worst case modes for your chips power consumption. That gives you an easy way to test your PCA’s power supplies and distribution
John Eaton
hi,can u all tell me what was the lead inductance and how it gets affected at microwave frequencies
[...] the flow, even when I’m to busy (well there is Steve Pateras, who has posted a couple of very compelling articles, which consistently get a good flow of comments). Anyone else like to write? Have [...]