Design for Testability and Extended Boundary ... - Goepel Electronic

DFT AND EXTENDED 

BOUNDARY SCAN 

APPLICATIONS - PART 4 

WEBINAR TRANSCRIPT 

Subject:! 

Boundary scan test development and deployment 

W14 

Aug 31, 2010 - Rev 1.0 

Heiko Ehrenberg [h.ehrenberg@goepelusa.com] 

(888) 4-GOEPEL 

GOEPEL Electronics • 9737 Great Hills Trail, 170, Austin, TX, 78759 • 1.512.782.2500 • www.goepelusa.com

So, again, welcome to today's webinar, hosted by MJS Designs and GOEPEL Electronics. Today's 

session is the fourth and final part of a webinar series on "Design for Testability and Extended Boundary 

Scan applications". The presentation will last approximately 45 minutes. 

As mentioned, please submit questions via the GoToWebinar Questions Pane. 

My name is Heiko Ehrenberg and I've been working with GOEPEL since 1996 in the area of Boundary 

Scan applications. 

! 

GOEPEL Electronics! 1 

Webinar Transcript!

Before we jump into today's topic, just a few words about MJS Designs and GOEPEL Electronics... 

MJS Designs is an electronics manufacturing services provider specializing in electronics engineering, 

CAD layout design, printed circuit board assembly and testing. 

The company was established in 1976 and is located in Phoenix, AZ. 

! 


Webinar Transcript!

GOEPEL was founded in 1991 and is headquartered in Jena, Germany, with branch offices in the United 

States, in the United Kingdom, in France, and in Hong-Kong. Worldwide we partner with a number of 

companies who provide technical and sales support to our customers. 

GOEPEL's expertise is in JTAG/Boundary Scan, Automotive Test Solutions, Functional Test Systems, 

Automated Optical and X-Ray Inspection Systems, and Digital Image Processing. 

And now, without further delay, let's jump into the topic of today's presentation ... 

! 


Webinar Transcript!

In this webinar we will discuss basic principles of boundary scan test development. 

We will also touch on the integration of boundary scan tools in other automated test equipment. 

! 


Webinar Transcript!

First I want to talk about Boundary Scan Description Language (or BSDL) files, which provide very 

important information about the boundary scan resources implemented in an IEEE 1149.1 compliant 

device. 

! 


Webinar Transcript!

As we have discussed in a previous session of this webinar series, an IEEE 1149.1 compliant device 

adds various mandatory and possibly some optional features to a digital device that otherwise would not 

support this test technology. First, there are four additional pins, the so called test access port (or TAP). 

The TAP includes a Test Data Input (TDI), a Test Data Output (TDO), a Test Clock (TCK), and a Test 

Mode Select (TMS) signal. Of those signals, the TDI and the TMS are required to feature an internal pullup 

resistor. 

The TCK and TMS signals control a 16 state state-machine, the so called TAP Controller, which manages 

various test registers included in an IEEE 1149.1 compliant device. Boundary Scan Cells that are inserted 

in the path between digital I/O pins and the digital core logic of the device are linked to a Boundary Scan 

Register that gets inserted between the TDI and TDO signal under certain conditions. The length of the 

Boundary Scan Register depends on the number of I/O pins and the types of Boundary Scan cells. 

Other registers mandated by IEEE 1149.1 include the 1 bit long Bypass Register and an Instruction 

Register. 

When certain instructions are loaded into the instruction register, the device I/O pins are essentially 

disconnected from the core logic by means of the Boundary Scan cells. One such instruction is the 

mandatory EXTEST which uses the Boundary Scan Register to stimulate and observe the I/O pins of the 

! 


Webinar Transcript!

device. In this manner connectivity at the board or system level can be verified between Boundary Scan 

devices without interference from the core logic in those devices. The standard also defines an optional 

INTEST instruction, which could be used to test the inside of the device while isolating it from the 

surrounding circuitry. This is only practical for simple device functions, though, and therefore is not widely 

used. 

Other mandatory instructions include SAMPLE and PRELOAD, both of which select the Boundary Scan 

