The Boundary-Scan Handbook

The Boundary-Scan Handbook, by Kenneth P. Parker, contains a collection of design rules applied principally at the Integrated Circuit level that allow software to alleviate the growing cost of designing, producing and testing digital systems. Chapter 2 is tutorial in nature.

Find it on Amazon: http://www.amazon.com/Boundary-Scan-Handbook-Kenneth-P-Parker/dp/1402074964/ref=cm_cr_pr_product_top

Informational guide to IEEE 1149.1
Since the mid-1970s, the structural testing of the loaded printed circuit boards (PCBs) has relied very heavily on the use of the so-called in-circuit "bed-of-nails" technique. This method of testing makes use of a fixture containing a bed-of-nails to access individual devices on the board through test lands laid into the copper interconnect, or other convenient contact points. Testing then proceeds in two phases: the power-off tests followed by power-on tests. Power-off tests check the integrity of the physical contact between nail and the on-board access point. They then carry out open and shorts tests based on impedance measurements. Power-on tests apply stimulus to a chosen device on a board, with an accompanying measurement of the response from that device. Other devices that are electrically connected to the device-under-test (DUT) are usually placed into a safe state (a process called "guarding"). In this way, the tester is able to check the presence, orientation, and bonding of the DUT in place of the board.

Fundamentally, the in-circuit bed-of-nails technique relies on physical access to all devices on a board. Such was the technique in the mid-1980s when a group of concerned test engineers got together to examine the problem and its solutions. The method of solution was based on the concept of a serial shift register around the boundary of the device - hence the name "boundary scan".

Principles of Boundary Scan
Each primary input signal and primary output signal is supplemented with a multi-purpose memory element called a boundary-scan cell. Cells on device primary inputs are referred to as "input cells"; cells on the primary output are referred to as "output cells". The input and outputs is relative to the core logic of the device. The collection of the boundary cells is configured into a parallel-in, parallel-out shift register. A parallel load operation, called a "capture" operation, causes signal values on device input pins to be loaded into input cells and, signal values passing from the core logic to the device output pins to be loaded into output cells. A parallel unload operation called an "update" operation causes signal values already present in the output scan cells to be passes out through the device output pins. Signal values already present in the input scan cells will be passed into the core logic.

Data can also be shifted around the shift register, in serial mode, starting from a dedicated device input called TDI and terminating at a dedicated device output pin called TDO. The test clock TCK, is fed in via another dedicated device input pin and the mode of operation is controlled by a dedicated TMS serial control signal. At the device level, the boundary scan elements contribute nothing to the functionality of the core logic. In fact, the boundary scan path is independent of the function of the device. On board the four; boundary scan devices are connected from one to the next in a serial format. The TDI input to the board is connected to the TDI input of the first device; the TDO output of the first device is connected to the TDI input of the next device; and so forth; creating a global scan path terminating at the TDO connecter output. TCK is connected in parallel to each device, TMS the control pin works similarly.

In this way, particular tests can be applied to the device interconnects via the global scan path by loading the stimulus into the appropriate device output scan cells via the edge connecter TDI (shift-in operation), applying the stimulus (update operation), capturing the responses at the device input scan cells (capture operation), and shifting the response values out to the edge connector TDO (shift-out operation). Essentially the boundary scan cells can be thought of as the "virtual nail".

There are four modes to be aware of normal, update, capture, and serial shift. During normal mode, data_in is passed straight through to Data_out. During update mode, the content of the output register is passed through the Data_out. During capture mode, the Data_in signal is routed to the shift register and the value is captured by the next ClockDr state. During shift mode, the scan_out of the register flip flop is passed through to the scan_in of the next via a hard wired path.

What is BSDL?

The Boundary-Scan Description Language enables users to provide a description of the way in which boundary-scan is implemented in any particular device. As each chip designer tends to apply the boundary-scan standard in a slightly different way, it is necessary to express tests in a comprehensible, specific and usable fashion.

BSDL is written within a subset of VHDL. VHDL is commonly used as a design-entry language for FPGAs and ASICs in electronic design automation of digital circuits, and as such it is suitable for work with boundary-scan since design of many chips is performed using this language. However BSDL is a "subset and standard practice" of VHDL, i.e., the scope of VHDL is thereby limited for boundary-scan application.

During the design of BSDL there were two main criteria for the language:

• It should be easy to use
• It should be parsable by a computer in a simple and unambiguous fashion

BDSL enables accurate and useful descriptions of the features of a device that uses boundary-scan. The BSDL file is used by the boundary-scan tools to make use of the device features to enable test program generation, failure diagnosis, as well as use in any testability analysis. BSDL is not a language that can be used for hardware description; rather, it is used to define the data transport characteristics of the device, i.e. how it captures, shifts, and updates scanned data. This is then used in defining the test capability. The BSDL file includes the following data:

