U. Glaeser

using ad hoc methodologies that are localized and specific to the design. Test reuse is the ability to provide
access to the individual IPs embedded in the SoC so that the test for the IP can be applied and observed
at the chip level. This ability to reuse becomes more complex when the IPs come from multiple sources
with different test methods. It becomes difficult to achieve plug and play capability in the test domain.
Without a standard, the SoC design team is faced with multiple challenges such as a test model for the
delivery of cores, the controllability and observability of cores from the chip I/O, and finally testing the
entire chip with embedded IPs, user defined logic, and embedded memories.
Core Delivery Model
Core test is an evolving industry-wide issue, so no set standards are available to guide the testing of cores
and core-based designs. Cores are often delivered as RTL models, which enable the end-users to optimize
the cores for the targeted application; however, the current test practices that exist in the “soft core” based
design environment are very ad hoc. To a large extent it depends on whether the “soft core” model is
delivered to the end user without any DFT built into the core itself. The core vendors provide only
functional vectors that verify the core functionality. Again, these vectors are valid only at the core I/O
level and have to be mapped to the chip I/O level in order to verify the core functionality at the chip
level. Functional testing has its own merits and demerits, but the use of functional tests as manufacturing
tests without fault simulation cannot provide a product with deterministic quality. It can easily be seen
that any extensive fault simulation would not only result in increased resources, but also an extended
test development time to satisfy a certain quality requirement.
Controllability and Observability of Cores
A key problem in testing cores is the ability to control and observe the core I/O when it is embedded
within a larger design. Typically, an ASIC or IC is tested using the parallel I/O or a smaller subset of
serial ports if boundary scan is used. In the case of the embedded core, an ideal approach would be to
have direct access to its I/O. A typical I/O count for cores would be in the order of 300–400 signals. Using
a brute-force approach all 300 signals could be brought out to the chip I/O resulting in a minimum of
300 extra multiplexers. The overhead in such a case is not only multiplexers, but also extra routing area
for routing the core I/O to the chip I/O and most of all, the performance degradation of at least one gate
delay on the entire core I/O. For most performance driven products, this will be unacceptable. Another
approach would be to access the core I/O using functional (parallel) vectors. In order to set each core
I/O to a known value, it may be necessary to apply many thousands of clocks at the chip I/O. (This is
because, the chip being a sequential state machine, it has to be cycled through hundreds of states before
arriving at a known state—the value on the core I/O signal).
Test Integration
Yet another issue is the integration of test with multiple cores potentially from multiple sources. Along
with the ability to integrate one or more cores on an ASIC, comes other design challenges such as layout
and power constraints and, very importantly, testing the embedded core(s) and the interconnect logic.
The test complexity arises from the fact that each core could be designed with different clocking, timing,
and power requirement. Test becomes a bottleneck in such an environment where the designer has to
develop a test methodology, either for each core or for the entire design. In either case, it is going to impact
the overall design cycle. Even if the individual cores are delivered with embedded test, the end user will have
to ensure testing of the interconnects between the multiple cores and the user logic. Although functional
testing can verify most of these and can be guaranteed by fault simulation, it would be a return to
resource-intensive ways of assuring quality.
Because many cores are physically distinct blocks at the layout level, manufacturing test of the cores
has to be done independent of other logic in the design. This means that the core must be isolated from the
rest of the logic and then tested as an independent entity. Conventional approaches to isolation and test
© 2002 by CRC Press LLC