Register, as well as BYPASS which selects the Bypass register. The bypass register is used - as the 

name suggests - to bypass the Boundary Scan Register when it is not needed for test purposes. 

One optional device register defined in IEEE 1149.1 is the 32 bit long ID Register, which can be used to 

identify the device type and manufacturer. If the ID Register is implemented, the device must also feature 

the optional IDCODE instruction. There may be other optional data registers that might be used for built-in 

self test control or other device test capabilities, or for device programming, for example. Any data 

registers would be associated with one or more instructions. 

In addition to the four mandatory TAP signals, an optional fifth signal - a low active Test Reset (/TRST) - 

may be implemented. IEEE 1149.1 demands an internal pull-up resistor for this signal. The /TRST pin can 

be used to asynchronously reset the test logic implemented in the device. If the device does not include 

a /TRST signal, the test logic is reset by the TAP Controller. 

Their presence and the specifics of these testability features are specified in a Boundary Scan 

Description Language (BSDL) file. The BSDL file is a mandatory part of IEEE Standard 1149.1, meaning 

a device claiming compliance to this standard also must be accompanied by a BSDL file that describes 

the boundary scan features implemented in this device. The BSDL file is provided by the device vendor 

and usually can be downloaded from the vendorʼs website. Some device vendors actually think they need 

to keep BSDL files under wrap and require NDAʼs or other administrative steps before providing BSDL 

files for their devices to interested parties. 

One thing to keep in mind is that the accuracy of a BSDL file is consequential for the usability of the 

boundary scan features implemented in the respective device. 

! 


Webinar Transcript!

Boundary Scan Description Language defines for example the port function and pin-out of an IEEE 

1149.1 compliant device, the availability of an ID Register and its capture value, the length of the 

instruction register, its capture value, available instructions and their binary opcode, the types of boundary 

scan cells, their order in the boundary register, and the boundary scan cell to pin mapping, the maximum 

TCK frequency, and more. The BSDL file syntax is a subset of VHDL. Device vendors claiming IEEE 

1149.1 compliance for their devices are required to provide BSDL files for those devices. 

! 


Webinar Transcript!

This slide shows a list of attributes in the order they would be presented in a BSDL file. Some of these 

attributes are optional, indicated here by enclosing square brackets. 

“BSDL extensions”, for example, are used to describe features implemented in IEEE 1532, or IEEE 

1149.4, or IEEE 1149.6 compliant devices, all of which are also required to be IEEE 1149.1 compliant. 

The “use statement” provides a reference to one or more package files (.all files) that may define 

boundary scan cells implemented in the device this BSDL file belongs to, 

Note that BSDL files include a port description as well as one or more pin mapping. When referencing a 

specific BSDL file for a boundary scan device during test development, one needs to ensure that the 

correct BSDL file, with the correct pin mapping, is selected. 

! 


Webinar Transcript!

As mentioned before, BSDL files typically can be downloaded from device vendorʼs websites. Here are 

screenshots of just three examples. On a device vendorʼs website, just search for “BSDL” and you 

typically will be presented with links to a respective download area. 

At GOEPEL, we also include a large number of BSDL files in our CASCON GALAXY system library, but I 

usually still recommend to go to a device vendorʼs website to check if there is a more recent version of a 

particular BSDL file - for example a newer version of a BSDL file may have corrections over older 

versions. 

! 


Webinar Transcript!

GOEPEL offers a free syntax and semantics verification tool for BSDL files, which can be made 

available to you upon request. 

! 


Webinar Transcript!

We also offer a tool can read a BSDL file and generate a test bench and/or test vectors for verification of 

the boundary scan implementation in a particular device. The test bench could be run on a simulator 

before the design is committed to silicon, or the test vectors could be executed on a semiconductor ATE 

system for validation of an actual device. 

! 


Webinar Transcript!

Now lets take a look at what it takes to develop boundary scan tests. 

! 


Webinar Transcript!

Most boundary scan applications are concerned about the outside connections between boundary scan 

