A low cost methode for BSDL Verification - Goepel Electronic

A LOW-COST METHOD FOR ASSESSING BSDL ACCURACY 

Heiko Ehrenberg and Gerhard Vieweg 

h.ehrenberg@goepel.com, g.vieweg@goepel.com 

GOEPEL Electronics LLC, 9600 Great Hills Trail, 150W, Austin, TX 78759 USA 

Abstract 

The focus of the paper will be on methodologies that 

allow assessing the accuracy of BSDL files. An approach 

based on a software-guided probe will be introduced 

which can be utilized even when the devices under test are 

mounted on a PCB and are part of a Boundary Scan 

chain involving other devices. 

2. Overview of BSDL 

A BSDL file for a particular IEEE 1149.1 compliant 

device contains, at a minimum, the description of the 

following features: 

• A logical Port description; 

• One or more Standard Use Statement(s); 

• One or more device Pin Mapping description(s); 

1. Introduction 

Development of BSDL (Boundary Scan Description 

Language) was initiated in 1990 as an extension to the 

IEEE 1149.1 standard. The first formalized syntax 

description including modifications on IEEE 1149.1 was 

implemented in the 1994 version of that standard. Further 

extensions were added in 2001 [1]. Based on a subset of 

VHDL (VHSIC Hardware Description Language) [2], 

BSDL is standardized and mandatory for IEEE 1149.1 

compliant devices. Typically, modern integrated circuit 

design tools are capable of generating a BSDL file 

automatically based on the Boundary Scan resources 

included in the design. Eventually, ATE (Automated Test 

Equipment) tools can read the BSDL files to understand 

the IEEE 1149.1 test resources available in a particular 

IC, which allows those tools to automatically generate test 

patterns for device, board and system level Boundary 

Scan tests. 

In 1994 the definition of BSDL was made part of the 

IEEE 1149.1 standard. Since then, parts of BSDL have 

been modified or extended, as defined in the revised 

version of IEEE 1149.1-2001. Recent standards such as 

IEEE 1149.4, IEEE 1149.6 and IEEE 1532 also take 

advantage of BSDL, and in particular, its capability to 

define test resources beyond what is defined in IEEE 

1149.1. Details regarding Boundary Scan technology and 

BSDL can also be found in [3]. 

This paper provides an overview of the contents of a 

BSDL file in section 2. Section 3 discusses the 

consequences of inaccurate BSDL files as well as 

indicators for such inaccuracies. In the remainder of the 

paper, ways to verify BSDL files are introduced (section 

4), with a focus on a particular low-cost methodology 

applicable to single devices as well as on board level 

(section 5). 

• Identification of the test bus signals (Scan Port, 

TAP signals); 

• Description of instruction register length, capture 

value, available instructions and their binary opcode; 

• Description of optional data registers (length, 

capture codes, instructions used to access them); 

• Description of Boundary Scan Register (length, 

cell mapping); 

The Standard Use Statement refers to the Standard VHDL 

Package and the Standard VHDL Package Body 

descriptions. Both are provided in a separate file that is 

used in conjunction with the Entity description in the 

BSDL file, supplying all necessary information to the 

tools reading the BSDL file (e.g. for BSDL file 

verification or test pattern generation). In addition to or 

instead of the IEEE 1149.1 Standard VHDL Package and 

Package Body file, a device vendor specific or related 

standard specific file can be assigned. Furthermore, 

extensions to IEEE 1149.1 functionality can be defined in 

such package files. 

Tools reading BSDL files typically verify its syntax and 

semantics. Simple faults, such as missing attributes, 

missing separators, illegal use of keywords in port 

descriptions, etc. are easily identified. Even a mismatch 

between a port function and the assigned Boundary Scan 

cell can be detected. However, certain faults may not be 

found until the actual device is physically accessed and 

exercised through its TAP (Test Access Port). For 

example, a Boundary Scan Register description that is 

syntactically and semantically correct but defines a longer 

or shorter register than physically implemented in the

device will make the BSDL file appear correct to the ATE 

that doesn’t have any other reference. However, when 

physically accessing the Boundary Scan Register of that 

device, the Boundary Scan chain will appear longer or 

shorter, respectively, than expected, causing the 