• Entity Declaration: The Entity Declaration is a VHDL construct that is used to identify the name of the device that is described by the BSDL file.
• Generic Parameter: The Generic Parameter is the section that specifies which package is described.
• Logical Port Description: This description lists all the connections on the device. It defines its basic attributes, i.e., whether the connection is an input (in bit;), output (out bit;), bi-directional (inout bit;) or if it is unavailable for boundary-scan (linkage bit;).
• Package Pin Mapping: The Package Pin Mapping is used for determining the internal connections within an integrated circuit. It details how the pads on the device die are wired to the external pins.
• Use Statements: This statement is used to call the VHDL packages that contain the data that are referenced in the BSDL File.
• Scan Port Identification: The Scan Port Identification identifies the particular pins that are used for the boundary-scan / JTAG implementation. These include: TDI, TDO, TMS, TCK and TRST (if used).
• Test Access Port (TAP) Description: This entity provides additional information on the boundary-scan or JTAG logic for the device. The data includes the instruction register length, instruction opcodes, device IDCODE, etc.
• Boundary Register Description: This description provides the structure of the boundary-scan cells on the device. Each pin on a device may have up to three boundary-scan cells, each cell consisting of a register and a latch.

Source: BSDL Tutorial

History of BSDL; Definition

JTAG Boundary-scan is a well established test technology. JTAG Boundary-scan has been in use since the early 1990s when the Joint Test Action Group (JTAG) devised a solution to testing the many new printed circuit boards that were being developed and manufactured where there was little or no physical access for test probes. Once boundary-scan was established, the next step was to develop a standard modeling language for silicon vendors to model their boundary-scan devices, for tool vendors to develop automation tools, and for end-users to create boundary-scan tests. Thus the Boundary-Scan Description Language (BSDL) was created.

BSDL is the standard modeling language for boundary-scan devices. Its syntax is a subset of VHDL and it complies with IEEE 1149.1-2001. It is used by boundary-scan test developers, device simulators, semiconductor testers, board level testers, and anyone using boundary-scan. The use of BSDL promotes consistency throughout the electronics industry. Additionally, it enables the specification of any boundary-scan functions on a device in a useful, understandable, and consistent manner.

BSDL came out of the development of the boundary-scan test philosophy. The initial IEEE 1149.1-1990 standard describing boundary-scan was approved and released in 1990, and as a result the use of boundary-scan techniques started to grow. The next revision of the standard occurred in 1993. In 1994 a further revision incorporated BSDL into the IEEE 1149.1-1994 standard.

Source: TI Wiki

Differential Signals and JTAG Boundary Scan

IEEE 1149.6
AC-coupled differential interconnections on very high speed (1+ Gbps) data paths are not testable using traditional IEEE 1149.1 techniques. The IEEE 1149.1 structures and methods are intended to test static (DC-coupled), single ended networks. IEEE 1149.6 is specifically designed for testing high speed differential, including AC coupled networks.


PCI Express Signalling/Connector Testing Support
JTAG Boundary-scan testing of PCIe connectors is pretty much out of the question. The PCIe differential signals are capacitively coupled so the boundary-scan devices on both sides of the PCIe connector would have to have some kind of dot6 compliant cells to test through the series capacitor. All of the boundary-scan compatible chips with PCIe interfaces that I saw had the PCIe signals specified as linkage bits so they wouldn't be testable anyway. If the customer has a specific device that needs to be tested we can look at the bsdl file to see if anything can be done.
We may be able to run software on the chips on both sides of the PCIe connector and test the link functionally (note that the link speed is 2.5Gb/s!!!).

Questions about JTAG Boundary Scan?

JTAG: What topics interest you or would you like to read about? Comments?

IEEE Standard

You can obtain a copy of the IEEE standard from http://www.ieee.org/.

The IEEE Std 1149.1-1990 - Test Access Port and Boundary-Scan Architecture, and the Std 1149.1-1994b - Supplement to IEEE Std 1149.1-1990, are available from:

IEEE Inc., 345 East 47th Street, New York, NY 10017, USA

1-800-678-IEEE (USA)

1-908-981-9667 (Outside of USA)

Applying JTAG

Applying JTAG for Field Service

Once a product ships, the role of JTAG does not end. Periodic software and hardware updates can be performed remotely using the JTAG chain as a non-intrusive access mechanism. This allows Flash ROM updates and reprogramming of programmable logic for example. Service centers that normally would not want to invest in special support equipment to support a product, now have an option of using a standard PC or lap-top for JTAG testing. A simple PC based JTAG controller can be used for all of the above tasks and also double as a fault diagnostic system, using the exact same test vectors that were developed during the design and production phase. This concept can be taken one step further by allowing an embedded processor access to the JTAG chain. This allows diagnostics and fault isolation to be performed by the embedded processor. The same diagnostic routines can be run as part of a power-on self-test procedure.