devices or between boundary scan and non boundary scan devices. 

Logic values present on input pins of an IEEE 1149.1 compliant device can be captured in their 

associated boundary scan cells while the device has either the SAMPLE instruction or the EXTEST 

instruction loaded. Logic values on output pins of an IEEE 1149.1 compliant device can be controlled 

while the device has the EXTEST instruction, the HIGHZ, or the CLAMP instruction loaded. Typically, an 

interconnect test utilizes the EXTEST capabilities of boundary scan devices. Test pattern is shifted 

through the scan chain. Stimulus pattern is applied to nets on the board through boundary scan outputs 

while inputs capture response pattern. A complete set of test vectors, usually a few dozen or so, is 

applied in order to test for opens, shorts, and stuck-at faults. This test pattern set is typically generated 

automatically, based on net list and bill of material for the unit under test, BSDL files for the boundary 

scan devices on the UUT, and device models for non-boundary scan devices. All this information about 

the UUT allows the boundary scan software to get a complete understanding about the functionality of the 

various device pins and their connection on the printed circuit board. This level of detail is necessary for 

the automated test pattern generation tools to be able to generate safe test vectors that donʼt cause any 

bus contentions or other conflicts for a defect free UUT. 

! 


Webinar Transcript!

The general sequence of events in boundary scan tests making use of the EXTEST instruction is shown 

on this slide. This applies to both automatically generated and manually written test programs. After test 

logic reset, the SAMPLE or PRELOAD instruction is loaded into the devices involved in the test, which 

puts their boundary register between their respective TDI and TDO. Then the boundary registers are 

preloaded with a test vector includes safe values specified in BSDL files and constraints specified during 

the test development. Next, the EXTEST instruction is loaded. You donʼt want to load the EXTEST 

instruction without a prior preload of the boundary registers because with the EXTEST instruction the 

boundary scan cells start controlling the I/O pins they are associated with. Without a preload of the 

respective disable value, an output control cell may contain the logic value that enables the I/O pin it is 

associated with, causing this I/O pin to drive, which may cause a collision with other pins that may also be 

driving the net this pin is connected to. 

Once the EXTEST instruction is loaded, a sequence of test pattern is applied. After the final test vector 

has been applied, the test circuitry is reset. 

! 


Webinar Transcript!

In addition to the external connectivity test we just described, some IEEE 1149.1 compliant devices also 

provide some internal test modes. The IEEE standard defines a few optional instructions (namely 

INTEST and RUNBIST) that could be used to verify device internal circuits. Built-in self test (BIST), for 

example, can be used to exercise circuit functions at-speed. Many micro-controllers and digital signal 

processors provide on-chip emulation functions that are often accessible through the componentʼs JTAG 

port. Frequently, such BIST and on-chip emulation functions can also be used for board and system level 

test applications. 

! 


Webinar Transcript!

Boundary scan test development typically starts with the import of CAD data, in particular the net list and 

bill-of-material information. If the unit under test is comprised of multiple modules, such as a mother board 

and one or more daughter cards, the CAD data for all these modules would first be imported and then 

merged together to create one combined system net list. The next step typically is to classify components 

and to assign device models. With an understanding of how the various components are connected 

together and what type of components we have on the UUT, the software tools can analyze the UUT 

structure and determine the amount of test access through boundary scan. Based on the result of this 

analysis, we may want to go back and improve the design of the UUT for better testability and/or for 

improved test access. The best time to do this, of course, is before the design is fixed and further 

changes are not possible in this generation of the product; i.e. one should start with this design for test 

analysis as early as possible in the product design cycle, at the latest once the schematic net list is 

available. 

Once the boundary scan software has this understanding of what the unit under test looks like, we can 

start creating boundary scan applications. Most of these applications can be generated automatically, 

others may need some manual test development effort (i.e. writing a test script in a programming 

language supported by the boundary scan software). Before deploying the boundary scan applications for 

! 


Webinar Transcript!

use in production test or field service, for example, we would make sure they work as expected by 

