Try to define one scan path on the board. Several scan paths are only necessary in case of compliance problems or if slower (TCK) rated devices would slow down a scan chain that is needed for In-System Programming and/or Memory Cluster Testing.
- Keep devices with special JTAG interface for emulation in separate scan chains. Some emulation tools do not work properly when components other than the target device are in the scan chain.
- To allow for system level test, consider the use special test bus handler like TI’s Scan Path Linker and ASP [www.ti.com] or NSC’s SCANBridge [www.national.com], or similar devices from Firecron [www.firecron.com], Lattice and others.
- Connect all IEEE-1149.1 compliant devices to one or more Boundary Scan chains, so that they are accessible from the outside via test bus connector(s). Exclusive test bus connectivity by nails should be avoided (to be able to test/program without nail-access). Provide a test bus connector/header.
- If non-compliant devices are on the board, provide means to bypass them, e.g. via jumpers or zero-ohm resistors (at least TMS and TDI – and perhaps TDO – should be disconnected if a device is to be bypassed).
- Test bus signals TCK, TMS, /TRST, TDI and TDO should have test pads for fine diagnosis by a probe in case of shorts to other nets or to find opens.
- Consider buffering the test bus signals on the UUT at the test bus header. Make sure the buffer can be enabled for boundary scan access (either via pull resistor or accessible to outside control via connector). Make sure not to use inverting buffers.
- If BScan device families with different voltage levels are used in a scan chain, make sure to implement level shifting capabilities (e.g. via pull resistors or integrated level shifters).
- If assembly variations are planned make sure the scan chain can be closed for non-assembled devices and/or mezzanine module.