Boundary Scan test to fail. Another example is a wrong 

order of cells in the Boundary Scan Register description. 

Since the Boundary Scan implementation in compliant 

devices becomes an essential part of the ATE during the 

test, it is a prerequisite that ATE tools can rely on those 

features being described accurately in the BSDL file. 

Otherwise, Boundary Scan testing cannot be 

accomplished successfully without lengthy debugging 

procedures. 

Years ago a group of engineers designed a tool to 

automatically generate a BSDL file from a physical 

sample device that is known to be IEEE 1149.1 compliant 

[4]. Such an approach can be used to either generate a 

BSDL file for a component for which no BSDL file exists 

at all, or to algorithmically extract BSDL information 

from the physical device for comparison against an 

existing BSDL file. 

3. Consequences of BSDL inaccuracy 

The following paragraphs discuss mismatches between 

the BSDL description and the physical implementation of 

Boundary Scan resources in the device itself. Syntax and 

semantic errors shall be excluded from the discussion, as 

those are typically identified by the ATE’s BSDL parser 

reading the file. 

3.1. How do mismatches between BSDL and silicon 

affect Boundary Scan tests? 

Table 1 shows a few examples of possible mismatches 

between the BSDL description and the implementation of 

the Boundary Scan resources on the silicon. 

Some of these faults, or a combination of several of them, 

may even result in board level conflicts during test, which 

can cause the scan chain to break, e.g. due to a test bus 

reset. 

Many of the faults created by BSDL inaccuracies such as 

those mentioned in table 1 could also be the result of 

mistakes made during test development or during the 

Design-For-Testability [5] process. Assuming the BSDL 

files are correct, out-of-date CAD data, bad device 

models for non-Boundary-Scan components, Ground- 

Bounce effects [6], disregarded compliance pattern, etc. 

could cause similar faults during board and system level 

test execution. This makes it even harder to gain 

confidence in the Boundary Scan implementation if there 

is no assurance about the correctness of the BSDL files 

used. The goal should be only to use devices whose 

BSDL files have been verified, preferably by the device 

vendor, and otherwise by the user or a third-party. If 

BSDL files are used that have not been verified against 

the silicon, there is always a chance of mismatches in 

early versions, especially for ASIC’s. Faulty BSDL file 

descriptions used during test pattern generation result in 

Boundary Scan tests that may exercise the Device-Under- 

Test in unexpected ways causing false error messages at 

run time. 

3.2. How to trace problems back to a bad BSDL file? 

Nowadays, most BSDL files accurately reflect the 

Boundary Scan implementation in the device they belong 

to. Automated BSDL creation tools make the process of 

generating the file less error prone. Still, there are cases 

where a BSDL file does not exactly represent the features 

implemented on silicon, be it because of a change in the 

design of the device that has not been revised in its 

corresponding BSDL file, or because of a mistake in a 

manually created BSDL file. 

Eventually, mismatches between a BSDL file and the 

device it belongs to will be detected. If the Boundary 

Scan implementation has not been verified on the device 

by itself, problems will likely show up during board level 

testing, but it will be more time consuming to locate 

problems related to a BSDL description at this stage. 

Typically, the verification is done in multiple steps: 

• Verification of the Test Access Port (TAP) 

functionality (including Compliance Enable pins, 

if applicable); 

• Verification of basic set of registers (Bypass 

Register, Instruction Register, Boundary Scan 

Register, ID-Code Register if available and other 

optional data registers): length, capture code (if 

any) 

• Verification of instruction op-codes in regard to 

data register access; 

• Verification of Boundary Scan Cell mapping and 

cell functionality; 

• Verification of optional test resources; 

By following a structured approach like this it becomes 

easier to identify any mistakes in the Boundary Scan 

implementation or to trace problems back to errors in the 

BSDL file. This is especially true for BSDL verification 

on a device already mounted on a printed circuit board 

where, due to board level interconnections, other devices

in the circuitry determine how freely pins of the Device- 

Under-Test can be exercised. 

Mismatch between BSDL 

and silicon 

1 Wrong pin function 

described (e.g. port 

described as input is 

actually an output) 

2 Wrong capture value 

defined 

3 Wrong Op-Code for 

SAMPLE defined 

4 Wrong register length 

