Home>Manufacturing Test Center>Test How-To

How to test high-speed memory with non-intrusive embedded instruments, part 3

Alfred Crouch- October 9, 2012

The first article in this series explains the nature of the memory test challenge in the industry today. The second article in this three-part series on memory test described several non-intrusive debug and test technologies, including  functional test, processor-controlled test,boundary-scan test, FPGA-controlled test and others. Beginning with functional test, this, the final article in the series, takes a closer look at the tradeoffs among the non-intrusive methods and discusses how they have been implemented in the industry.  

Functional test has also been applied to memories for years, but it can only be brought to bear late in the development cycle when the board is fully functional or close to fully functional. As a result, functional tests are very difficult to apply to boards with a problem, bug, defect or error. Functional tests typically are applied with the board in a test jig or when the board is in a fully configured system. In addition, their diagnostic granularity may be very limited.

More recently, third-party pseudo-functional test tools have been able to overcome many of the difficulties of classic functional test and reduce the risks that a test development process late in the design cycle typically poses. For example, processor-controlled test (PCT) tools for embedded instruments apply pseudo-functional test routines independently of the board’s functional firmware or operating software.  PCT test routines can be applied by a processor without requiring a functional firmware environment.  PCT tools appropriate the processor’s capabilities by way of its debug port. If the processor is connected directly to on-board memory,  a PCT tool can apply its pseudo-functional test routines originating from the processor to test memory. As a result, test teams can apply pseudo-functional memory tests during the early stages of board bring-up without having to wait for the design’s operating firmware. In addition, the validity and comprehensive nature of PCT’s test routines have been verified over many different designs from many board manufacturers. The comprehensiveness of PCT’s memory test routines have themselves been fully field tested.

Memory has been tested with standalone boundary-scan (IEEE 1149.1/ JTAG) testers for more than a decade. Currently though, certain new memories may be outpacing the ability of board-level boundary scan since the minimum clock and data rates of the memory devices may exceed the maximum board test clock frequency (TCK) of boundary scan. So, for modern high-speed designs, the application of boundary-scan test (BST) as a tool for memory test may be limited, but only time will tell.

FPGA-controlled test (FCT) tools are emerging as an attractive alternative for debugging and testing memory.  Borrowing a functional FPGA on a board as the basis for testing memory  during prototype board bring-up and manufacturing has been implemented for years, but each such implementation has been developed by the board test provider and each test suite typically involves custom or functional development of test instruments and custom access protocols. The difficulty here is that the instruments embedded in the FPGAs are custom crafted for each board design with no, or limited, intended re-use.

In some cases, developing the embedded instruments is as daunting a design task as developing the device’s functional firmware. In addition, the individual instruments that make up a multi-instrument tester embedded in an FPGA must be controlled and operated by design or test engineers. This would necessitate the development of an operating system for the embedded tester. Lastly, inserting and removing a multi-instrument tester from an FPGA must be a simple, straightforward process since most manufacturing board test engineers are typically not familiar with FPGA instrument insertion and other test-related operations.

Some FCT toolkits have been based on an open industry standard for embedded instruments, the IEEE P1687 Internal JTAG (IJTAG) standard which accesses board designs through the IEEE 1149.1 boundary-scan (JTAG) infrastructure. (The IJTAG standard is expected to be ratified this year.) The IJTAG access architecture is ideal for the purposes of FCT because the new standard’s procedural control language (PCL) acts as an application programming interface (API) for the embedded tester instruments. Since PDL can represent fully defined and reusable operating routines, an FCT tool based on the IJTAG standard can act as the operating system for a multi-instrument tester embedded in an FPGA.

Using an ASIC or SoC with embedded instruments that have been made public by the chip provider requires a tool environment that can read not only Boundary-Scan Description Language (BSDL), but other documentation files such as IEEE 1500’s Core Test Language (CTL) and then subsequently manage the operation of the embedded instruments. Since the instruments embedded in ASICs, SoCs and other chips often may be accessed by a combination of boundary scan (IEEE 1149.1), IEEE 1500 and IEEE P1687 IJTAG, a tool environment that can operate architectures based on all three standards would be preferable.

And finally, microprocessor- or chipset-based MBIST instruments can be deployed to validate memory buses, but typically this method can only be employed when the supplier of the processor has already embedded the MBIST instruments. In the case of Intel’s IBIST embedded test technology, for example, a third-party toolkit is available which can apply IBIST’s MBIST engines to validate the performance of certain high-speed memory buses, such as the DDR3 bus in designs based on the processors codenamed Nehalem, Sandy Bridge and Ivy Bridge. This toolkit accesses the embedded IBIST test technology to drive patterns onto the DDR3 bus. These patterns form the basis for tests that verify the read/write capabilities of the memory bus, perform margin testing and execute bit error rate tests (BERT).

>>Tradeoffs