Boundary scan emerges as popular tool for design engineers
4 mins read
Boundary scan is becoming a useful tool for design engineers. As the development of Design and Test automation tools continues apace, then so too does the convergence of the disciplines that utilise these sophisticated software systems.
![](/media/lk2boiho/boundary.jpg?width=1002&height=564&bgcolor=White&v=1d9d7643338c440)
JTAG/Boundary-scan developer tools for example have always been at the forefront of board-level DfT technologies and today the link between EDA and pcb test development is closer than ever.
This article will consider how EDA and automated test development software and their users interact at the following levels:
• Connection data (Netlist) import for board level connectivity testing
• Schematic data - import for fault coverage review and guard point setting
• Board layout data - import for improved, faster fault finding and fault coverage review
Furthermore we will also look at how device-level debug mechanisms can now be utilised by the test engineering community to enhance their manufacturing fault screening.
Use of connectivity data
All schematic entry (drawing) systems are used to draw circuits and create an interconnection table (netlist) that can be used by downstream tools such as board layout systems and manufacturing and test tools.
Boundary-scan test systems such as JTAG Technologies' ProVision allow the import of many different netlist types, principally from schematics but also from down-stream systems such as board layout or CAM (Computer Aided Manufacturing) tools. By analysing connectivity data in conjunction with component models (including the boundary scan description language (BSDL) test description models) it is possible to get an early indicator of fault coverage using JTAG/Boundary-scan. The software that comes with JTAG Technologies' ProVision boundary scan system, for example, includes a fault coverage analyser that provides two outputs listing a) predicted and b) actual fault coverage.
The predicated coverage report is derived from only the basic raw inputs (Netlist(s), device models and BSDLs) and makes assumptions regarding I/O access to connectors and test-points.
Actual coverage on the other hand is derived following an analysis of individual pcb tests that have been created - typically these will include Scan path infrastructure, bscan-to-bscan pin interconnects, memory tests and logic cluster tests. Most importantly the automated test tool offers a second screening for the schematic data and also offers an opportunity for the designer to 'tweak' design aspects for optimal test coverage.
Schematic viewing and probing
Importing fuller EDA data including component symbols into test tools offers a number of further advantages for the engineer responsible for pcb test.
Professional-level test tools that can support a schematic viewer 'plug-in' module should also be able to overlay fault coverage data on to the schematics. By highlighting fault coverage differences using a colour coding system it is easy to get an 'at a glance view' of the pcb sectors that are being fully tested and those which may require further attention.
Figure 1 shows a pcb with 100% (all nodes) test coverage highlighted in white for example. Interactive schematic viewers with links back to boundary control software also allow an instant continuity or 'Buzz' test direct from the schematic screen – making this a great companion tool for the hardware engineer during prototype debug. For the test development engineer the ability to set guarding values (fixed drive and sense points) on a circuit node) from a schematic view also offers considerable benefits.
Interacting with board layouts
In addition to schematic views, modern test tools can often also import board layout information in numerous formats, from the now ubiquitous ODB++ to proprietary formats from EDA tool vendors such as Cadence, Mentor, Zuken and Altium.
In the boundary-scan domain, pcb tests that fail and are subsequently diagnosed as a net-level or pin-level faults, can be linked into the layout view and highlighted or zoomed-to (see figure 2). Individual layers can be stripped-off as required and the pcb can even be viewed 'flipped' or from the underside to aid speedy diagnosis. Moreover fault analysis data can once again be overlaid onto the layout view.
IC-level Tools
Over its 20+ year history JTAG/boundary-scan has been associated principally with board-level testing. However in recent years JTAG test tool vendors have also seized upon additional features embedded within devices (ICs) that were not initially envisaged for testing.
In microprocessors for example, the JTAG interface is often used to access not only the boundary-scan test register, but also internal registers included to exercise on-chip debug (OCD) modes. Given access to the OCD features, engineers responsible for test can create more sophisticated tests using many more of the modules embedded within the microcontroller (figure 3).
Low cost 'core commander' routines greatly simplify this method and allow use of open source Python code to compose re-usable test modules.
A further example of the way in which design and test tools/technologies are now merging is in the use of JTAG access within the core of an fpga.
Most fpga vendors now provide a resource (so-called megafunction) that will provide a bridge between the standard JTAG (IEEE 1149.1) TAP and the gate array fabric. Thus with some experience of the vendor design tools (Altera's Quartus or Xilinx's ISE for example) engineers responsible for test can construct specific test IP that can be triggered via the JTAG port.
In February 2013 JTAG Technologies extended this methodology by introducing a generic translator block that links the vendors JTAG <=> fabric bridge to standard embedded busses such as Wishbone, AMBA, Avalon and CoreConnect. In this way engineers can utilise standard IP blocks (e.g. DDR controllers. E-net MAC, CAN bus interfaces etc.) for test purposes by linking them back to the JTAG port. In design also, engineers can use this technique to test out the effectiveness of the IP in question before adding it to the final fpga design.
In conclusion it is commonly found in smaller enterprises that the engineer responsible for test is also the hardware designer. In these circumstances it is not uncommon for this person to wish to 'leverage' their design skills and efforts for manufacturing test purposes. Test tool companies are now responding to this requirement and are providing many more features that allow the transfer of data and IP from design to test.
James Stanbridge is UK Sales Manager for JTAG Technologies.