defined 

5 Wrong capture value 

defined 


defined 

7 Wrong cell order 

defined (input cell, 

output cell, control 

cell order assigned 

for a bi-directional 

port is wrong) 

8 Wrong cell number 

assigned to port 

9 Wrong cell type 

defined 

10 Wrong disable 

condition defined for 

TriState-output or bidirectional 

port 


defined 

Consequence as observed during board 

level test execution 

Port description 

Possible conflicts on board level 

interconnects; 

Pin might be diagnosed as open or stuck-at 

Instruction Register description 

ATE assumes it measured a wrong capture 

value or is reading from a wrong register 

or device. 

When assigning the SAMPLE instruction 

to the device, ATE assumes it is selecting 

the Boundary Scan register for capturing 

values on input cells; in reality it may 

select the BYPASS register or another 

register because of the wrong Op-Code 

assumed to be valid for the SAMPLE 

instruction. 

ATE assumes it is not reading the correct 

register or device or the scan chain is 

different than expected. Wrong instruction 

op-codes may be supplied to the device 

causing additional problems. 

Optional Data Register description 

ATE assumes it measured a wrong capture 

value or is reading from a wrong register 

or device. 



different than expected. 

Boundary Scan Register description 

Test pattern generated by ATE does not 

exercise the pin as expected in EXTEST 

mode, causing faulty diagnostic messages 

and maybe even conflicts between output 

drivers. 

ATE is not exercising the correct pin, 

causing faulty diagnostic messages and 

maybe even conflicts between output 

drivers. 

Pin may not behave as expected in test 

modes, causing faulty diagnostic messages 

and maybe even conflicts between output 

drivers. 

Pin may be activated when ATE assumes 

it to be inactive, causing conflicts between 

output drivers. Resulting in faulty 

diagnostic messages. 



different than expected. 

Table 1: Mismatches between BSDL and silicon, examples 

4. Methods of BSDL verification 

There are mainly two methods for verifying Boundary 

Scan implementations and the BSDL file created for a 

specific device: 

• Verification in Single Device Environment; 

• Verification in Circuit Board Environment with 

other devices surrounding the device under test. 

If no BSDL file is available for a Boundary Scan 

component, it is possible to stimulate its Test Access Port 

in such a way such as to emulate the test bus functionality 

to determine the length of the Boundary Scan Instruction 

Register, the length of Boundary Scan data registers, 

existence and contents of the ID-Code Register, and 

register access of instruction op-codes. With the results of 

this emulation an incomplete BSDL file can be created 

which in turn can be used for further examination in a 

single device environment. Such an emulation could be 

done by providing access to the TCK, TMS, TDO, TDI 

and /TRST signals through Boundary Scan pins or other 

I/O pins of the ATE system as indicated in Figure 1. 

Controller 

TCK 

TMS 

TDO 

TDI 

BScan IC 

(Host) 

OUT2 

OUT2 

OUT2 

TCK 

TMS 

TDI 

IN 

TDO 

BScan IC 

(DUT) 

TCK 

TMS 

TDI 

TDO 

Figure 1: Emulating TAP access to a Device-Under-Test 

(DUT) 

The example illustrated in Figure 1 uses an off-the-shelf 

Boundary Scan system with a Controller to stimulate the 

TAP signals on an IEEE-1149.1 compliant component 

(BScan IC – Host), which in turn is used to provide test 

pattern to the Device Under Test (DUT). This host device 

provides very inexpensive test channels (its Boundary 

Scan I/O pins) that are sufficient to drive and observe the 

TAP signals and I/O pins on the DUT. The emulation of 

TAP access to the DUT through the hosts Boundary Scan 

I/O pins allows experimenting with the DUT’s Test 

Access Port and the detection of any non-compliant 

behavior without breaking the Boundary Scan chain.

Once basic information about the Boundary Scan 

implementation is available (either after emulation mode 

as described in figure 1; or by means of an existing BSDL 

file) the goal is to verify that the implementation is 

compliant to IEEE 1149.1 and that the BSDL file 

accurately reflects the Boundary Scan features available 

in the device. This includes verifying data register 

functionality as well as Boundary Scan Cell mapping and 

pin functionality. 