applying them to a number of UUTs, if possible. 

! 


Webinar Transcript!

The test development workflow I just described is fairly common. How different tools handles these steps 

varies, of course. This and the next few slides discuss the test development process in GOEPELʼs 

SYSTEM CASCON specifically. 

In our SYSTEM CASCON software we divide the test development process in two major processes: 

- First we define the unit under test in what we call the “Design Inspector”; steps include the import of 

CAD data, merging net lists (if necessary), classifying component types or assigning device models, and 

describing any UUT variants, specifying with nets would be accessible for tester channels to extend the 

test coverage, and checking the design agains DFT (design for test) rules. Some of these steps are 

optional, of course. 

- Once we have described the unit under test this way, we would move on to the actual test development, 

which is done in what we call the “Application Inspector”. 

! 


Webinar Transcript!

In CASCONʼs Application Inspector we create the different boundary scan applications, some of which 

are generated automatically based on the net list we just imported, others may need some manual coding 

of the test algorithm. 

Applications that are generated automatically typically include infrastructure tests, interconnect tests, 

memory cluster tests, logic cluster tests, and in-system programming applications (e.g. for Flash, serial 

EEPROM, and CPLD devices). 

Applications that are created by writing the test program manually often include tests of LED clusters, 

switches, AD and DA converters, and other mixed signal circuits that require some operator interaction, 

for example. SYSTEM CASCON provides a programming language called CASLAN, which enables users 

to create pretty much any type of test application that makes use of the boundary scan infrastructure 

defined for a particular UUT. In addition, such tests can also make use of other tester resources, such as 

analog and digital I/O channels, for example. 

Once the various boundary scan applications have been created, one can combine them in batch 

sequences. Such batch sequences may include conditional branches. For example, one could first 

execute the infrastructure test to verify that the scan chain works and the proper devices are mounted, 

and move on with other tests only if that infrastructure test passes. Similar, one may want to spend time 

! 


Webinar Transcript!

programming a Flash device only if the interconnect test and cluster tests for memory devices sharing the 

same address and/or data bus have been passing. 

In SYSTEM CASCON we can also generate test coverage reports for the individual tests as well as for 

batch sequences. These reports can be used to analyze what is really tested with the boundary scan 

applications and what parts of the UUT need to be tested by other means. 

And once test development is completed, we can create a project archive that we can use for backup and 

to easily transfer a project between different locations. 

! 


Webinar Transcript!

This slide provides an overview of SYSTEM CASCON, here with GOEPELʼs SCANFLEX hardware. 

Software related items are highlighted yellow and orange, while hardware related features are highlighted 

blue. 

Inputs are BSDL files, device libraries, and CAD data (which includes net list and bill of material for the 

UUT, perhaps layout and/or schematic data as well). 

Those inputs are processed by the CASCON software and boundary scan test and in-system 

programming applications are created. Those applications can then be applied to the unit under test 

through a stand alone boundary scan hardware, comprised of boundary scan controller and TAP interface 

hardware, perhaps even some additional I/O modules for interface tests, or through 3rd party ATE, which 

communicates with CASCON through an API and which typically integrates some GOEPEL boundary 

scan hardware as well. 

! 


Webinar Transcript!

We just mentioned the integration of boundary scan tools in 3rd party test equipment. Letʼs take a closer 

look at that. 

! 


Webinar Transcript!

This diagram shows a typical electronics manufacturing flow, where on the left side we start with the 

screen printing process for the carrier (typically a printed circuit board) and on the right side we finish the 

manufacturing process with final assembly test before shipping the end product. 

In-between we typically have test steps at various stages of the manufacturing process. For example, 

Automated Optical Inspection (or AOI) is widely used after component placement and before reflow 

soldering. Often there is another AOI or even X-Ray Inspection step after reflow. The goal is to sort out 

bad units before passing them on to the next stage and to rework them immediately, if possible. Since 

Inspection methods don't verify the electrical features of the unit under test, most test strategies include at 

least one electrical test methodology focused on manufacturing defects such as opens and shorts prior to 

