The smallest granularity of current architectures is on the level of digital
channel boards—it's typically 16 pins or 32 pins. This coarse granularity of assigning pins to sequencers puts severe constraints
on a system-on-a-chip (SoC) test interface. For example, a BIST (built-in self-test) port may consist of only a few pins. All remaining
pins on the digital channel board can't be used to test another block concurrently.
The Ideal Multi-Port ATE Architecture
Back to top
An ideal multi-port architecture must overcome the limitations of independent timing sets for ports with independent period selection.
It must also overcome the on-the-fly-reconfiguring of ATE ports and DUT interfaces with a per-pin granularity to match the suite of test
access ports active at each instant of time.
In addition to these requirements, some features can add considerable value. For example, the ideal concurrent-test system should also
be designed in such a way as to permit the user flexibility in adjusting a test after development.
Data-Rate Speed Changes
Back to top
Once first silicon is available, it's often beneficial (and occasionally mandatory) to adjust the operational frequency of one or more
tests. That's because one test may not run at the design frequency, while others may need to run faster.
The ideal concurrent-test environment must support data-rate speedup and slowdown techniques without significant additional test
development efforts. Similarly, it may prove beneficial to speed up some critical-path tests, as these tests directly impact the resulting
test time.
There may also be an opportunity where one or more concurrent-test ports fall idle. These idle moments are obvious opportunities for
adding additional tests with no impact on the test time.
A flexible concurrent-test approach also provides an opportunity for process-monitoring tests, data logging, or nonstandard performance
checks during these idle moments.
A Cell-Phone Example
Back to top
As promised in Part 1 and Part 2 of this series, let's consider an example that describes a concurrent-test implementation. We'll describe
a generic third-generation (3G) cell-phone design.
Let's assume this 3G cell phone is an ideal system. As such, our theoretical analysis will identify various test elements with associated
percentages of test-time requirements for the case of serial execution. Here's the block diagram representing our ideal cell phone.
Figure 1 - A Generic 3G Cell-Phone Design
The table reflects the approximate time percentages needed to test this system.
| Microprocessor |
21.7% |
| DSP |
20.6% |
| Flash |
17.4% |
| D/A Converter |
12.1% |
| A/D Converter |
7.2% |
| Filters |
6.8% |
| ICC |
5.4% |
| RAM |
1.7% |
| DC Tests |
1.7% |
With appropriate access schemes, JTAG, and BIST circuitry, it's possible to execute four
concurrent tests on our theoretical device, resulting in a significant throughput improvement.
This is shown in the figure at right, where the various test elements are "stacked" on top of each other, much as you would stack up blocks
of various heights (the height of the blocks represents the test time associated with that step).
While this is only a model, it shows how powerful concurrent testing can be, by reducing our test-time requirement by nearly 70 percent.
|
 |
If only a portion of this result can be achieved in the actual test implementation, it will result in a significant cost savings.
Flexibility Needed
Back to top
In order to realize this goal, however, the ATE system will need considerable flexibility. First, let's consider flash testing.
Flash tests are characterized by considerable use of match loops. Our ideal concurrent-test platform must be able to perform the match-loop
functions on one port while the other port(s) continue its (their) test execution uninterrupted.
Next, the ATE must encompass RAM testing. Today's SoC devices are using more and more memory arrays of various configurations. The ideal
concurrent test platform must be able to move from one configuration of memory test to another without interrupting the test flow on the
adjacent ports.
Our ideal concurrent-test system must also be able to run simultaneous memory test sequences on multiple ports at the same time. Thus, it
should provide for multiple APGs (algorithmic pattern generation).
Next come microprocessor/DSP tests. An ideal concurrent-test platform must be able to handle various JTAG and parallel test sequences, along
with the embedded memory tests associated with these design elements. The ability to handle long pattern lists as well as AC-scan and varying
data rates is a common requirement for these elements. What's more, all of these capabilities have to be available independently on a per-port
basis to support concurrent testing.
Next
>>
