Package-on-Package (PoP) handling with ScanExpress Boundary-scan Tools

Introduction
Package-on-package (PoP), a method to stack discrete packages vertically, has over the last few years gained significant popularity with applications processors such as Texas Instruments OMAP and DaVinci DM37x series SOCs. As with many space-saving design techniques, implementing PoP can often result in loss of physical test access since connections between the bottom and top devices are inaccessible to probes, making boundary-scan ideal for testing the interfaces.

To make matters worse, not all design engineers define a PoP interface the same way—some may choose to define each net in the schematic/netlist, while others may consider interconnections to be implied and outside the scope of the PCB design files. Many designers will define the PoP connections outside of the PCB files, leaving automated tools without an interface definition.

Let’s take a look at a few cases and how to set up ScanExpress tools for projects that include PoP components based on different possibilities.

Figure 1: Processors with PoP interfaces include interconnections on the top and bottom
Before You Start: Check for Boundary-scan Access!
Not all CPUs include boundary-scan cells on the PoP interface. For example, the TI DM3725 CBP and CBC packages offer no boundary-scan access on the top RAM interface. It’s always a good idea to check the BSDL first and make sure that boundary-scan is supported on a particular set of pins before going deep into test development.

To verify boundary-scan capability, open up the BSDL and search for a few PoP pins. Make sure that the pin in the BSDL file is associated with a digital port and that the port is associated with cells in the boundary-scan register (BSR). If the component is a synchronous memory device, start with the clock—clock pins are the most likely pin to be left out of the BSR due to high speed requirements and on-chip PLLs that limit boundary-scan capability.

Handling Common Cases
Keep in mind that not all design files will define the PoP interface in the same way. Some designers may choose to leave any reference to the PoP interface out of the system schematic and netlist—this makes complete sense considering the way PCBs have traditionally been defined and built, but unfortunately makes test definition more difficult for the test engineer.

Case 1: PoP Defined in the Netlist
If the PoP interface is fully described in the system netlist, then you’re in luck—the tedious work was already done! Setting up the test should be a simple process to associate a BSDL file with the CPU and associate an appropriate model with the PoP device. ScanExpress TPG will treat the top balls on the PoP just like other board interconnects and generate tests accordingly to catch opens, shorts, and bridging faults wherever possible.

Case 2: PoP Not Defined
In some cases, the PoP interconnect and device definitions will be left out of the netlist entirely and the test engineer not be provided an external netlist or connection list. In these situations, there are two main approaches with ScanExpress Tools:

Edit the original netlist directly to add the PoP-to-peripheral connections, then use the edited netlist to create a ScanExpress project.
Use ScanExpress netlist edit commands to define the connections between the CPU and peripheral. This may include a mix of ADD_NODE, ADD_NET, and sometimes MERGE_NET commands.

For example, let’s say that applications processor U1 has a PoP interface populated by device U10, as shown below. The schematic and Netlist have no reference to U10 or the PoP pins on U1.

Figure 2: PoP & PCB Interface Interconnections
Using approach #1, we can edit the source netlist to add the additional net definitions. Editing the netlist directly has the advantage of making the nets available to the TPG preparation flow immediately and allowing these nets to be used in the scripting engine. The disadvantage is that it requires modifying the source netlist, which may or may not be an acceptable method.

A good text editor with block edit capabilities such as TextPad can make editing the netlist easy. Since the interface is one-to-one, each pin can be copied and pasted to form the net. For example, the new nets might look something like this:

Code:
$NETS
‘POP_NET_T1’ ; U1.T1 U10.T1
‘POP_NET_T2’ ; U1.T2 U10.T2
‘POP_NET_T3’ ; U1.T3 U10.T3

Note: If a netlist detailing the PoP interface is available, ScanExpress Merge may be used to combine the two netlists. Make sure that the reference designator for the boundary-scan device is the same in both netlists and turn of the “Add Prefix” option.

Using approach #2, we will be adding netlist edit commands within TPG. This leaves the netlist file itself untouched, but takes a bit more definition and does not make the new nets available to the scripting engine. Keep in mind also that netlist edit commands are processed by the TPG generation engine and not the preparation engine, meaning any model associations will need to be done manually by editing input files. For example, we could add something like the following to the EDT file:

Code:
ADD_NET POP_NET_T1
ADD_NET POP_NET_T2
ADD_NET POP_NET_T3
ADD_NODE U1.T1 U10.T1 POP_NET_T1
ADD_NODE U1.T2 U10.T2 POP_NET_T2
ADD_NODE U1.T3 U10.T3 POP_NET_T3

Conclusion
Beyond PoP, we expect to see more 2.5D and 3D techniques come into play in the next few years. If you have a design that uses PoP, 2.5D, 3D, or any difficult packaging method either at the board or chip level, let us know! Insight into your latest design developments helps us make sure ScanExpress tools remain easy to use for all possible UUT designs.