running a functional test. Examples are Flying Probe Testers, In-Circuit Testers, Manufacturing Defect 

Analyzers, or a combination of those. Those types of testers often times can provide much better 

diagnostics of manufacturing defects compared to Functional Test. Again, we would want to rework any 

faulty UUTs prior to spending test time on functional test equipment. 

Practically all manufacturing test strategies include at least one functional test stage to verify whether the 

product functions per specification prior to shipment to the customer. 

! 


Webinar Transcript!

As we have just talked about, boundary scan testing can be done with a stand-alone test system. 

Alternatively, boundary scan tools can be integrated with other automated test equipment. For example, a 

Flying Probe Tester could provide additional test access for boundary scan by strategically placing the 

flying probes on circuit nodes that otherwise would not be completely testable with boundary scan alone. 

Or, an In-Circuit Test bed-of-nail fixture could be much less complex and less expensive if nails don't need 

to be provided for circuit nodes that are tested with boundary scan. Functional Tests can benefit from the 

simple pin level access provided by boundary scan, which could reduce test development time 

significantly. 

Boundary scan can even be integrated in Automated Optical Inspection systems, as long as power can 

be provided to the UUT. That way, boundary scan can provide the electrical tests that an AOI machine 

normally is lacking. 

So, in summary, a thorough test strategy usually employs a number of different test methods. Today, 

boundary scan often is an important part of manufacturing test, either as a stand-alone tester setup or as 

an integrated tool set in other test equipment. 

! 


Webinar Transcript!

A few more obvious reasons to integrate boundary scan with other automated test equipment are listed 

here. 

Fewer test stations result in less space needed on the manufacturing floor and less time spent handling 

UUTs. If UUTs need to be handled less there is also less room for error, and the potential for damage 

through handling is reduced. 

In addition to allowing the reuse of tests that have been created for prototype verification, for example, 

boundary scan can also reduce the test time of other test equipment, especially for Flying Probe Testers 

and even for functional testers, while this other test equipment can at the same time potentially extend the 

test coverage achievable with boundary scan. 

! 


Webinar Transcript!

To illustrate the point of extending the test coverage by using flying probes or even bed-of-nail probes, 

consider a net with two boundary scan pins. If one of these two pins is open, we can detect this with 

boundary scan, but we cannot pinpoint which of the two is open. Adding a third driver/sensor - by way of a 

flying probe or fixed probe contacting a test point on that net - gives us the extra resource needed to 

determine which of the two pins is open. 

Another example is a single boundary scan pin in a net. Without additional test resources, such a net 

could only be tested for shorts and - depending on whether it is an input pin or an output pin - for stuck-at 

faults. To gain additional test coverage on such a net, we would need to probe the net and provide an 

extra driver/sensor, which would then allow us to test for connectivity between the boundary scan pin and 

the nail probe. 

! 


Webinar Transcript!

Combining boundary scan and functional test primarily offers a low-cost access mechanism that is 

actually embedded in the UUT. This allows parts of the UUT to be controlled and/or observed by 

boundary scan cells, which other parts of the UUT are in functional mode, for example. Or, boundary scan 

can be used to get control over I/O pins of a CPU or micro-controller if the UUT doesnʼt boot up properly. 

Boundary scan can be used to verify the connectivity between devices before functional test attempts to 

validate the proper function of the UUT. 

! 


Webinar Transcript!

And with this we have come to the end of this four part webinar series. 

Over the last four weeks we have discussed the basics of boundary scan, identified some essential 

design for test guidelines, introduced various types of boundary scan applications, and today we talked 

about how boundary scan applications are developed and deployed. 

We will make the slides of this and the other webinars in this series available for download online. Youʼll 

receive a respective download link via email. 

! 


Webinar Transcript!

! 


Webinar Transcript!

! 


Webinar Transcript!

! 


Webinar Transcript!

For technical support requests, contact us at support@goepelusa.com. 

! 


Webinar Transcript!

Design for Testability and Extended Boundary ... - Goepel Electronic

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?