As discussed in Part
1, concurrent test can cut test times and the cost of a system-on-a-chip (SoC), but test-resource partitioning challenges
can arise at both the system level and at the intellectual property (IP) level.
At the system level, the overall architecture of your design should be amenable to concurrent test, that is, it should
permit independent access to multiple IP blocks that can be tested concurrently. At the IP level, your IP itself should be
selected so that your test methods don't create dependencies on other IP blocks.
Let's look at some of the tradeoffs at both the system and the IP levels that can help achieve these goals. At the system
level, it is important to generate a test controller that will permit multiple IP blocks to be tested concurrently. It is also
important to generate a scheduler if on-chip scheduling is desired. Providing a test bus and/or directed access to IP through
core isolation is also significant, as is the ability to provide independent access to IP.
Matching the test bandwidth for IP and the number of clock domains involved is also important, as is the placement of analog
blocks away from noisy digital blocks. Built-in self-test (BIST) for memories vs. direct access is also significant, as is the
need to determine what's needed with respect to a shared-memory BIST controller and/or an individual BIST controller.
At the IP level the test method used for IP and its properties (such as the number of scan chains or the number of clock
domains) is important, as are the test bandwidth requirements of the IP and its test-power rating. Also important is any
dependence on other cores for testing, as well as the environmental requirements for scan (such as having the output of the other
cores being three-stated). Lastly, it should be essential to match the system test architecture.
Design-for-Test Issues
Back to top
Design-for-test (DFT) for concurrent test can incorporate all conventional DFT techniques, plus some others to enable
concurrent test. Let's look at serial DFT, parallel DFT, and some related test methods.
Serial DFT can include
- scan (single, multiple, DC/AC scan, 1149.1, etc.),
- test support for analog interfaces (such as delta-sigma A/D conversion serial tests), and
- core wrappers (such as P1500 and Virtual Socket Interface Alliance, or VSIA) to isolate the IP under test from its
environment, and to make IP in the environment quiescent.
Example techniques for parallel DFT include
- MUX isolation of cores,
- bus splitting to enable parallel tests of modules, and
- interleaved data access on a bus if splitting isn't possible.
There are a number of possible test methods. These include BIST (for memory, logic, PLLs, and I/O), Iddq, and
loop-back tests (digital and analog). While all these DFT approaches are possible, present efforts to implement concurrent
test focus on serial-access schemes, BIST, loop-back, and bus-splitting techniques.
The Role of EDA
Back to top
Automation tools are absolutely essential to handle the complexity of systems-on-chips (SoCs). Challenges you may face in
supporting concurrent test rest in DFT tools, test-generation tools, and test-translation tools.
In addition to supporting conventional DFT techniques such as scan, BIST, and boundary scan, EDA tools have to use DFT
techniques to enable concurrent testing. Design-rule-checking (DRC) tools are needed to analyze the conflicts during concurrent
test modes. You also need methods to reduce power during test. Tools for doing bandwidth analysis and matching for the IP are
also required, and DFT synthesis tools are needed to generate controllers and schedulers.
Test-Generation Tools
Back to top
Test-generation tools pose challenges for supporting concurrent test. First, conventional test-generation tools may need to
be modified to generate test programs organized as a set of sub-test programs for IP instead of a single monolithic test program
for the whole SoC.
Also, the control information for generating various port configurations should be generated.
Finally, test-generation tools might have to be enhanced to generate test vectors that dissipate less power while still
achieving the required test coverage.
Test-Translation Tools
Back to top
Test-translation tools may also have to be enhanced with a number of possibilities. For one, they may have to translate new
forms of the tests generated by test-generation tools as a set of tests for the IP. They may also have to generate a test program
from the sub-programs for the IP blocks such that the overall test time is optimized while staying within device constraints such
as power and pin limitations.
Test-translation tools are among the most important pieces of software for optimizing the ATE (automatic test equipment)
resources to device test requirements.
It's likely that test-translation tools must also exploit parallelism from test programs that haven't been generated for
concurrent test as such. This would be the case in the beginning of your design cycle, when devices aren't necessarily designed
for concurrent test, and the test-generation tools mentioned above may not yet be available.
What's Needed In ATE?
Back to top
In general, one of the challenges for ATE in supporting the concurrent test of SoCs is supporting a test model, where instead
of treating the SoCs as an "atomic" entity for test, it's viewed as a collection of IP that needs to be tested.
In order to implement this model, multiple copies of resources will be required to be able to test multiple IP blocks
simultaneously. Let's explore the limitations of conventional ATE systems, and review the requirements of an ideal ATE for
concurrent test.
The Limitations
Back to top
Generically, implementing concurrent testing requires a full suite of independent test resources dedicated to each functional
block. However, digital and memory test subsystems of conventional ATE have central resources that either prevent this, or make
it difficult to accomplish for those few cases where it may be possible at all.
Limiting central resources typically include central digital sequencers, central period generation, global time-set selection,
and central scan-memory boards. Additional limitations include central memory test algorithmic-pattern generation (APG), central
source/capture boards, and central error-capture facilities.
As such, concurrent operation is possible only when the test patterns of the concurrently tested functional blocks are merged
into a single pattern across all participating pins.
In such cases, a single sequencer program and test period must be sufficient. Typically, this is done either by functionally
testing the entire SoC or by flattening the design and inserting scan chains, and disregarding the structure of the design.
The functional test approach often cannot stress all the embedded cores concurrently, as the ATE generally lacks the ability
to run all the cores at native speed. Certainly, the resulting "concurrent test" is specific to a particular test methodology
(often excluding memory and mixed-signal tests). Note that the resulting test data are specific to an SoC, and can't be re-used
for another SoC that partly integrates the same embedded cores.
Dual-Sequencer Architectures
Back to top
Beyond these widely used single-sequencer approaches, there are ATE systems offering dual-sequencer options, or those that use
a sequencer-per-site architecture. Both approaches add capital costs—for the additional sequencer and signal distribution to
improve flexibility and throughput.
Dual-sequencer architectures typically offer a high degree of independence between the sets of pins assigned to one or the other
sequencer. However, for a fully flexible solution to test two arbitrary cores concurrently, not only are two sequencers required,
but two source and capture memories, APGs, etc. are also required.
If two independent clock sources are used to generate the vector period, the system may not be able to start the two sequencers
vector-aligned, and may not stay phase-aligned throughout the pattern execution time. This isn't a limitation for truly independent
testing, except during debug when repeatability would permit debugging interdependencies more effectively.
In any case, it prevents the synchronous testing of functional blocks that run at fractional speeds derived from a central clock.
But, note that distributing two independent clocks selectively to sets of pins may cause intermodulation issues, and may impact the
timing accuracy as well.
In the next part of this article we'll look at an ideal multi-port ATE architecture, and use a generic 3G (third generation) cell-phone
design as an example.