JTAG for Production Test

Applying JTAG for Production Test

Production test, utilizing traditional In-Circuit Testers that do not have JTAG features installed, experience similar problems that the product developer had and more:

• Loss of Physical Access to fine pitch components such as SMTs and BGAs reduces Bed-of-Nails In-Circuit Testers (ICT) fault isolation.
  
  
• Development of test fixtures for ICTs has become longer and more expensive.
  
  
• Development of test procedures for ICTs has become longer and more expensive due to more complex Ics.
  
  
• Designer is forced to bring out a large number of test points, which is in direct conflict with his goals to miniaturize the design.
  
  
• In-system programming is inherently slow, inefficient, and expensive if done with an ICT.
  
  
• Assembling boards with BGAs is difficult and subject to numerous defects such as solder smearing.
  

Figure 7 shows a typical production flow configuration that includes a JTAG tester that tests all the interconnects between the UUT digital components and performs in-circuit programming of all the CPLDs and Flash memories. Some test engineers complement the JTAG test with an ICT that requires simpler fixture primarily testing the analog components.


Figure 7 - Typical Production Flow Configuration


Following the ICT analog tests, a comprehensive at-speed functional test is performed before the product is shipped. However, in many cases, test engineers are skipping the ICT test and moving from JTAG interconnect test to a functional test that includes thorough testing of the analog portion of the product.

The following are major benefits in using JTAG test and ISP in production:

• No need for test fixtures.
  
  
• Integrates product development, production test, and device programming in one tool/system.
  
  
• Engineering test and programming data is reused in Production.
  
  
• Fast test procedure development.
  
  
• Preproduction testing can start the next day when prototype is released to production.
  
  
• Dramatically reduces inventory management – no pre-programmed parts eliminates device handling and ESD damage.
  
  
• Eliminates or reduces ICT usage time – programming and screening.
  

Production test is an obvious area in which the use of JTAG yields tremendous returns. Automatic test program generation and fault diagnostics using JTAG software products and the lack of expensive fixturing requirements can make the entire test process very economical. For products that contain edge connectors and digital interfaces that are not visible from the JTAG chain, JTAG vendors offer a family of JTAG controllable I/Os that provide a low cost alternative to expensive digital pin electronics.

JTAG Tools

Why are JTAG Tools needed?

In the previous paragraph we listed all the benefits that a designer enjoys when using boundary-scan in his product development. In this section we will describe the tools and design data needed to develop JTAG test procedures and patterns for in-circuit programming. We will use a typical board as an illustration for the various JTAG test functions needed. A block diagram of such a board is depicted in Figure 4.



Figure 4 - Typical Board with JTAG Components


A typical digital board with JTAG devices includes the following main components:

• Various JTAG components such as CPLDs, FPGAs, Processors, etc., chained together via the boundary-scan path.
  
  
• Non-JTAG components (clusters).
  
  
• Various types of memory devices.
  
  
• Flash Memory components.
  
  
• Transparent components such as series resistors or buffers.
  

The following will introduce you to the major components of the various JTAG test tools available followed by a description of how to test and program the above board.

A typical boundary-scan test system is comprised of two basic elements: Test Program Generation and Test Execution. Generally the Test Program Generator (TPG) requires the netlist of the Unit Under Test (UUT) and the BSDL files of the JTAG components. The TPG automatically generates test patterns that allow fault detection and isolation for all JTAG testable nets of the printed circuit board (PCB). The TPG also creates test vectors to detect faults on the pins of non-scannable components such as clusters and memories that are surrounded by scannable devices.

Corelis TPGs also provide the user with a test coverage report, that allows the user to focus on the non-testable nets and determine what additional means are needed to increase the test coverage.

Test programs are generated in seconds. For example when Corelis ScanPlusExpressTPG was used, it took a 200MHz Pentium PC eight (8) seconds to generate an interconnect test for a UUT with 4,090 nets (with17,500 pins). This generation time includes netlist and all other input files processing, as well as test pattern file generation.

The test execution tool provides means for executing JTAG tests and perform in-circuit-programming in a pre-planned specific order called a test plan. Test vectors files, which have been generated using the TPG, are automatically applied to the UUT and the results are compared to the expected values. In case of a detected fault, the system diagnoses the fault and lists the failures as depicted in Figure 6. Different test plans may be constructed for different UUTs. Tests within a test plan may be re-ordered, enabled or disabled, and unlimited different tests can be combined into a test plan. Corelis test execution tool (ScanPlus Runner) also includes a test executive that is used to develop a test sequence or test plan from various independent sub tests. These sub tests can then be executed sequentially as many times as specified or continuously if desired. A sub test can also program CPLDs and Flash memories. For in-circuit programming other formats such as SVF, JAM, J-Drive and STAPL are also supported.

