The test coverage achievable on a board/module or system with Boundary Scan depends on the available Boundary Scan resources (e.g. type and number of Boundary Scan cells connected to a particular net) as well as on the implementation of design for testability considerations at the board and system level.
- Necessary sequential logic should be packed into a FPGA/(C)PLD with IEEE 1149.1 testability features.
- In case of non-BScan FPGA or PLD, consider to download a (BScan) test configuration temporarily (if they support in-system programming).
- All highly complex devices like ASIC, PLD, DSP or microprocessors, etc. should have BScan.
- When you have a choice, use BScan versions rather than non-BScan versions of a component (e.g. there are BScan testable SRAM devices and FIFO devices on the market available today).
- If each port of an on-board buffer is connected to BScan devices or to edge connector, the device itself is not required to be scanable (it is a “transparent cluster”).
- Use of some bytes of FLASH to record board history is an excellent QMS (Quality Management System) approach (e.g. type of board, release, production date, count of repair cycles, etc). This device should be accessible via Boundary Scan.
- To accelerate FLASH programming you might want to provide access to WE signals at edge connectors. This allows additional I/O resources not requiring extra scan cycles for each change at WE to control these signals.
- If frequent downloads of firmware into FLASH or FPGA or selftests at system boot-up are required (in production and/or field) a separate on-board test bus controller makes sense. Such controllers are available from TI, NSC, Firecron, and others.
- Identify components that support device level emulation/test and utilize the TAP to access these resources. BIST (Built-In Self Test) often times provides for dynamical tests otherwise not achievable with Boundary Scan.
- If analogue functions have to be designed in, (digital) Boundary Scan should be placed close to the digital interface. Think about utilizing IEEE 1149.4.
- For Boundary Scan the board has to be powered-up. Remember that when designing boards containing devices that require cooling blocks or active cooling.
- If control signals of non-BScan components are fixed to VCC or GND, use pull resistors to do so (rather than directly tying the pins to VCC or GND), so that an outside source can “overdrive” the pull condition.
- If BScan capable PLD or FPGA device pins are not used, consider routing them to test points or to nets that otherwise would not be accessible via Boundary Scan. This will increase test coverage and maybe even the testability of the UUT. Also consider using such pins to add control over non-BScan devices and clock circuitry. Make sure, though, that such pins are not toggled when the FPGA/PLD is in functional mode.
- Consider loop-back connections on peripheral connectors between two BScan nets if the on board BScan resources in those nets are limited (avoid “masking” of faults such as shorts between neighbouring pins, though). This includes the connector pins in the test and may even make otherwise not testable nets testable. Alternatively, consider using off-board BScan resources to be connected to the peripheral connector.
