How to test high-speed memory with non-intrusive embedded instruments, Part 2
Having explained in part 1 the nature of the memory test challenge in the industry today, this article discusses non-intrusive debug and test methods based on embedded instruments and how these methods can meet the challenges that design and manufacturing engineers are encountering.
Many test engineers are turning to several non-intrusive debug and test technologies to characterize and test today’s high-speed memory architectures on circuit boards. The following basic diagram (see Figure 1) with minor variations will be used throughout the rest of this paper to illustrate how non-intrusive board test (NBT) methods can be deployed in memory test.
Although memory chips typically do not conform to the boundary-scan standard (IEEE 1149.1 JTAG) – meaning they do not have a 1149.1 test access port (TAP) or dedicated boundary-scan registers on-chip – they can be tested from the boundary-scan facilities of a connected device, such as a memory management unit (MMU) or a microprocessor if there is power, clock, and access to the 1149.1 TAP at the board level. The boundary-scan registers on a MMU (see Figure 2) can be appropriated and directed to test the shorts and opens on the interconnect routes to the memories. In some cases, boundary-scan test (BST) may be the only alternative to test these interconnects, especially when the test probes and bed-of-nail fixtures that are essential to scopes and in-circuit test (ICT) systems do not have access to the memories because there are no or only a few test pads on the board.
When the boundary scan registers of a connected device are used to test memory interconnects, algorithmic writes and reads are executed on memory locations in particular sequences. The more complex the test algorithm, the longer the testing will take because a boundary-scan ‘scan operation’ (ScanDR) must be conducted for each read or write. In many cases, if multiple Read, Write, Stall, Output_Enable and other control signals must be operated at different times to make up the test, then multiple ScanDRs must be conducted to operate those signals in the proper sequence for each read or write action.
Figure 2 shows that a memory management unit with a boundary-scan TAP can be used to test the memory devices to which it is connected for specific faults, such as those defined by the commonly used PCOL/SOQ board test fault spectrum. In this case, shorts or opens have disrupted the interconnect to the first DRAM device, the next DRAM does not have power, another is missing and the last memory device is the wrong type of memory and its orientation is incorrect. (PCOLA/SOQ is a fault spectrum originally defined by Agilent Technologies ).
In addition, the rate and efficiency at which boundary-scan tests can be applied to memory buses will be limited to the clock speed of boundary scan (for example, 50 MHz may be the maximum boundary-scan clock speed) and the length of the board’s boundary scan register. These factors could cause lengthy test times. Moreover, multiple scans typically comprise a memory test. When each scan can only be applied at a slow speed, the time needed to apply an entire memory test made up of multiple scans can become extensive.
In some cases where the memory architecture consists of very fast memory, such as DDR3 or DDR4, the overall scan-in and update speed of the boundary scan register is not fast enough to meet the minimum speed required by the memory chips to conduct a valid read or write. Because its test times will be longer, boundary scan is usually best suited to designs with slower memory buses or when boundary scan is the only alternative for memory test. When this is the case, boundary scan is a feasible alternative for testing memory interconnects as opposed to performing full memory cell testing.
Some test teams decide to perform the most basic and well-understood type of non-intrusive test -- functional test -- on a circuit board to test memory buses. Unfortunately, functional tests can only be applied when the board’s BIOS (basic input/output system) or the firmware contained in its board support package (BSP), as well as its operating system are all functional. In addition, this will require fully integrated firmware in all on-board FPGAs, flash memories, and the proper configuration loaded into the MMU. At the very least, this base level of software will be needed to apply functional test routines on memory buses.
The inability to test prototype hardware independently of its basic software environment increases the risks to the timing of a new product introduction since, most often, software is only integrated into a design late in the design cycle. Difficulties at this point would likely extend the design phase and make the new product late to market. If the test team must wait for the design’s base level of functional software, the risk of a late entry increases. In addition, identifying design problems late in the development cycle can result in increased rework costs.
Functional memory tests must be developed by an expert programmer who is very knowledgeable of the hardware issues of the microprocessor and board, including how the memory buses and memory devices function, as well as sophisticated software programming techniques. In the end, the validity of a functional memory test is limited by the expertise of the person developing it. Moreover, memory buses could pass a functional test, but the test itself might not exercise all of the required aspects of the memory bus for structural or manufacturing defects. If this were the case, the functional memory test would merely prove that a certain sequence of reads and writes can occur without faults, given a known set of environmental conditions.