Figure 2 shows one way of accessing the Device Under 

Test (DUT) for verification in a single device 

environment. There are a few requirements to be taken 

care of when considering unlimited pin mapping and pin 

functionality test: 

• To avoid damage, the DUT must not be 

connected to other system pins of a PCB (single 

device environment); 

• VCC and GND connections are required; 

• Compliance pattern (if required) needs to be 

applied; 

• A BSDL file with the minimum information 

Instruction Register length, Boundary Scan 

Register length, Instruction Register Op-Code 

for Bypass and Extest must exist (it is possible 

for this to be a result of "Emulating a DUT" – 

see figure 1); 

• Connection between host driver pin via serial 

resistor to the Pin Under Test (PUT) and back to 

an input pin of the host (probe) must be 

available; 

Controller 

TCK 

TMS 

TDO 

TDI 

BScan IC 

(Host) 

OUT2 

IN 

TCK 

TMS 

TDI 

TDO 

RES 

Figure 2: Checking Pin Properties of a DUT 

BScan IC 

(DUT) 

TCK 

TMS 

TDI 

TDO 

• The device could be mounted on a carrier board 

and test pads could be accessed sequentially by a 

handheld probe; 

The least expensive and most versatile of these three 

options is to probe each pin sequentially using a handheld 

probe. In conjunction with special test routines the user 

can be guided by the ATE software to probe whatever pin 

or test pad is to be accessed for a particular test step. In 

figure 2 the BScan IC (Host) represents such a handheld 

probe. Using an existing Boundary Scan device as 

“Probe” can be especially helpful for verification of 

Boundary Scan resources in a circuit board environment. 

Verification of the Boundary Scan implementation of a 

DUT in a circuit board environment can become difficult 

due to interactions with other devices on the board [7]. 

The conditions, under which pin mapping and pin 

functionality tests are possible on a device mounted on a 

PCB with other components, are more limiting than in the 

case of a single device environment: 

• To avoid damage, only pins not connected to 

other drivers and not causing any conflicts on 

board level can be exercised in Extest mode; 

• Board has to be powered on; 

• Compliance pattern (if required) needs to be 

applied; 

• Preferably, a complete BSDL file must exist; 

• Connection between host driver pin via serial 

resistor to the Pin Under Test (PUT) and back to 

an input pin of the host (probe) must be 

available; 

• As host (probe) a Boundary Scan pin on a 

different device on the same board could be 

utilized, as long as that device is in a separate 

scan chain from the DUT, and that pin is 

bidirectional and not connected to any other pins 

on the board; 

Table 2 provides an overview of the three methods of 

verifying Boundary Scan resources discussed above. 

There are multiple ways to contact the DUT for pin 

testing in a single device environment: 


and put on a bed-of-nails fixture; 


and test pads could be accessed sequentially by 

an Automated Flying Probe system;

Action 

Verification of Instruction 

Register length 

Verification of possible 

data register length 

Detection of Instruction 

Register length 

Detection of possible data 

register length 

Relation between 

Instruction Op-Code and 

accessible data register 

Verification of ID-Code 

Register 

Detection of ID-Code 

Register 

Emulation 

Mode 1 , 

single device 

Real Mode 2 , 

Single Device 

Environment 

Real Mode 2 , 

Circuit Board 

Environment 

Yes Yes Yes 

Yes Yes Yes 

Yes No No 

Yes No No 

Yes No No 

Yes Yes Yes 

Yes No No 

Verification of pin type Yes Yes Yes 

Verification of Control 

Cell number 

Verification of Data Cell 

number 

Verification of Input Cell 

number 

Detection of Control Cell 

number 

Detection of Data Cell 

number 

Detection of Input Cell 

number 

(Yes) 3 Yes Yes 

(Yes) Yes Yes 

(Yes) Yes Yes 

(Yes) Yes No 

(Yes) Yes No 

(Yes) Yes Yes 

Table 2: Overview of BSDL Verification methodologies 

5. Example, Guided Probe approach in a 

Single Device Environment 

In this particular example, access to the I/O pins to be 

tested on the Device-Under-Test is provided through a 

handheld probe (Guided Probe). That Guided Probe can 

be used in two modes: Emulation Mode and Real Mode/ 

