Testing multichip modules (MCMs) can be a challenge, so it is important to develop a sound test strategy. You need to understand a wide range of system design issues: cost, projected volume, repairability, availability of CAD tools, level of design-for-testability. It is easy to get lost in the forest of all these trees. But self-test can provide a pathway.
Multichip modules (MCMs) are a costly system design because of the complexities involved with placing multiple ICs in a small package. The traditional IC test strategy of full functional test is appropriate only for relatively simple MCMs. Using board test techniques on complex MCMs is difficult because of the lack of access in the small package. In many applications, self-test can provide an at-speed test. It works because many MCMs contain some type of processing element, the basic requirement for a self-test.
MCM Test Strategies
The most critical issues to think about when selecting an MCM test strategy are your coverage goals, the quality of the incoming parts and the available test methods.
Setting the overall coverage goal means determining how much testing of the
assembled MCM will be done. For example, tests to demonstrate the functionality of consumer product design prototypes can be less complete than final tests for astrospace equipment.
The level of testing done on the incoming parts is closely tied to the issue. If incoming parts have been screened with 99.99% effective tests, the MCM test can be relatively simple compared with the test required when 50% of the incoming parts are bad.
Once you determine coverage goals and quality levels, it’s time to select a test method. Choices include full functional test, system or hot mock-up test, assembly test and self-test.
Full functional test can achieve very high fault coverage, but often at a penalty of extremely long test development time. Functional test also does not lend itself to automated fault diagnosis, important for repairable MCMs.
System or hot mock-up test has a similar drawback: Special diagnostic routines must be written to isolate faults. But a system test can be easier to develop than functional test because the test involves plugging the MCM into a target system and running system software. In functional test, the vectors must be developed as an additional process step. System test has its own drawbacks, though. The main one is that you need expensive test equipment for each
new product.
Assembly test, in which parts are assumed good and their interconnects are tested, is usually straightforward and provides excellent support for automated fault diagnosis. IEEE 1149.1 boundary scan is the modern method of performing interconnect testing. However, with this test method, you don’t test the overall functionality of the MCM, so it is best used as a first- level test to be followed by a functional or system test.
Finally, there is self-test. This method has two main variations–built-in self-test (BIST) and tester-assisted self-test. BIST is becoming an important test method, especially with advances in test synthesis tools, because BIST can be expensive to develop manually. The biggest advantage of BIST is that it allows an at-speed test that does not require a high-speed tester. A disadvantage of BIST is that the test coverage is usually limited to internal nets only–there is no way to test external I/O ports using BIST.
On the other hand, tester-assisted self-test uses the test equipment to initialize the test and exercise the I/O signals. This self-test is usually simpler to develop than BIST, and code developed for one self-test can generally be used in other designs. Table 1 summarizes the advantages and disadvantages of various test strategies for MCMs.
Self-Test Strategy
The basic architectural requirements necessary to support self-test are simple: You need a processing element and some memory. The processing element can be a common microprocessor, a microcontroller or a digital signal processor.
The memory element may consist of one or more RAM chips, an EEPROM device, or even internal memory integrated into the processing element. The self-test code is loaded into the memory and the processor is allowed to execute.
When you implement self-test, be sure there is a way to load the test code into the memory. For example, if an external memory chip is to be used, the memory address, data and control lines must be accessible to the tester. The reset line to the processor must be available so the tester can assert reset and turn off the processor drivers while the memory load is underway. If there are other components on the MCM that could affect this operation, they must be disabled.
Another issue is control of execution when reset is released. If the processor looks for starting addresses in the memory that has just been loaded, everything is fine.
Some microcontrollers and other devices may have internal boot ROM that could prevent your self-test from executing. In this case, you must provide an interrupt so that the processor can be made to execute the self-test. An easier solution: Have the ROM boot routine modified to look for the self-test and, if present, execute it.
When planning the self-test, it is important to identify the test goals up front. The test can target chip-to-chip interconnects or die functionality. For an MCM built with known-good die, a test concentrating on interconnects is usually adequate. Each interconnect must be tested in both the logic high and logic low state, so a test plan should include the method to accomplish this.
If the MCM is repairable, you must consider fault diagnosis at the planning stage. This entails defining how a bad component or interconnect will be identified after a
test failure. For example, if a bad wirebond exists, automated diagnosis techniques would identify the fault directly from the failing test vector information.
The steps involved with developing a self-test are shown in Figure 1. We have already covered the first step, identifying test goals. Next, assembly code must be written using assembly language statements for the target processor.
The code should handle the initialization of the processor registers, set up the I/O ports and perform other such tasks. Then the test for the MCM can be written.
You may need a memory map containing the addresses of registers in support chips such as ASICs. These other ICs must be initialized before any specific tests can be done.
Once the code is written, run the assembler to produce machine code. This code usually resides in an ASCII file with anywhere from 1 to 80 bytes per line. Sometimes you may have to convert the file into a format understandable by the software and hardware that will download the machine code into the processor. Once download is complete, test execution can begin.
Test Size, Test Time
The size of the self-test program is measured in bytes. In most cases, there will be plenty of memory to hold the test program. When on-board RAM is the target memory device, however, the test program can be huge, since a typical RAM device these days is at least 32k bytes. When you plan to load the test program into microcontroller internal memory, size becomes an issue. Internal RAM can be as small as 256 bytes or as large as 2k bytes. A self-test for an MCM will typically be in the hundreds of bytes range.
If memory limitations become a problem, you can work around it. A first alternative is to rewrite the assembly code to make more efficient use of memory. Experienced code writers know many tricks that can save space. Another alternative is to partition the test into multiple blocks and perform multiple downloads to test the MCM.
The issue of multiple downloads raises the question of total test time. In some cases, even single downloads can be very time-consuming. For example, a long test program which is loaded through a device’s serial port could take minutes to download. This is usually not acceptable. Shorten the program or develop a method to perform a parallel download into memory.
More Issues
Writing efficient self-test depends on making the best use of the resources in the MCM design. One feature of many processors and ASICs is programmable I/O ports. Such ports often have special functions but can be used as general-purpose pins.
When interconnect tests are the primary self-test goal, a simple trick is to set all general-purpose pins to be outputs. Then write test data to all the ports in two passes, once with high data and once with low data (or you could use an alternating checkerboard pattern, as shown in Figure 2). This method of test is very efficient because all the outputs in the design can be tested simultaneously.
If the ports were configured as inputs, they would have to be written individually. The tester drivers would have to provide stimulus at predetermined times and the self-test assembly code would have to read individual ports and then check the results or reflect them in an
output port. Properly synchronizing all these activities takes considerable effort.
Chip-internal memory is one of the two main memory configurations possible in an MCM self-test. The self-test code is loaded internally, using support features on the host IC. With this type of memory setup, you get excellent internal test of the host chip. Also, when executing out of internal memory, you are free to exercise any external memory as you see fit. One drawback of internal memory self-test is that internal memories are often restricted to serial loading.
The other memory configuration is a memory device mounted inside the MCM and tied to the processing element. The usual way to load processor code into this type of memory is by using direct tester access to the memory signal connections. Once the memory is loaded, the processor takes off.
The advantage of this type of self-test is that the processor, memory and connectivity are usually very well tested.
But there are drawbacks. One is that you do need quite a bit of tester access to parallel load the memory. In some cases, the original design of the MCM may be in a package without enough pins to provide access for memory load. A new package or new test strategy is then required.
Another problem with this self-test architecture is that operating the processor from the memory may preclude complete test of the memory. In other words, there may be specific test needs for the memory that cannot be met because the processor code resides there.
A final possible memory configuration is to have no on-MCM memory element at all, but use the tester to store the processor code. This can become more complex than storing the code in the MCM, because the tester will be involved with other activities besides operating as a memory.
This method also gives you the lowest amount of test coverage since the device is not executing as it would normally. It is not even a self-test, but a standard, tester-provided functional test.
Self-Test Debug
The first time the self-test is executed on the tester, it will fail. The challenge is to figure out why.
Debugging processor code execution failures is not like debugging test vectors for combinational logic. This is sequential logic, where the state of the processor and the input conditions determine the outputs. Start at the beginning of the process. Did you perform a reset? Does the processor come out of reset properly? By carefully examining the bus signals as the processor begins execution, you should be able to determine when execution becomes different from what was intended. A listing of your assembly code should help.
One common error is to set up the output ports before initializing them with data. Failures can occur because the data ports in some processors will contain arbitrary data after power-up and reset.
Figure 2 shows an example of code that could cause failures on the tester. The fix is very simple, though. Place lines 3 and 4 ahead of the rest of the code and the port will be initialized before the output drivers are enabled.
Example MCMs
Figure 3 shows block diagrams of two MCMs successfully verified using self-test. The first MCM contains a digital signal processor, an ASIC and two static RAM chips. The tester loads the self-test code in parallel into the SRAMs.
The ASIC interconnect is tested by writing and reading its various registers. Several DSP and ASIC signals connect to the MCM I/O pins.
Signals that can be tested as outputs are verified by writing data to the proper port registers. Signals that must be tested as inputs are driven at appropriate times by the tester and monitored by the digital signal processor (DSP). The total test time, including memory loading, is quite fast because of the parallel load. The test size is approximately 580 bytes.
The MCM in the second example in Figure 3 contains a microcontroller, a flash memory and an ASIC. The test for this MCM executes out of RAM internal to the microcontroller.
Writes to and reads from the flash array and ASIC registers constitute the bulk of the interconnect testing performed. Most of the microcontroller ports can serve as general-purpose I/O, so they are configured as outputs and tested by writing to their data registers. The test size is about 340 bytes, but the total test time for this self-test is longer than the previous example because the code requires bit-at-a-time loading through the microcontroller serial port.
Conclusion
Self-test is an excellent technique for verifying today’s MCMs. Certain of the advantages of self-test are obvious: Self-test definitely proves the functionality of the MCM by having the processing element execute real code. Self-test execution speed is limited only by the ability of the tester to load the MCM memory and provide a signal to clock the processing element. Consequently, self-test can easily provide an at-speed test in many applications.
About the Author
Andrew Flint is an MCM Test Engineer with Motorola’s Semiconductor Product Sector. He has been involved with developing and implementing MCM test strategies for the past three years. Previously, he worked at Digital Equipment Corp., where he supported board test activities. Mr. Fling has a B.S.E.E. degree from the University of Maine and a 1992 M.S.E.E. degree from National Technological University. Motorola, EL615, 2100 E. Elliot Rd., Tempe, AZ 85284, (602) 413-5992.
ATE
Test Type
Strengths
Weaknesses
Functional
High coverage
Poor diagnosis support
Complex
Assembly
Good diagnosis support
Simple
No functional coverage
Requires DFT
Self-test
Relatively simple
Reusable
Tests I/O signals
Can be slow
Low diagnosis support
BIST
At-speed test
No tester needed
No I/O test
Low reusability
Complex
System test
Excellent coverage
Expensive equipment
Copyright 1995 Nelson Publishing Inc.
September 1995
|
|