Figure 5 shows the ScanPlus Runner main window. As can be seen, ScanPlus Runner gives a user an overview of all test steps and the results of executed tests. These results are displayed both for individual tests as well as for the total test runs executed. ScanPlus Runner provides the ability to add or delete various test steps from a test plan, or re-arrange the order of the test steps in a plan. Tests can also be enabled or disabled, and the test execution can be stopped upon the failure of any particular test.

To test the board depicted in Figure 4, the user must execute a test plan that consists of various test steps as shown in Figure 5.


Figure 5 - ScanPlus Runner Main Window

The first and most important test is the scan-chain integrity test. The scan chain must work correctly prior to proceeding to other tests and in-system programming. Following a successful testing of the scan chain, the user can proceed to testing all the interconnects between the JTAG components. If the interconnect test fails, the ScanPlus Runner will display a diagnostic screen that will identify the type of the failure (such as stuck at, Bridge, Open) and will list the failing nets and pins as shown in Figure 6. Once the interconnect test passes, including the testing of transparent components, it makes sense to continue testing the clusters and the memory devices. At this stage the system is ready for in-circuit programming that usually is takes more time compared to the testing.


Figure 6 - ScanPlus Runner Diagnostics Display

During the design phase of a product, some JTAG vendors will provide design assistance in selecting JTAG compatible components, work with the developers to ensure that the proper BSDL (Boundary-scan Description Language) files are used, and provide advice in designing the product for testability.

Applying JTAG for Product Development

Product Development

Recent marketing drive for reduced product size, such as portable phones and digital cameras, higher functional integration, faster clock rates, shorter product life-cycle with dramatically faster time to market, has created new technology trends. These new technology trends include increased device complexity, fine pitch components such as SMTs, MCMs, and BGAs, increased IC-pin count, and smaller PCB traces. This has created the following problems in product development:

• Many boards include components that are assembled on both sides of the board. Most of the through-holes and traces are buried and inaccessible.
  
  
• Loss of Physical Access to fine pitch components such as SMTs and BGAs makes it difficult to probe the pins and distinguish between manufacturing and design problems.
  
  
• A prototype assembly is usually done by a small prototype assembly shop, in rush, with lower quality control as compared to a production house. A prototype generally will include more assembly defects than a production unit.
  
  
• When the prototype arrives, a test fixture for the In-Circuit- Tester (ICT) is not available and therefore manufacturing defects can not be easily detected and isolated.
  
  
• Small-size products do not have test points which makes it difficult or impossible to probe suspected nodes.
  
  
• Many Complex Programmable Logic Devices (CPLDs) and Flash devices (in BGA packages) are not socketed and are soldered directly to the board.
  
  
• Every time an engineer selects a new processor or a different flash device, he has to learn from scratch how to program the Flash memory
  
  
• When a design includes CPLDs from different vendors, the engineer must use different in-circuit programmers to program the CPLDs.
  

JTAG technology is the only cost effective solution that can deal with the above problems. In the last few years, the number of devices that include JTAG has grown exponentially. Almost every new microprocessor that is being introduced includes JTAG circuitry for testing and in-circuit emulation. Most of the CPLDs and FPGAs manufacturers such as Altera, Lattice, and Xilinx, to mention a few, have incorporated JTAG logic into their components including additional circuitry that uses the JTAG 4-wire interface to program their devices in-system.

As the acceptance of JTAG as the main technology for interconnect testing and in-circuit programming has increased, the various JTAG test and in-system programming tools have matured as well. The increased number of JTAG components and mature JTAG tools, as well as other factors that will be described later, provide engineers with the following benefits:

• Easy to implement Design For Testability (DFT) Rules. A list of basic DFT rules is provided later in this article.
  
  
• Testability report prior to PCB layout enhances DFT.
  
  
• Find packaging problems prior to PCB layout.
  
  
• Little need for test points.
  
  
• No need for test fixtures.
  
  
• More control over the test process.
  
  
• Quickly diagnose (with high resolution) interconnect problems without writing any functional test code.
  
  
• Program code in flash devices.
  
  
• Put design configuration data into CPLDs.
  
  
• JTAG emulation and source-level debugging.
  

The Digital Electronics Blog

Visit http://digitalelectronics.blogspot.com/ to find out information on upcoming electronics design conferences hosting organizations and agencies like IEEE, ACM, EDA, Joint Test Action Group, and more.

Digital Electronics Blog also provides information on new electronics technologies and career opening in the electronics industry. They provide a weblog about digital electronics, with industry news and short tutorials on VHDL , Verilog, timing and low power design, among other topics.