Pin Test Mode. It is connected to a PC based Boundary 

Scan controller and provides the Test Access Port signals 

for the DUT as well as a test channel for testing I/O pin 

functionality. During Emulation Mode, the test bus 

signals for the DUT’s TAP are emulated using Boundary 

Scan I/O pins on the Guided Probe (see figure 1); in Pin 

Test Mode (or Real Mode), the DUT’s TAP becomes part 

1 In “Emulation Mode” the TAP on the DUT is emulated by the ATE 

(e.g. through Boundary Scan I/O pins); 

2 In “Real Mode” the TAP of the DUT is controlled by the ATE and can 

be part of a scan chain that includes other devices, resulting in 

limitations during register check. 

of the Boundary Scan chain controlled directly by the 

Boundary Scan controller (see figure 2). 

In Emulation Mode, the focus is on checking test bus pins 

and the registers that are part of the Boundary Scan 

implementation of the DUT. The Guided Probe is 

emulating a Boundary Scan component’s TAP. As a 

result of applying test sequences to the DUT’s TAP pins, 

one can evaluate the following Boundary Scan features: 

• Detect IR Register; 

• Detect length of IR Register; 

• Detect Data Registers; 

• Detect the content of a possible Data Register of 

32 bit length (ID-Code Register); 

• Detect the length of the Data Register between 

TDI and TDO after Power On; 

• Detect a relationship between Instruction 

Register Op-Codes and Data Register length; 

Executing these test steps takes several seconds to 

minutes, mainly depending on the length of the 

instruction register, the TCK frequency, and ATE 

throughput (e.g. PCI based BScan controller vs. Parallel 

Port). 

As mentioned earlier, the Emulation Mode would 

predominantly be used to detect Boundary Scan 

resources, rather than to verify an existing BSDL file. It 

can be used, however, to compare the Boundary Scan 

implementation with an available BSDL file and even to 

check pin functionality and cell mapping, although the 

latter will take considerably more time than in Real 

Mode. 

In Real Mode, the DUT is part of a Boundary Scan chain 

(see figure 2). The Guided Probe is used to access the 

Boundary Scan I/O pins in order to test the pin 

functionality and the Boundary Scan cell mapping. The 

focus is on verifying an existing BSDL file: 

• Verification of Compliance Pattern (if 

applicable) and TAP functionality; 

• Verification of Instruction Register length and 

capture code; 

• Verification of BYPASS Registers (length, 

capture code); 

• Verification of ID-Code Register (if existent); 

• Verification of other Data Registers (length, 

capture code if applicable); 

3 (Yes) = possible but can be time consuming

• Verification of relationship between Instruction 

Register Op-Codes and Data Registers; 

• Verification Boundary Scan Register length, cell 

mapping, cell and pin functionality; 

Executing the first six verification steps of the list above 

takes typically a few seconds only. The amount of time it 

takes to verify cell mapping and pin functionality depends 

heavily on the length of the Boundary Scan register, the 

number of I/O pins as well as the types of I/O pins (input 

only, output only, bidirectional, etc.). 

The Guided Probe (host) uses one BScan Output for 

driving via a serial resistor (160 … 470 Ohm), and one 

BScan Input to capture the level on the pin to be tested. 

The DUT is in a Single Device Environment (none of its 

I/O pins are connected to other devices). During pin 

testing, the following features can be evaluated: 

• Is the Pin-Under-Test (PUT) TriState or driving 

actively LOW / HIGH? 

• Is the PUT a Boundary Scan I/O pin at all? 

• Can the PUT be enabled / disabled by a 

Boundary Scan cell? Which level is needed to 

disable the pin? 

• Is the PUT bi-directional? 

• Number of control cell for PUT (if any); 

• Number of output cell on PUT (if any); 

• Number of input cell on PUT (if any); 

The time it takes to do these tests is typically about one 

second per I/O pin plus the time it takes to contact the pin 

(typically seconds for a hand-held probe). 

In this example, the test pattern for the BSDL file 

verification has been created on a PC based Boundary 

Scan ATE tool set. The Device-Under-Test was a Texas 

Instruments OMAP5910GZG289 in a 289 ball MicroStar 

BGA package [8]. A BSDL file was available and has 

