Boundary-Scan Testing of Memories, and output2 Cells

A customer found that their older ICT-based boundary-scan test tool was creating bus contention during memory testing. Let the buyer beware!

Most memory devices are not boundary-scan compatible, which limits traditional interconnect testing. However, you can work around this by using a facility known as โ€œmemory access verificationโ€, or MAV for short. Running MAV tests verifies the interconnections between boundary-scan devices and non-boundary-scan memory devices by writing data patterns to the memory and then verifying the patterns can be read back properly.

Seems simple, right? Well, it is, but with some caveats. The board design must accommodate having control (including clock), address and data lines all accessible from boundary-scan devices. The memories need to be able to handle the slower JTAG-speed TCK-based clock. And in RDIMM (registered DIMM) based designs, the PLL is on the DIMM itself, and canโ€™t be controlled directly from a boundary-scan device, so MAV wonโ€™t work.

Presuming that the above are taken care of, itโ€™s still important to have the boundary-scan test tool understand the potential limitations of the boundary scan cell implementation on the memory controller. For example, on one design, the scannable device had the strobes (DQS signals) supported by boundary scan cells of function output2:

Output2
In normal MAV operation, the DQS and the DQSN pins are driven to the memory during a WRITE cycle and driven from the memory during a READ cycle. During the READ cycle, the strobes need to be disabled. But, cells of type output2 lack the additional control cell which would give the boundary register control over the output enables of the driver. So, MAV cannot be used if the strobes are of type output2. With our help, the customer found that their previous In-Circuit Test-based boundary-scan tool was in fact attempting to disable the strobes, and then proceeding with the MAV test. The result was DQS contention, which can damage the device, especially if it were backdriven for an extended period of time. This could contribute to system performance degradation and, ultimately, system failure.