But this, compelling as it is, may not be the only good reason to include test engineers in the architectural development of a system-level chip. The other major reason has little or nothing to do with chip test, and everything to do with system test. The same forces that are exacerbating the chip test problem are both worsening the life of system test engineers and opening wonderful opportunities to them at the same time. It all comes back to integration and capacity.

On the negative side, increasing integration is burying critical test access points within the chip. This doesn't exactly make the test points inaccessible, but it does mean that they become the property of the chip test people rather than the board- or system-test team. Since these teams may be in different companies, and since they certainly will have different objectives and vocabularies, this is no mean problem. There may literally be no channel for conveying the system test needs to the chip design team.

That can mean that critical nodes, or whole critical blocks, get isolated from the outside of the chip. Certainly they will be subjected to testing at the wafer level and probably as packaged dice, but these tests may be functional tests developed by an IP design team that had no concept of the actual use or environment in which the block now finds itself. So the testing that the block gets as a chunk of IP embedded in the chip may be significantly different than the testing that system-test designers would have specified for the same block as a stand-alone IC. That can spell trouble.

All of this gets grimmer as the use of high-speed serial I/O-the current darling of SoC gurus everywhere-grows. The fastest of these high-speed links are so sensitive to external loads that they may be disabled by a change in solder composition or thickness. Probing them with anything short of an exposed-FET probe is hopeless. So even some critical I/O paths that cross chip boundaries may become unobservable at the system level.

But all that chip capacity brings good news, too. Joe Mendolia, technology evangelist for protocol testing experts Computer Access Technology Corp., pointed out recently that some forethought on the part of the chip design team can make a huge difference to system test. And this is not just in making sure that internal blocks in the IC get adequate coverage.

One case in point is those unprobable busses. It's often not inconvenient to provide a test mode on an SoC in which a fast high-speed bus is mirrored-perhaps even in parallel format-on other pins on the IC. In this way conventional board-test hardware can observe bus traffic without attempting to probe the fragile, impedance-balanced serial lines.

In a slightly more extreme case, simple logic analyzers, function generators and even whole protocol analyzers can be fabricated as blocks in the SoC. Such tools not only can be helpful for verification and test of the chip itself, but they can be invaluable for stimulating, observing and checking board-level or system-level connections that use complex protocols.

Today such devices are quite unusual, although the technology certainly exists to design them. But as conventional parallel backplanes give way to high-speed serial links with elaborate protocols, and as even chip-to-chip interconnect moves into the GHz region, on-chip analyzer resources may become key tools at the system level. Of course, for that to happen, the engineers responsible for system test will have to be represented in the chip design team from the beginning. That cultural change may be the hardest step in implementing this necessary advance.

Ron Wilson is editorial director of ISD Magazine and a contributor to EE Times. He has covered chip-related matters for 15 years for various industry publications, and was once, in the distant past, a designer himself.