been imported into the ATE’s device library. The DUT 

required four pins to be held low to enable Boundary 

Scan testing (compliance pattern). The test pattern is 

available for the ATE as a macro, which allows it to be 

adapted to other DUT’s with very few modifications. The 

TAP of the Guided Probe was connected to the PC 

through a LAN based Boundary Scan controller. The 

Device-Under-Test has been mounted on a small fixture 

board which provided a power supply and compliance pin 

access as well as test pads for all pins. The DUT’s TAP 

has been connected to the Guided Probe which can switch 

between Emulation Mode and Real Mode in order to 

exercise DUT’s Boundary Scan resources. 

The preparation in the ATE software included: 

• Importing BSDL file, including automated 

syntax and semantics check; 

• Creating a description file to define the 

Boundary Scan chain configuration; 

• Modifying and compiling the BSDL Verification 

Macro for the DUT; 

The time spent on these preparations was less than one 

hour. 

After verifying the basic Boundary Scan implementation 

(instruction and data register check), the BSDL 

Verification Macro instructs the operator to probe certain 

pins or test pads. It then analyzes the available pin 

functionality and stores the findings in a report file. In 

this manner, all pins of the BGA are contacted 

sequentially. This process could be automated using a 

Flying Probe System. Eventually, the pin functionality 

recognized by the Guided Probe hardware is compared to 

the cell description in the BSDL file. 

Alternatively, all DUT’s I/O pins can be connected to 

Boundary Scan I/O channels on the ATE and a test can be 

generated that verifies all Boundary Scan Cell 

implementations against the existing BSDL file and 

reports mismatches. This process is faster than the manual 

probing. 

Overall, the verification process of the BSDL file can be 

accomplished in a few hours. Considering that access to 

the BGA’s ports is accomplished with very low-cost 

equipment and that the verification can be executed by 

technicians, this is a good alternative approach to 

verifying BSDL files on more expensive ATE (such as 

Chiptesters) that require much more elaborate hardware 

configurations. 

6. Conclusions 

Verifying BSDL files against the physical implementation 

of Boundary Scan resources in a device associated with 

the file is important, because faulty BSDL files result in 

false diagnostics during Boundary Scan testing and in a 

worst case scenario can create board level conflicts that 

may even cause additional damage. 

This paper introduces a low-cost approach to verification 

of Boundary Scan implementations conforming to all 

revisions of the IEEE-1149.1 standard. The method of 

using a (handheld or automated) Guided Probe for pin 

access can be extended to board and even system level 

debugging, as it allows for nets to be stimulated, and/or 

for pin and net states to be detected.

7. References 

[1] IEEE Computer Society, IEEE Standard Test Access 

Port and Boundary Scan Architecture - IEEE Std. 

1149.1 2001, Annex B, IEEE, New York, NY, 2001 

[2] IEEE Computer Society, ANSI/IEEE Standard 

VHDL Language Reference Manual - IEEE Std. 

1076-2000, IEEE, New York, NY, 2000 

[3] Kenneth P. Parker, The Boundary-Scan Handbook, 

3 rd Edition, 2003, Kluwer Academic Publishers, 

Norwell, MA, 02061, ISBN: 1-4020-7496-4 

[4] Doug Raymond et al, Algorithmic extraction of 

BSDL from 1149.1-compliant sample ICs, 

Proceedings of International Test Conference 1995, 

Paper 25.1, pp.561-568 

[5] Heiko Ehrenberg, White Paper: Design-For- 

Testability Guidelines for Boundary Scan Test, 

GOEPEL Electronics, 2002 

[6] Hans-Peter Richter and Norbert Muench, Boundary 

Scan Test triumphs over Ground-Bounce, Test & 

Measurement World, August 1997 

[7] Bill Eklow, Richard Sedmark, Dan Singletary, and 

Toai Vo, Unsafe Board States During PC-Based 

Boundary Scan Testing, Proceedings of 

International Test Conference 2001, Paper 22.3, 

pp.615-623 

[8] Texas Instruments, OMAP5910 Dual Core 

Processor Data Manual, Texas Instruments, Inc., 

August 2002

A low cost methode for BSDL Verification - Goepel Electronic

Create successful ePaper yourself

Delete template?

Save as template?