2 Ieee BSDL: Medalist I3070 In-Circuit Test System Boundary-Scan Testing

Medalist i3070 In-circuit Test System
Boundary-Scan Testing
2
IEEE BSDL
Overview 2-2
Elements of BSDL 2-3
Components of a BSDL Description 2-7
RUNBIST Description 2-42
INTEST Description 2-46
User Extensions to BSDL 2-48
Design Warning 2-50
Standard VHDL Package STD_1149_1_2001 2-51
User-Supplied VHDL Packages 2-55
Example Applications of BSDL 2-62
Sample BSDL Description 2-68
BSDL Quick Reference 2-71
2-1
2 IEEE BSDL
Overview
This chapter describes how to use IEEE Standard 1149.1- 2001 BSDL.
The information in this chapter is derived and/or reprinted from IEEE
Std. 1149.1- 2001, IEEE Standard Test Access Port and Boundary- Scan
Architecture, Copyright © 2001 by the Institute of Electrical and
Electronics Engineers, Inc. The IEEE disclaims any responsibility or
liability resulting from the placement and use in this publication.
Information is reprinted with the permission of the IEEE.
IEEE 1149.1 and BSDL History

The 1149.1 Standard was first released by the IEEE in 1990. Starting then,
an industry ad- hoc group began developing a version of BSDL that was
then taken over for final development by the IEEE. The standard itself has
undergone several revisions. First came a series of enhancements and
additions in 1993. Then in 1994, a formal definition of BSDL was added to
the standard. In 2001, another revision was completed by the IEEE
working group which made some minor changes. This section reflects the
current state of the standard as defined in 2001.
The following information is subject to periodic change. Therefore, consult
the IEEE documentation as the final, current authority.
2-2 Boundary-Scan Testing

IEEE BSDL 2
Elements of BSDL
• Character Set
• Strings
• Comments
• Syntax Definitions
• Lexical Atoms
• Commonly Used Syntactic Elements
Character Set
BSDL is not case sensitive and permits the following characters:
• Upper- and lower- case letters A to Z
• Digits 0 to 9
• Special characters " & ’ [ ] ( ) * , - . : ; < = > _
• Logical separators such as space and VHDL characters called:
• horizontal tabulation
• carriage return
Logical separators have two purposes:
• Separate lexical tokens such as reserved words and/or identifiers such
as the reserved word entity which must be separated from the
component name identifier that immediately follows it.
• Create visually appealing layouts.
Strings
A string is defined as a sequence of zero or more characters enclosed
between quotation marks. A quotation mark character is not allowed
within a string in BSDL. Strings are used extensively in BSDL. Since many
BSDL strings are potentially much longer than a single line, the
concatenation operator & is used to break them into manageable pieces.
BSDL does not permit replacement of the quotation mark with any other
character. A string literal has to fit on one line since it is a lexical
element. Therefore, the only legal VHDL format effector in a string literal
is horizontal tabulation.
Boundary-Scan Testing 2-3

2 IEEE BSDL
Comments
Text between a double dash (- - ) and the end of a line is treated as a
comment. The text is allowed to contain any special character allowed by
VHDL. Comments syntactically terminate a line of description. Comments
may be interspersed with lexical elements. For example:
"This is all" & -- string split by comment
" a single string"
Syntax Definitions
BNF Conventions
BSDL syntax is presented in Backus- Naur Form (BNF):
• Any item enclosed in chevrons (< and >) is the name of a syntax item.
• Items enclosed between braces ({ and }) may be omitted or included one
or more times.
• Items enclosed between square brackets ([ and ]) may be omitted or
included only one time.
• Items enclosed between the pipe characters (¦ and ¦) may appear in
any order.
• Items shown in bold type have to be included exactly as presented
except for case.
• Alternative syntaxes are separated by a vertical bar ( | ).
• The symbol “::=” should be read as “is defined as”. Note that the
non- bold face “::=” is only part of a BNF description; in a BSDL file the
bold face characters “::=” are used to indicate assignment.
• White space (spaces, tabulation, carriage returns, etc.) is used in BNF
descriptions to enhance readability and are not part of the syntax.
However, white space needed to resolve lexical ambiguity (logical
separation) is required.

IEEE BSDL 2
Lexical Atoms
• A <VHDL identifier> is any valid identifier chosen as an item name.
• An <integer> is any valid unsigned VHDL integer made up of an
unsigned numeric character sequence not containing an underscore (_)
character and not using an exponent field.
• A <real number> is any valid VHDL real number of the form
<integer>.<integer> or <integer>.<integer>E<integer> all written
contiguously without spaces or format effectors. Note 1E3 is not real
because it doesn’t contain a decimal point. The number 20.0E6 is real
as is 20000000.0.
• A <pattern> is a contiguous sequence of one or more 0, 1, and X
characters containing no spaces or format effectors. For example,
001X00 and XX010X, are legal. However, 100 X00 is not legal because
of the embedded space. A low state is denoted by 0, a high state is
denoted by 1, and a don’t care value is denoted by X.
• A <32- bit pattern> is a <pattern> with exactly 32 characters in its
character sequence.
• A <left bracket> is the bracket character ( [ ).
• A <right bracket> is right bracket character ( ] ).
• A <string> is any valid string or concatenated string structure.

2 IEEE BSDL
Commonly Used Syntactic Elements

A <port ID> identifies a component signal that may be used to interface to
external signals. A port may be dimensioned as a bit or a bit_vector.
Subscripted names are allowed only when bit_vector dimensioned port
signals are used.
Example 2-1 Port ID Syntax

<port ID> ::= <port name> | <subscripted port name>
<port name> ::= <VHDL identifier>
<subscribed port name> ::= <VHDL identifier> ( <subscript> )
<subscript> ::= <integer>
An <instruction name> is an instruction name defined by a manufacturer.
Example 2-2 Instruction Name Syntax

<instruction name> ::= BYPASS | CLAMP | EXTEST | HIGHZ | IDCODE | INTEST |
RUNBIST | SAMPLE | USERCODE | <VHDL identifier>
SAMPLE is used as an abbreviated name for SAMPLE/PRELOAD.

NOTE

IEEE BSDL 2
Components of a BSDL Description

The BSDL description is composed of the entity description, the standard
VHDL package and package body, and the user- specified VHDL packages
and package bodies.
• An entity is the basis for describing a device in VHDL. Within the
entity, the boundary- scan parameters of a device are described. The
entity relies upon the package to provide device attribute information.
An entity describes a device's I/O port and important attributes of the
device. For BSDL, an entity has the following structure:
Example 2-3 Entity

entity My_IC is -- an entity for my IC
[Generic Parameter]
[Logical Port Description]
[Use Statement(s)]
[Package Pin Mapping]
[Scan Port Identification]
[TAP Description]
[Boundary Register Description]
end My_IC; -- end description
The order of the elements within the entity, as shown above, is a

required standard practice to simplify non- VHDL applications. The
following sections examine each element of the entity and the
statements used to describe the elements.
An example for an actual device is shown in Sample BSDL Description.
• A package is a collection of declarations used to describe IEEE
Standard 1149.1 information, or user- specific design information.
The definitions related to IEEE Standard 1149.1 come from a standard
VHDL package and related package body. The package information is
directly related to the standard and is only expected to change when
the standard itself changes. Typically, this information would be
write- protected.
The standard definitions are provided in Standard VHDL Package
STD_1149_1_2001.
Device designers can add a package (and package body), to contain
user- specific design information. An example of this would be to
contain a library of cell definitions unique to some application, perhaps
dependent upon the silicon technology in use.

2 IEEE BSDL
• A package body contains declarations that define the function of the

declarations given in the package. The package body typically provides
specific, device attribute information. The package bodies are broken
into separate units to allow you to update the data within the units
without needing to recompile all entities that reference the
corresponding package. Figure 2- 1 graphically represents the exchange
between a typical entity, package, and package body.
A double-dash (--) is the VHDL convention for comments.

NOTE
Figure 2-1 A Typical Entity, Package, and Package Body

IEEE BSDL 2
The Entity Description

The entity description and supporting VHDL packages make up a BSDL
model of the component and is, in effect, the electronic data sheet for its
test logic. It contains statements through which parameters that may vary
from one chip to another are defined.
The BSDL entity description must have the following structure:
<BSDL description> ::=
entity <component name> is
<generic parameters>
<logical port description>
<standard use statement>
{ <use statement> }
<component conformance statement>
<device package pin mappings>
[ <grouped port identification> ]
<scan port identification>
[ <compliance enable description> ]
<instruction register description>
[ <optional register description> ]
[ <register access description> ]
<boundary-scan register description>
[ <runbist description> ]
[ <intest description> ]
{ <BSDL extensions> }
[ <design warning> ]
end <component name> ;
<component name> ::= <VHDL identifier>
VHDL permits some elements within an entity description to be in an

NOTE
arbitrary order, the fixed ordering above is required for BSDL.
The <component name> identifies a particular integrated circuit. Any

<component name> referenced in any attribute statement has to be the
same as the component name declared in the entity statement.

2 IEEE BSDL
Generic Parameter Statement

The generic parameter is a VHDL construct used to pass data into a VHDL
model. In BSDL the generic parameter is intended as a method for
selecting among several physical packaging options that a device might
have. Each option could have a different mapping between the pins of the
package and the bonding pads of the device. Even devices manufactured in
a single package will be tested before packaging, with a different mapping
possible. This is called the logical- to- physical relationship of the device’s
signals.
Logical pins are the control, input, and output pins of the Boundary
Register. They are assigned logical names that describe their function and
location within the device.
Physical pins are the actual pins or terminals of the device. They are
typically numbered 1 through X (depending on the number of pins the
device has), or A1 through Ax for pin grid arrays (the alphanumeric
pattern can have any combination typically found in PGAs).
BSDL describes the device’s boundary- scan architecture with the logical
signals. When you develop a board test, you will need to know how the
logical structure of the device maps onto a set of physical pins. The
generic parameter must have the name PHYSICAL_PIN_MAP so test
development software can identify it.
The generic parameter has the following form:
Example 2-4 Generic Paramater Statement Syntax

<generic parameter> ::=
generic (PHYSICAL_PIN_MAP : string); |
generic (PHYSICAL_PIN_MAP : string := <default device package type> );
<default device package type> ::= " <VHDL identifier> "
In the first alternative <generic parameter> statement syntax, a <pin

mapping name> that identifies a component package option must be
supplied with the BSDL description when it is referenced. In the second
alternative syntax, a value is given for the <default device package type>
that will be used as the default in the case in which no <pin mapping
name> is supplied with the BSDL description when it is referenced. The
<default device package type> must be the quoted name of a <pin mapping
name> used to specify the pin mapping for the component.
It is an error if:
• no <default device package type> is specified in the <generic parameter>
statement of a BSDL description, and no package <pin mapping name>
is specified when a BSDL description is processed.

IEEE BSDL 2
• the <default device package type> specified in the <generic parameter>

statement is not identical to any <pin mapping name> appearing in any
<pin mapping> and no <pin mapping name> is specified BSDL
description is processed.
• a <pin mapping name> is specified when a given BSDL description is
processed, and that <pin mapping name> is not identical to any <pin
mapping name> appearing in any <pin mapping> of that description.
Example 2-5 Generic Parameter Examples

generic (PHYSICAL_PIN_MAP : string := "UNDEFINED");
generic (PHYSICAL_PIN_MAP : string := "DW_Package")
In the first example above, note that the string is initialized to an

arbitrary (undefined) value that will not allow a package selection if a
parameter has not been bound to a value; that is, a parameter has not
been passed, so the package will have to be selected by some external
mechanism.
In the second example, the DW_Package is selected as the package.
Logical Port Description

The BSDL port description is a specialization of the VHDL port list. It is
used to assign meaningful symbolic names to a component’s pins. These
symbolic names, which will be used in subsequent statements in the
description, allow the majority of such statements to be independent of a
renumbering or other reorganization of the component’s pins.
It is strongly recommended that the existence of non- digital pins (such as
power, ground, no- connects, or analog signals) be recorded in the
component’s BSDL description through use of the linkage <pin type>
shown in Table 2- 1. The logical port description has the following form:
Example 2-6 Logical Port Description Syntax

<logical port description> ::= port ( <pin spec> { ; <pin spec> } );
<pin spec> ::= <identifier list> : <pin type> <port dimension>
<identifier list> ::= <port name> {,<port name>}
<pin type> ::= in | out | buffer | inout | linkage
<port dimension> ::= bit | bit_vector ( <range> )
<range> ::= <integer_1> to <integer_2> | <integer_2> downto <integer_1>
<integer_1> ::= <integer>
<integer_2> ::= <integer>

2 IEEE BSDL
The definitions of the possible values of <pin type> are given in Table 2- 1.
Table 2-1 Pin Types
Value Meaning
in An input-only pin
out An output-only pin that may be connected to a bus wire driven by
multiple drivers (a 3-state or open-collector output)
buffer A 2-state output-only pin where either state is always actively driven
(must not be connected to bus wire)
inout A bidirectional pin
linkage Other pin types such as power, ground, analog, or no-connect
The <port dimension> defines the number of signals comprising a port. If

the <port dimension> is bit, then one <port name> corresponds to that one
signal. If the <port dimension> is bit_vector, then one <port name>
corresponds to a collection of n signals which can be individually
referenced by subscripting the port name (a <subscripted port name>).
A bit_vector declared in a <logical port description> statement must have
the value of <integer_1> less than or equal to the value of <integer_2>.
Each <port name> appearing in an <identifier list> of a <logical port
description> must occur only once within the <logical port description>
statement.
The <pin type> can be one of two types prescribed by the standard
practice of BSDL: pin scalar or pin vector.
• A pin scalar is a single signal. Every pin must have a unique name. For
example, if there are several ground pins, they must each have a
different name (such as GND1, GND2, GND3); otherwise they must be
expressed as a pin vector.
• A pin vector is a shorthand for grouping related signals. For example,
Data(1 to 8) indicates that there are eight signals named Data indexed
from one to eight, such as Data(3). The range can be either ascending
(1 to 8), (2 to 31) or descending (8 downto 1), (31 downto 2). For
example:
D:in bit_vector (1 to 8)
Q:out bit_vector (16 downto 1)

IEEE BSDL 2
Standard Use Statement

The <standard use statement> identifies one Standard VHDL Package in
which attributes, types, constants, and other elements are defined that will
be referenced elsewhere in this guide. The standard use statement has the
following form:
Example 2-7 Standard Use Statement Syntax

<standard use statement> ::= use <standard VHDL package identifiers>.all;
<standard VHDL package identifiers> ::= STD_1149_1_1990 | STD_1149_1_1994 |
STD_1149_1_2001
The <standard VHDL package identifiers> is the name of the Standard

VHDL package that contains the information to be included. The suffix .all
indicates that all declarations within the VHDL package are to be used.
Within an Agilent test system processing BSDL descriptions, the standard
VHDL package may be a file somewhere in the file system. The .all suffix
is meaningful to VHDL and is not part of a file name. While VHDL permits
the use of a wider range of suffixes, .all is the only suffix permitted in
BSDL.
The content of the standard VHDL package is the current definition of the
BSDL language and must not be modified by users.
Use Statement
The optional <use statement> identifies a VHDL package in which specific
attributes or constants are defined so they can be referenced elsewhere in
a BSDL description. The use statement uses the following form:
Example 2-8 Use Statement Syntax

<use statement> ::= use <user VHDL package identifier>.all;
<user VHDL package identifier> ::= <VHDL identifier>
The <user VHDL package identifier> in the <use statement> is the name of
the VHDL package that contains the information to be included. Identifiers
declared in VHDL packages cannot be defined:
• more than once in a single VHDL package.
• in more than one VHDL package referenced by a <user statement> or
<standard use statement> in a single BSDL description.
Example 2-9 Use Statement Example

use Private_Package.all; -- Retrieves a user proprietary package

2 IEEE BSDL
The use statement for 1149.1 information must also appear in each
user- defined package.
The package name that you assign should not include a pathname to the
package. The software performs a routine search for the package to ensure
that all information is retrieved. The search pattern that the software
follows is:
• current directory (typically, your board directory)
• directory where the BSDL source file is located
• /Agilent_ICT/library/supplemental/bsdl
We suggest that you place your BSDL files and packages in the
/Agilent_ICT/library/supplemental/bsdl directory, which is reserved
for this function. This strategy is particularly useful if you use the same
boundary- scan devices on various types of boards.
If you have a unique device, you might want to place its BSDL file and
associated package(s) in a separate directory (board directory).
Component Conformance Statement

The <component conformance statement> identifies the issue of the
standard to which a physical component’s testability circuitry conforms. It
is possible for a component designed in 1990 to be described by the 1994
version of BSDL, but this cannot imply that the component conforms to
the rules of the 1993 issue of this standard. For example, the 1990 issue
of the standard allowed (by omission of rules) two drivers controlled by a
single control cell to be disabled by opposing values loaded into that cell.
This is explicitly forbidden in the 1993 issue of the standard. The
<component conformance statement> allows tools to account for changes in
the rules that may occur in past and future issues of this standard. The
component conformance statement uses the following form:
Example 2-10 Component Conformance Statement Syntax

<component conformance statement> ::= attribute COMPONENT_CONFORMANCE of
<component name> :entity is <conformance string>;
<conformance string> ::= " <conformance identification> "
<conformance identification> ::= STD_1149_1_1990 | STD_ 1149_1_1993 | STD_
1149_1_2001
STD_1149_1_1990 refers to the 1990 issue of this standard,

STD_1149_1_1993 refers to the 1993 issue, and
STD_1149_1_2001 refers to the 2001 issue.
Example 2-11 Component Conformance Statement Example

attribute COMPONENT_CONFORMANCE of My_Old_IC:entity is
"STD_1149_1_1990"; -- 1990 component described in 1994 BSDL

IEEE BSDL 2
Copyright © 2001 IEEE All rights reserved.
Device Package Pin Mappings

The mapping of logical signals onto the physical pins of a particular
component package is defined through use of an attribute statement and a
BSDL string. The device package pin mappings uses the following form:
Example 2-12 Device Package Pin Mappings Syntax

<device package pin mappings> ::=<pin map statement> <pin mappings>
<pin map statement> ::= attribute PIN_MAP of <component name> : ENTITY IS
PHYSICAL_PIN_MAP;
<pin mappings> ::= <pin mapping> { , <pin mapping> }
<pin mapping> ::= constant <pin mapping name> : PIN_MAP_STRING :=
<map string>;
<pin mapping name> ::= <VHDL identifier>
<map string> ::= "<port map> { , <port map> }"
<port map> ::= <port name> : <pin list>
<pin list> ::= <pin ID> | ( <pin ID> { , <pin ID> } )
<pin ID> ::= <VHDL identifier> | <integer>
No subscripting of <port name> is allowed. Only the base name of a

NOTE
port may appear if the port was described to be a bit_vector.
Example 2-13 Device Package Pin Mappings Example

attribute PIN_MAP of ttl74bct8374 : entity is PHYSICAL_PIN_MAP
constant DW:PIN_MAP_STRING:=
"CLK:1, Q:(2,3,4,5,7,8,9,10)," &
"D:(23,22,21,20,19,17,16,15)," &
"GND:6, VCC:18,OC_NEG:24,TDO:11,TMS:12,TCK:13,TDI:14";
constant FK:PIN_MAP_STRING:=
"CLK:9, Q:(10,11,12,13,16,17,18,19)," &
"D:(6,5,4,3,2,1,26,25), GND1:15, VCC1:8," &
"GND2:14,VCC2:22, OC_NEG:7,TDO:20, TMS:21, TCK:23, TDI:14";
Attribute PIN_MAP is a string that is set to the value of the parameter

PHYSICAL_PIN_MAP, which was defined by the generic statement. VHDL
constants are then declared, one for each packaging variation. In the
sample description, two packaging variations exist: DW and FK.
The constants identify component packages that are typified for BSDL
purposes by the mapping between logical port names and the physical pins
of a component. Agilent Test System software looks for the constant with

2 IEEE BSDL
a name matching the value of PIN_MAP. BSDL’s standard practice

mandates that the type of the constant must be PIN_MAP_STRING. An
example of a <map string> is shown below.
Example 2-14 Map String Example

"CLK:1,Q:(2,3,4,5,7,8,9,10), D:(23,22,21,19,17,16,15)," &
"GND:6, VCC:18, OC_NEG:24, TDO:11, TMS:12, TCK:13, TDI:14"
Notice that this is the concatenation of two smaller strings. Agilent Test
System software reads the contents of the string. It matches signal names,
such as CLK, with the names in the port definition. For a given <port
map>, the <pin list> identifies the physical pin (or set of physical pins)
associated with the port called <port name>. A <pin ID> may be a number
or an alphanumeric identifier because some component packages, such as
Pin- Grid Arrays (PGA)s, use coordinate identifiers, such as A07 or H13.
Note, that however, that names like 7A and 13H are illegal since they are
not valid VHDL identifiers.
If signals such as that having <port name> Q in the above example are
identified as bit_vector in the <logical port description>, then there must
be a one- to- one mapping between the members of that bit_vector and the
members of the <pin list> associated with Q. The ordering of items in the
<pin list> is significant, and the ordering provides correlation between a
given <subscripted port name> and its associated <pin ID>. For example, if
Q were defined to have members "1 to 8", then the physical pin mapped
onto port Q(1) in the example above (for the DW component package)
would be pin 2 and Q(2) would be pin 3, etc. If Q were defined to have
members "8 downto 1" then Q(1) would be pin 10 and Q(2) would be pin 9,
etc.
Within a given <pin mapping> each <pin ID> will appear only once.
All non- linkage ports in the <logical port description> of a given BSDL
description will be referenced in each <pin mapping> of that description,
and vice versa. Separate BSDL descriptions are required for components
that do not have pin connections for some non- linkage signals.
For a given <port map> the number of members in the <pin list> must be
the same as the number of bits of the port’s bit_vector, or 1 if the relative
<port dimension> is bit.
The <port map> for a <port name> defined as bit in the <logical port
description> has to be defined using a single <pin ID> without a subscript.
The <port map> for a <port name> defined as a bit_vector in the <logical
description> has to be defined using one or more <pin ID> elements within
parenthesis.
Each <pin mapping name> must be unique within a <pin mappings>.

IEEE BSDL 2
Any <port name> element in a <port mapping> element of a given BSDL

description must appear in an <identifier list> element of the <logical port
description> statement of the description.
There may be different numbers of linkage ports among packaging variants
for a component. It is strongly recommended that all physical linkage pins
be included in a <pin mapping>.
Grouped Port Identification

The optional <grouped port identification> is used to identify system I/O
signals that have the special characteristic of using more than one pin to
carry a bit of data and for which the allowed states of the pins are
restricted. Typically, these are differential pairs of signals, operating either
in the voltage or current domains.
With differential pairs where one signal is always the complement of the
other (a state restriction), there is a Plus pin and a Minus pin. A
differential pair may need to be treated as an analog circuit with a single
boundary- register cell providing or receiving data. However, due to the
prevalence of differential signaling and the fact that digital data is indeed
being transmitted, it is desirable to accomplish boundary- scan interconnect
testing on each pin of a differential signal pair. The grouped port
identification is used to describe such a situation to test generation
software.
Ports must have a <group port identification> when the state restrictions
apply during boundary- scan operation. If the ports are restricted during
normal system operation but not during boundary- scan operation, then
the <grouped port identification> is not needed. Grouped port
identification uses the following form:
Example 2-15 Grouped Port Identification Syntax

<grouped port identification> ::=
attribute PORT_GROUPING of <component name> : entity is <group table string>;
<group table string> ::= " <group table> "
<group table> ::= <twin group entry> {, <twin group entry> }
<twin group entry> ::= <twin group type> ( <twin group list> )
<twin group type> ::= DIFFERENTIAL_VOLTAGE | DIFFERENTIAL_CURRENT
<twin group list> ::= <twin group> {, <twin group>}
<twin group> ::= ( <representative port>, <associated port> )
<representative port> ::= <port ID>
<associated port> ::= <port ID>
The <representative port> pin is to be treated as the positive ( + ) pin of

a differential pair. The <associated port> is the negative ( - ) pin of a
differential pair.

2 IEEE BSDL
Example 2- 16 includes a <boundary- scan register description> to illustrate

certain semantic relationships.
Example 2-16 Grouped Port Identification Example

entity diff is
generic(Physical_Pin_Map:string := "Pack";
port (CLK:in bit;

D_Pos:in bit_vector(1 to 4);
D_Neg:in bit_vector(1 to 4);
Q_Pos:out bit_vector(1 to 4);
Q_Neg:out bit_vector(1 to 4);
GND, VCC:Linkage bit; OC_NEG:in bit; TDO:out bit;
TMS, TDI, TCK:in bit);
use STD_1149_1_2001.all; -- Get Std 1149.1-2001 attributes/definitions
attribute PIN_MAP of diff : entity is PHYSICAL_PIN_MAP;
constant PACK:PIN_MAP_STRING:"CLK:1, " &

"Q_Pos:(2,3,4,5), " &
"Q_Neg:(23,22,21,20)," &
"D_Pos:(23,22,21,20)," &
"D_Neg:(19,17,16,15)," &
"GND:6, VCC:18, OC_NEG:24, TDO:11, TMS:12, TCK:13, TDI:14";
attribute PORT_GROUPING of diff : entity is

"Differential_Voltage ( (Q_Pos(1), Q_Neg(1)), " & __ voltage signals
"(Q_Pos(2), Q_Neg(2)), " &
"(Q_Pos(3), Q_Neg(3)), " &
"(Q_Pos(4), Q_Neg(4)))," &
"Differential_Current ( (D_Pos(1), D_Neg(1)), " & -- current signals
"(D_Pos(2), D_Neg(2)), " &
"(D_Pos(3), D_Neg(3)), " &
"(D_Pos(4), D_Neg(4))) " ;
(...some BSDL deleted...)
attribute BOUNDARY_REGISTER of diff : entity is
-- num cell port function safe [ccell disval rslt]
"9 (BC_1, CLK, input, X)," &
"8 (BC_1, OC_NEG, input, X)," & -- Merged Input/Control
"8 (BC_1, *, CONTROL)," & -- Merged Input/Control
"7 (BC_1, D_Pos(1), input, X)," &
"6 (BC_1, D_Pos(2), input, X)," &
"5 (BC_1, D_Pos(3), input, X)," &
"4 (BC_1, D_Pos(4), input,) X)." &
"3 (BC_1, Q_Pos(1), output3, X, 8, 1, Z)," &
"2 (BC_1, Q_Pos(2), output3, X, 8, 1, Z)," &
"1 (BC_1, Q_Pos(3), output3, X, 8, 1, Z)," &
"0 (BC_1, Q_Pos(4), output3, X, 8, 1, Z)";
end diff:

IEEE BSDL 2
This BSDL description describes four pairs of voltage differential pins and
four pairs of current differential pins. Any <port ID> used in a <grouped
port identification> must have been declared in the <logical port
description> statement and name a signal of a non- linkage type.
Note the following:
• If a <port ID> is a <subscripted port name>, the <subscript> has to lie
within the range specified for the relevant port’s bit_vector.
• Any <port ID> appearing as a <representative port> has to also appear
as a <port ID> in a <cell spec> in the subsequent <boundary- scan
register description>.
• Any <port ID> appearing as an <associated port> must not appear as a
<port ID> in a <cell spec> in the subsequent <boundary- scan register
description>.
• The two ports listed in a <twin group> have to have the same pin type.
• Any <port ID> appearing in a <twin group> must be a <subscripted port
name>, or a <port name> defined in a <logical port description>
statement with corresponding <port dimension> equal to bit.
Scan Port Identification

The scan port identification statements define the component’s TAP and
adhere to the following format:
Example 2-17 Scan Port Identification Syntax

<scan port identification> ::= ¦ <TCK stmt> <TDI stmt> <TMS stmt> <TDO stmt>
[ <TRST stmt> ] ¦
<TCK stmt> ::= attribute TAP_SCAN_CLOCK of <port ID> : signal is
(<clock record>);
<TDI stmt> ::= attribute TAP_SCAN_IN of <port ID> : signal is true;
<TMS stmt> ::= attribute TAP_SCAN_MODE of <port ID> : signal is true;
<TDO stmt> ::= attribute TAP_SCAN_OUT of <port ID> : signal is true;
<TRST stmt> ::= attribute TAP_SCAN_RESET of <port ID> : signal is true;
<clock record> ::= <real number> , < halt state value>
<halt state value> ::= LOW | BOTH
The statements identify specific logical signals of the component as being

signals of the TAP.

2 IEEE BSDL
A <clock record> is a pair consisting of:

• A real number that gives the maximum operating frequency for TCK in
Hertz.
• A VHDL type that can have one of two values: LOW and BOTH. This
specifies the state(s) in which the TCK signal may be stopped without
causing loss of data held in the test logic. BOTH indicates that the
clock can be stopped in either state. Components that allow TCK to be
stopped only in the high state do not conform to this standard.
IEEE Standard 1149.1 dictates that a device clock can stop in either
NOTE
the LOW state or BOTH; it does not allow for stopping the clock in the
HIGH state alone.
Example 2-18 Scan Port Identification Example

attribute TAP_SCAN_IN of TDI : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;
attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_RESET of TRST : signal is true;
attribute TAP_SCAN_CLOCK of TCK : signal is (20l.0e6, BOTH);
Signal names TDI, TDO, TMS, TRST, and TCK are used in the <logical port
description> in the above example. These names are those defined by
IEEE; however, arbitrary names could have been used.
Regarding the <port ID> elements in the <scan port identification>:
• The unique <port name> element in a <port ID> occurring in a <TDO
stmt> must appear as a value in an <identifier list> of a <pin spec> in
the <logical port description>. The value of <pin type> on that <pin
spec> has to be out.
• The unique <port name> element in a <port ID> occurring in a <TCK
stmt>, a <TDI stmt>, a <TMS stmt>, or a <TRST stmt> must appear as a
value in an <identifier list> of a <pin spec> in the <logical port
description>. The value of <pin type> on that <pin spec> has to be in.
• Any <port ID> appearing in the <scan port identification> has to be
<subscripted port name>, or a <port name> defined in a <logical port
description> statement with corresponding <port dimension> equal to
bit.
• No <port ID> in the <scan port identification> may appear in the
<boundary- scan register description>.
• A given <port ID> may occur at most once in the <scan port
identification>.
• If <port ID> is a <subscripted port name>, the <subscript> has to lie
within the range specified for the relevant port’s bit_vector.

IEEE BSDL 2
• No value of a <port ID> element in the <scan port identification> can

have appeared as a <representative port> or an <associated port> in a
<twin group>.
Compliance Enable Description

This section of a BSDL description has to appear in the description of a
component if the optional compliance enable feature has been
implemented in that component or bare chip. Otherwise, improper
operation of the part may occur during an automatically generated test.
Compliance enable description uses the following format:
Example 2-19 Compliance Enable Description Syntax

<compliance enable description> ::= attribute COMPLIANCE_PATTERNS of
<component name> : entity is <compliance pattern string> ;
<compliance pattern string> ::= " ( <compliance port list> ) ( <pattern list> )"
<compliance port list> ::= <port ID> { , <port ID>}
<pattern list> ::= <pattern> { , <pattern> }
A number of <pattern> elements can be specified, reflecting the fact

NOTE
that there may be many combinations of bits that enable compliance.
For convenience, a <pattern> may contain X bits to reduce the size of
a <pattern list>. As an example, the <pattern list> 1111X, 0XXX0
specifies ten unique bit patterns that enable compliance.
The Agilent In- circuit Test System associates <port ID> elements in
<compliance port list> positionally with the bits in a <pattern>. For
example, the first appearing <port ID> is associated with the first
(left- most) bit in <pattern>, and similarly with the rest.
Note the following:
• The number of <port ID> elements in the <compliance port list> is equal
to the number of bits in each <pattern> within the <pattern list>.
• No <port ID> value may occur more than once in the <compliance port
list>.
• No <port ID> value in the <compliance port list> may also appear as a
<port ID> value in the <scan port identification>.
• Each <port ID> value in the <compliance port list> must appear as a
value in an <identifier list> of a <pin spec> in the <logical port
description>. The value of <pin type> in that <pin spec> has to be in.
• No <port ID> value in the <compliance port list> may later appear in
the <boundary- scan register description>.

2 IEEE BSDL
• If a <port ID> value in the <compliance enable description> is a

<subscripted port name>, the <subscript> has to lie within the range
specified for the relevant port’s bit_vector.
• No <port ID> value in the <compliance port list> may also appear as a
<port ID> in the <group port identification>.
Example 2-20 Compliance Enable Description Example

attribute COMPLIANCE_PATTERNS of My_IC : entity is
"(Sig_A, Sig_B, Sig_C) (001)";
Instruction Register Description

The next segment of the BSDL description concerns the
component- dependent characteristics of the instruction register. The
details that need to be specified to characterize the implementation of the
instruction register in a particular component are:
• Length. The instruction register must be at least two bits long. Its
length is not otherwise limited.
• Instructions. The register is required to support certain instructions. A
designer may add any or all of the optional instructions identified or
any or all of the optional instructions identified or and/or any number
of design- specific instructions. Private instructions need to be marked
as private to warn applications not to use them in order to prevent
unsafe or undocumented behavior.
• Instruction codes (opcodes). BYPASS instruction is decoded from bit
patterns fixed by IEEE. Bit patterns for other instructions have to be
specified by the test logic designer. Each instruction may be decoded
from several bit patterns.
• Instruction capture. On passing through the Capture- IR controller
state, the instruction register loads data from its parallel input. In some
register stages, certain fixed values are required; but in other register
stages, design dependent values may be loaded.
BSDL must provide a means of describing these characteristics and take
advantage of opportunities for semantic checks, thus verifying that the
component is in compliance with the IEEE standard.
The characteristics of the instruction register specified using BSDL are its
length, the opcodes, the pattern captured in the Capture- IR controller
state, and whether any given instruction is public or private. The
instruction register description uses the following form:

IEEE BSDL 2
Example 2-21 Instruction Register Description Syntax

<instruction register description> ::= <instruction length stmt>
<instruction opcode stmt>
<instruction capture stmt>
[ <instruction private stmt> ]
<instruction length stmt> ::= attribute INSTRUCTION_LENGTH of <component name>
: entity is <integer> ;
<instruction opcode stmt> ::= attribute INSTRUCTION_OPCODE of <component name>
: entity is <opcode table string> ;
<instruction capture stmt> ::= attribute INSTRUCTION_CAPTURE of <component name>
: entity is <pattern list string> ;
<instruction private stmt> ::= attribute INSTRUCTION_PRIVATE of <component name>
: entity is <instruction list string> ;
<opcode table string> ::= " <opcode description> { , <opcode description> } "
<pattern list string> ::= " <pattern list> "
<pattern list> ::= <pattern> { , <pattern> }
<instruction list string> ::= " <instruction list> "
<instruction list> ::= <instruction name> { , <instruction name> }
<opcode description> ::= <instruction name> ( <pattern list> )
Example 2-22 Instruction Register Description Example

attribute INSTRUCTION_LENGTH of MY_IC: entity is 4; -- Must be first
attribute INSTRUCTIOM_OPCODE of MY_IC: entity is -- Must be second
"EXTEST (0000), " &
"EXTEST (0110), " &
"BYPASS (1111, 1000), " &
"SAMPLE (1100), " &
"THREESTATE (0101), " &
"SECRET (0001) ";
attribute INSTRUCTION_CAPTURE of MY_IC: entity is "0101"; -- Must be third
attribute INSTRUCTION_PRIVATE of MY_IC: entity is "secret"; -- Optional
In the above example, BYPASS was shown to be decoded from 1111.

NOTE
This is the mandatory pattern specified by the IEEE Standard, so its
expression is redundant and not required. However, notice that
BYPASS is given on another line with an additional decode. This
shows another way to document other decodes for standard
instructions.
The purpose of each attribute is described below.

• INSTRUCTION_LENGTH
• INSTRUCTION_OPCODE
• INSTRUCTION_CAPTURE
• INSTRUCTION_PRIVATE

2 IEEE BSDL
INSTRUCTION_LENGTH
The <instruction length stmt> defines the length of the instruction register,
and hence, the number of bits that each opcode pattern must contain in
subsequent statements of the <instruction register description>.
INSTRUCTION_OPCODE
The <instruction opcode stmt> is a BSDL string containing instruction
identifiers and their associated bit patterns. The right- most bit in the
pattern is that closest to TDO (that shifted in first). Each <opcode
description> is such a pair. The IEEE standard mandates the existence of
EXTEST, BYPASS, PRELOAD, and SAMPLE instructions, with mandatory
bit patterns for the BYPASS. Other bit patterns may also decode to these
instructions. Decoding of unused bit patterns defaults to the BYPASS
instruction.
For example, consider the following opcodes for a device:
attribute INSTRUCTION_OPCODE of ttl74bct8374
"BYPASS (11111111, 10001000)," &
"EXTEST (x000x000)," &
"PRELOAD (x0000010)," &
"SAMPLE (x0000010)";
The opcode for EXTEST (x000x000) could decode to one of four codes as
shown below:
00000000
10000000
00001000
10001000
The problem illustrated here is that the last code (10001000) is reserved
as a BYPASS opcode, so the bit positions list as X (don't care) are not
really don't care positions. You must ensure that such ambiguity does not
find its way into your BSDL file. If such a problem does exist in your file,
the BSDL compiler will generate an error message telling you that you
have ambiguous opcodes.
INSTRUCTION_CAPTURE
The <instruction capture stmt> specifies the bit pattern that is loaded into
the instruction register when the TAP controller passes through the
Capture- IR state. This bit pattern is shifted out whenever a new
instruction is shifted in. The IEEE standard mandates that the least
significant bits must be "01". The remainder of this bit pattern is
design- specific.
IEEE Standard 1149.1-2001 mandates this 01 pattern to aid in the

NOTE
detection of failures when the device is being tested.

IEEE BSDL 2
INSTRUCTION_PRIVATE
The optional <instruction private stmt> identifies instructions that are
private and potentially unsafe for use by other than the component’s
manufacturer. By definition, the effects of these instructions are undefined
to the general public; and their use should be avoided.
Failure to follow warnings about private instructions can result in
CAUTION
damage to the component, circuit board, or system.
Additional details:
• The integer value of the attribute INSTRUCTION_LENGTH has to be
greater than or equal to 2. This value is to be interpreted as the length
of the instruction register.
• All opcodes defined within a <pattern list> have to have length equal to
that of the instruction register.
• The all 1’s opcode must decode to BYPASS or, not be defined explicitly
for any instruction.
• Opcodes for SAMPLE and PRELOAD have to be defined, and the
<opcode description> to which each is defined must have SAMPLE and
PRELOAD as the value of its <instruction name> element, respectively.
Note that each instruction may decode to the SAME opcode bit pattern,
as a single opcode can be used to implement both functions.
• Opcodes containing X bits must not be ambiguous (decodable as two or
more different instructions). That is, if there are two <opcode
description> elements and two <pattern> elements such that one
appears in each of the two <opcode description> elements, the two
<pattern> elements must differ in some character position in which
neither pattern contains the character X.
• The <pattern> value in the <instruction capture stmt> has to have a
length equal to that of the instruction register. The two least significant
bits of this <pattern> have to be 01.
• Only user defined instructions can be defined as private.
• Any <instruction name> appearing in an <instruction list> must appear
only once and also appear in the <opcode table>.

2 IEEE BSDL
Optional Register Description

This section identifies whether the optional device identification register is
provided by specifying the bit patterns returned in response to selection of
the device identification register instructions – IDCODE and if implemented,
USERCODE. The optional register description uses the following format:
Example 2-23 Optional Register Description Syntax

<optional register description> ::= ¦ <idcode statement> [ <usercode statement>
] ¦
<idcode statement> ::= attribute IDCODE_REGISTER of <component name>
: entity is <32-bit pattern list string> ;
<usercode statement> ::= attribute USERCODE_REGISTER of <component name>
: entity is <32-bit pattern list string> ;
<32-bit pattern list string> ::= " <32-bit pattern list> "
<32-bit pattern list> ::= <32-bit pattern> { , <32-bit pattern> }
Example 2-24 Optional Register Description Example

attribute IDCODE_REGISTER of MY_IC : entity is
"0011" & -- version
"1111000011110000" & -- part number
"00001010100" & -- manufacturer’s identity
"1"; -- required by 1149.1
attribute USERCODE_REGISTER of MY_IC : entity is

"10XX" & "0011" & "1100" & "1111" & -- start of 1st 32-bit pattern
"0000" & "0000" & "0000" & "1111", "& -- end of 1st 32-bit pattern
"111X" & "0011" & "1001" & "1000" & -- start of 2nd 32-bit pattern
"0000" & "0100" & "1001" & "1000"; -- end of 2nd 32-bit pattern
In the above example, concatenation is used to delimit fields within the

codes. An X may be used to mask subfields within a code that are not
important for testing purposes; X specifies a “don’t care.” It is also
possible that a single component type may be sourced from different
manufacturers with different version fields. The <32- bit pattern list>
allows all desired sourcing to be fully specified without using X bits.
If a device identification register is specified by inclusion of an <idcode
statement>, the least significant bit in any <32- bit pattern> element within
the <idcode statement> has to be 1.
An <idcode statement> appears in a BSDL description if and only if
IDCODE appears as the value of an <instruction name> element in an
<opcode description> of the <instruction opcode stmt>.
A <usercode statement> appears in a BSDL description if and only if both
IDCODE and USERCODE appear as the value of <instruction name>
elements in an <opcode description> of the < instruction opcode stmt>.

IEEE BSDL 2
A bit pattern (Bits 11- 1 equal to 00001111111) in the manufacturer code

is illegal.
Register Access Description

All instructions must place a test data register between TDI and TDO.
User- defined instructions may access test data registers mandated by the
IEEE standard or design- specific registers. The IEEE standard allows a
designer to place additional test data registers, referenced by user- defined
instructions, in the component.
It is important for test development software to know of the existence and
length of all test data registers and the names of their associated
instructions. Register address description uses the following format:
Example 2-25 Register Access Description Syntax

<register access description> ::=
attribute REGISTER_ACCESS of <component name> : entity is <register string> ;
<register string> ::= " <register association> { , <register association> } "
<register association> ::= <register> ( <instruction capture list> )
<instruction capture list> ::= <instruction capture> { , <instruction capture> }
<instruction capture> ::= <instruction name> [ CAPTURES <pattern> ]
<register> ::= BOUNDARY | BYPASS | DEVICE_ID |
<VHDL identifier> <left bracket> <register length> <right bracket>
<register length> ::= <integer>
Example 2-26 Register Access Description Example

attribute REGISTER_ACCESS of ttl74bct8374 : entity is
"BOUNDARY (READBN, READBT, CELLTST), " &
"BYPASS (TOPHIP, SETBYP, RUNT, TRIBYP)," &
"BCR [2] (SCANCN, SCANCT CAPTURES OX)";
In this example, READBN, READBT, CELLTST, TOPHIP, SETBYP, RUNT,

TRIBYP, SCANCN must be defined in the <instruction opcode stmt>. The
first three instructions select the boundary- scan register, while the next
four instructions select the bypass register. Note that the last two
instructions (SCANCN and SCANCT) select a two- bit register called BCR
[2]. This is a design- specific test data register. The SCANCT instruction
also shows a capture value 0X that is loaded into BCR[2] when passing
through Capture- Dr. No capture value is specified for the SCANCN
instruction.
By identifying the association between instructions and test data registers,
Agilent Test System software can determine the length of the test data
scan sequence for a given instruction. The lengths of the mandatory
boundary- scan register, bypass register, and instruction register, as well as
the optional identification register, are known from other statements as

2 IEEE BSDL
well as from their relationship to the component’s instructions. A semantic

check will be made to ensure that each instruction has an associated test
data register as required by IEEE.
Exceptions to this are private instructions. They are not to be accessed,
nor do their target registers need to be identified. Because these
instructions should not be used by component users, their associated test
data registers need not be defined in the BSDL description.
Note that IEEE allows user instructions to reference several registers at
once in a concatenated mode. In BSDL, the logical register resulting from
such a concatenation is treated as if it were a separate register with a
distinct name and length.
The association of registers with the BYPASS, CLAMP, EXTEST, HIGHZ,
IDCODE, INTEST, SAMPLE, PRELOAD, and USERCODE instructions is
mandated by IEEE. Description of these assignments is redundant and not
needed in BSDL, but if they are given, then:
• They must be checked against the mandatory assignment specified by
IEEE and an error issued if not correct.
• They nust not have a "CAPTURES <pattern>" element in their
description.
Any public instruction defined in the <instruction register description> not
listed in any of the above registers, has to have an associated test data
register defined.
The length of each publicly accessible design- specific test data register has
to be specified and must be greater than 0; if the <register> appears in
more than one <register association> the first appearance must define the
length and subsequent appearances may either not define it again, or
define it identically.
All instructions, the names of which appear as the value of an
<instruction name> element in any <instruction capture> element of the
<register string>, have to appear as an <instruction name> element in an
<opcode description> element in the <instruction opcode stmt>.
Any <instruction name> element must appear in only one <instruction
capture list> within the <register string>.
The <pattern> value in an <instruction capture> element has to contain the
same number of bits as the <register> in the same <register association>.

IEEE BSDL 2
Boundary-Scan Register Description

The <boundary- scan register description> contains a list of boundary- scan
cells, numbered 0 to LENGTH- 1, where the total number of cells in the
register is LENGTH. The cells may be listed in any order, but all must be
defined. Cell 0 is closest to TDO. The boundary- scan register cells can
vary in design and purpose.
The characteristics of each cell design used in a component must be
specified before the cells can be referenced in the <boundary- scan register
description>. For example, cell designs included in IEEE are contained in
the standard VHDL package STD_1149_1_2001. Cells defined in this VHDL
package may be referenced through a simple set of names listed in
Table 2- 2.
Table 2-2 List of Cells Defined in the Standard VHDL Package and Relevant Figure Numbers in IEEE 1149.1-2001
Name Figures Comments

BC_0 Special cell See note 2 below
BC_1 11-18, 11-30, 10-31c, 11-34, 10-41d, 11-36 Design usable for many functions
BC_2 10-14, 10-30, 10-32c, 10-32d, 10-35c INTEST unsupported on Output2
BC_3 10-15 Input or Internal only
BC-4 11-16, 11-17 Input, Observe-Only, Clock or Internal only
BC_5 10-41c Combined Input/Control
BC_6 10-35d Bidirectional, see note 3 below
BC_7 11-37 Bidirectional, preferred
The suffix c is used to denote a control cell shown in a cited figure.

NOTE
The suffix d denotes a data cell.
BC_0 is a cell that captures the value specified by the rules of IEEE
and captures a “don’t care” value whenever IEEE allows options. It
can be used whenever there is uncertainty about the exact behavior of
a compliant cell.
BC_6 is conformant to IEEE, but lacks desirable features and is not
recommended for use in new designs. The design for BC_7 is
preferred.
The method of describing cells other than those depicted in IEEE is

described in Section 0.2. When such cell designs are to be used their
descriptions must be given in a user- supplied VHDL package and VHDL
package body.

2 IEEE BSDL
A very general cell design from IEEE (figure 11- 18) is shown in
Figure 2- 2. Figure 2 shows a symbolic representation of the same cell
design.
The design consists of a parallel input (PI), a parallel output (PO), a
multiplexer controlled by a mode signal, and two flip- flops. The mode
signal is a function of the current instruction. A serial input (SI) and a
serial output (SO) form the shift path through the cell. The mode signal is
a logic 0 or 1 that tells a cell what test function to perform.
Note that the symbolic representation does not include the following:
• the multiplexer controlled by signal ShiftDR.
• the mode signal and multiplexer.
• the clock signals, ClockDR and UpdateDR.
These parts of the cell design do not need to be considered in BSDL
because the control and operation of boundary- scan register cells is fully
defined by IEEE. Figure 2- 3 is a full representation of the cell design
shown in Figure 2- 2 for the purposes of BSDL.
Figure 2-2 Cell Design Corresponding to IEEE Figure 11-18
(Shift)
Scan Out Mode
(SO)
Shift-DR
MUX
Parallel in 1 Parallel out

(PI) 1 (PO)
MUX
Shift-Register Latch
Flip-Flop Flip-Flop
Scan In Clock-DR Update-DR

(SI) (Capture
(Shift) and Shift) Source: IEEE Standard 1149.1
The parallel input and output are shown on the symbol and these are
connected to various places depending on the application. The two
flip- flops are labeled CAP and UPD to represent their uses. The CAP
flip- flop captures data from the cell’s system data input in the Capture-DR
controller state and lies on the shift register path. The UPD flip- flop loads
data from the CAP flip- flop in the controller state. The shift path is

IEEE BSDL 2
shown because many such cells will be linked together in a shift chain
that makes up the boundary- scan register. The shift path links only the
CAP flip- flops.
One cell design shown in Figure 2- 3 is an observe- only cell and has a
symbol with no UPD flip- flop. This cell can be used at a system input pin
and has the advantage of lower propagation delay in some
implementations. However, it does not support the optional INTEST
instruction if provided at a non- clock input.
Figure 2-3 Two Symbols for a Typical Boundary-Scan Cell
SO SO
C U C
PI A P PO PI A PO
P D P
(a) (b)
SI SI
The symbols in Figure 2- 4 on page 2- 31 show a bubble on top of the UPD

flip- flop (indicating that the flip- flop may be preset to 1) or a bubble on
the bottom (indicating that the flip- flop may be cleared to 0) when the
Test-Logic-Reset controller state is entered. No signal connection is made to
these bubbles.
The resetting or clearing of the cell has to be consistent with rule
NOTE
11.6.1p of the IEEE standard, which states the value forced into the
cell has to be the one that would disable the associated drivers.
Figure 2-4 Symbols for a Boundary Cell with Preset (a) and Clear (b) on the UPDATE
Flip-Flop
SO SO
C U C U
PI A P PO PI A P PO
P D P D
(a) (b)
SI SI
The Boundary- Scan Register Description uses the following form:

2 IEEE BSDL
Example 2-27 Boundary-Scan Register Description Syntax

<boundary-scan register description> ::= <boundary length stmt> <boundary
register stmt>
<boundary length stmt> ::=
attribute BOUNDARY_LENGTH of <component name> :entity is <integer> ;
<boundary register stmt> ::= attribute BOUNDARY_REGISTER of <component name>
: entity is <cell table string> ;
<cell table string> ::= " <cell table> "
<cell table> ::= <cell entry> { , <cell entry> }
<cell entry> ::= <cell number> ( <cell info> )
<cell number> ::= <integer>
<cell info> ::= <cell spec> [ , <disable spec> ]
<cell spec> ::= <cell name> , <port ID or null> , <function> , <safe fit>
<cell name> ::= <VHDL identifier>
<port ID or null> ::= <port ID> | *
<cell name> ::= INPUT | OUTPUT2 | OUTPUT3 | CONTROL |
CONTROLR | INTERNAL | CCLOCK | BIDIR | OBSERVE_ONLY
<safe bit> ::= 0 | 1 | X
<disable spec> ::= <ccell> , <disable value> , <disable result>
<ccell> ::= <integer>
<disable value> ::= 0 | 1
<disable result> ::= Z | WEAK0 | WEAK1 | PULL0 | PULL
Example 2-28 Boundary Length Example

attribute BOUNDARY_LENGTH of ttl74bct8374 " entity is 18;
The <boundary length stmt> defines the number (LENGTH) of cells in the
boundary- scan register. This number has to match the number of <cell
entry> elements in the <boundary register stmt>, which describes the
structure of the boundary- scan register. Some cells may require two lines
of description.
Example 2-29 Boundary Register Example

attribute BOUNDARY_REGISTER of ttl74bct8374 : entity is
--
--num cell port/* function safe [ccell disval rslt]
--
"17 (BC_1, CLK, input, X),"&
"16 (BC_1 OC_NEG, input, X),"&
"16 (BC_1, *, control, 1),"&
. . .
. . .
"3 (BC_1, Q(5), output3, x, 16, 1, Z),"&
"2 (BC_1, Q(6), output3, X, 16, 1, Z)."&
"1 (BC_1, Q(7), output3, X, 16, 1, Z),"&
"0 (BC_1, Q(8), output3, X, 16, 1, Z)";

IEEE BSDL 2
Cell Entry Elements

The <boundary register stmt> contains a string (<cell table strings>) within
which there is a list of elements (<cell entry>), each with two fields. The
<cell entry> elements may be listed in any order, but all must be listed.
• The <cell number> element must be in the range from 0 to LENGTH- 1.
• The <cell info> contains a list of either four or seven elements
contained within parentheses.
All <cell entry> elements have to include values for the first four elements
of the second field. Only <cell entry> elements for cells that drive system
outputs that can be set to an inactive drive state (open- collector or 3- state
outputs) have the remaining three elements of the second field, which
specify how the output may be disabled. If the <function> element is
OUTPUT3, or BIDIR, then the last three elements must be defined. If the
<function> element is BIDIR, then the action of placing the relevant driver
in the inactive drive state is taken as equivalent to setting the cell to
operate as a receiver. If the <function> element is OUTPUT2 then the last
three elements may or may not be defined depending on whether the
described driver is an asymmetrical driver, for example, open- collector
(VHDL <port type> equal to out), or capable of actively driving both states
(VHDL <port type> equal to buffer).
The <cell spec> and <disable spec> elements are defined as follows:
• <cell name> Element. This identifies the cell design used. It must match a
cell described in the standard VHDL package or a user- supplied VHDL
package.
• <port ID or null> Element. This element identifies the system input or
output connected to a given cell. Any name supplied for this element
must match the one specified in the <logical port description>. A cell
serving as an output control <port name> element with corresponding
<port dimension> previously described as a bit, or a <subscribed port
name> can be supplied as the value of a <port ID or null> element.
• <function> Element. This element defines the primary function of the
relevant cell. Table 2- 3 lists the possible values of the <function>
element.

2 IEEE BSDL
Table 2-3 Functional Element Values and Meaning
Value/Function Meaning Example figure in

1149.1b-2001
INPUT A cell that has observe capability (control-and-observe with Figure 11-18, Figure 11-16
INTEST) and is connected to a system pin. This pin can have a
<pin type> value of "in" or "inout" only.
CLOCK An observe-only cell connected to system input clock pins Figure 11-17
only, and allows support of INTEST.
OUTPUT2 A cell that drives a 2-state (either symmetric or asymmetric) Figure 11-30
output and is connected to a system pin with a <pin type>
value of "out", "buffer", or "inout" only.
OUTPUT3 A cell that drives data to a 3-state output and is connected to a Figure 11-34
system pin with a <pin value> of "out", or "inout" only.
CONTROL A cell that controls a 3-state enable or direction control to one Figure 11-36
or more output drivers or bidirectional pins. It is not referenced
to a system pin in the <cell spec> element
CONTROLR A control cell that is forced to its disable state in the Figure 11-36
Test-Logic-Reset controller state.
INTERNAL A cell not associated with a device signal pin, that captures
constants "1", "0", or "X". It is a place-holder cell and cannot
be connected to a system pin.
BIDIR A reversible cell for a bidirectional pin and is connected to a Figure 11-37
system pin with a <pin type> inout only.
OBSERVE_ONLY A solitary observe-only cell on an input, or an additional cell Figure 11-17
observing any device signal pin not exempted by checks.
Notice that many of the cell designs are somewhat general, meaning that
they can be used in more than one context. The value of the <function>
element has important implications in describing a given cell.

IEEE BSDL 2
System pin classification

• INPUT. A cell may have a <function> of INPUT or OBSERVE_ONLY.
Additional cells with <function> INPUT or OBSERVE_ONLY may be
connected to the INPUT pin. If INTEST is a supported instruction, then
there must be at least one cell with <function> of INPUT connected to
the INPUT pin.
• CLOCK. There are two cases:
• At least one cell must have a <function> of CLOCK. Additional cells
with <function> OBSERVE_ONLY may also be connected to the pin.
This case is used where external clocking must be supplied to
support INTEST or RUNBIST.
• At least one cell must have a <function> of INPUT. Additional cells
with <function> INPUT or OBSERVE_ONLY may also be connected to
the CLOCK pin. This case is used where clocking must be supplied
by shifting to support INTEST.
• TWO-STATE OUTPUT. One cell must have a <function> of OUTPUT2.
Additional cells with <function> OBSERVE_ONLY may also be connected
to the pin.
• THREE-STATE OUTPUT. One cell must have a <function> of OUTPUT3.
Additional cells with <function> OBSERVE_ONLY may also be connected
to the pin.
• BIDIRECTIONAL. There are two cases:
• A single cell with <function> BIDIR attached to the pin. Additional
cells with <function> OBSERVE_ONLY may also be connected to the
pin.
• A two- cell structure used to create bidirectionality; one of these cells
must have a <function> of either OUTPUT2 or OUTPUT3, and the
other cell must have a <function> of either INPUT or
OBSERVE_ONLY. Additional cells with <function> OBSERVE_ONLY
may also be connected to the pin.

2 IEEE BSDL
System logic classification

• INPUT or CLOCK. There are two cases:
• Cell provisions are the same as noted for system INPUT or CLOCK
pins above.
• System logic receiving data from analog circuitry, cells with
<function> INTERNAL are connected.
• OUTPUT DATA or OUTPUT_CONTROL. There are two cases:
• Cell provisions are the same as noted for system pins above; and
additional cells with <function> INTERNAL may also be connected,
but are not referenced to a system pin in the <cell spec> element.
• System logic providing data to analog circuitry, cells with <function>
INTERNAL are connected but are not referenced to a system pin in
the <cell spec> element.
Cells may exist that are not connected to system pins or to system logic
due to the programming of programmable system logic. Such cells must
have <function> values of INTERNAL.
The <safe bit> Element

This element supplies a value that should be loaded into a given cell’s
CAP flip- flop (and UPD flip- flop if it exists) when board- level test
generation software might otherwise choose a value randomly. Three
examples are:
• The value in a control cell that turns off its associated drivers.
• The value that an output should have during INTEST that minimizes
driver current.
• A preferred value to present to on- chip logic at a component input
during EXTEST.
The <safe bit> value is not intended to force software to use particular
values for cells. Rather, it provides values for cells where software would
otherwise choose a 0 or 1 at random. An "X" signifies that the value does
not matter and that test generation software may assign either a 1 or 0, in
a case where there is no value the algorithm requires.
The <ccell> Element

This element identifies, for the relevant <port ID>, the <cell number> of
the control cell that can disable the output.

IEEE BSDL 2
The <disable value> Element

This element gives the value that must be scanned into the control cell
identified by the previous <ccell> element to disable the port named by the
relevant <port ID>.
The <disable result> Element

The value of <port ID> within a given <cell entry> element is the name of
a signal. If that signal can be disabled, the value of the <disable result>
element within the same <cell entry> specifies the condition of the driver
of that signal when it is disabled. The permissible values are:
• high impedance state (Z)
• weak "0" external pull down (WEAK0)
• weak "1" external pull up (WEAK1)
• weak "0" internal pull down (PULL0)
• weak "1" internal pull up (PULL1)
• weakly maintained value of last actively driven state (KEEPER)
The values WEAK1 and WEAK0 would be used for asymmetrical drivers
such as at TTL open- collector outputs. The values PULL0 and PULL1
would be used for asymmetrical drivers such as at TTL open- collector
outputs, when a pull down or a pull up is internal to the component. The
KEEPER value is used for drivers that latch and weakly hold the logic
state that was last actively driven by the driver. Such drivers weakly
maintain a logic state on their outputs rather than allow intermediate
voltages to exist.
By processing the <boundary- scan register description>, it is possible for
software to check that every non- linkage, non- TAP controller,
non- compliance enable, non- grouped port name in the port statement has
been named by a <port ID> of the <boundary- scan register description>.
Missing <port ID> values (other than linkage, TAP controller ports,
compliance- enable ports and grouped ports) identify digital system signals
lacking corresponding cells in the boundary- scan register, which indicates
a non- compliant device or an error in entering the BSDL description.

2 IEEE BSDL
Boundary-Scan Register Coding Rules

The coding rules are as follows:
• The value of the <integer> (LENGTH) in the <boundary length stmt> has
to be greater than zero.
• Every <cell entry> element of the <cell table> has to include a <cell
number> element with value in the range of 0 to LENGTH - 1.
• Every <integer> with a value between 0 and LENGTH - 1 must appear
as a <cell number> in some <cell entry> of the <boundary register
stmt>.
• Only a pair of merged cells may correspond to two <cell entry>
elements containing identical <cell number> elements in the <cell table>.
Moreover,
• The only possible mergers are of cells with <function> equal to
INPUT and cells with <function> equal to OUTPUT2, OUTPUT3,
CONTROL, or CONTROLR.
• The value of the <cell name> element in both <cell entry> elements
has to be equal.
• The <safe bit> values for these two cells have to be identical unless
one value is X.
• Every <cell name> appearing in the <cell table> has to be the name of a
cell described in either the Standard VHDL Package or a user- supplied
VHDL package.
• Any value of a <port ID> element in a <cell spec> that is not a
<subscripted port name> must be a <port name> in an <identifier list>
element of a <pin spec> in the <logical port description> such that the
value of the <port dimension> element in that <pin spec> is bit.
• Any <port name> of a <port ID> appearing in a <cell spec> must appear
in the <logical port description>; and, if a given <port ID> in a <cell
spec> is a <subscripted port name>, its <subscript> has to be in the
range of the <range> element in the <pin spec> element of the <logical
port description> in which the <VHDL identifier> of that <subscripted
port name> appears as a value of a <port name> element.
• A <port ID or null> has to have the value asterisk (*) when, in the
same <cell spec> elements, the <function> element has the value
CONTROL, CONTROLR, or INTERNAL.
• Any <cell info> element containing a <function> element equal to INPUT,
CONTROL, CONTROLR, INTERNAL, OBSERVE_ONLY, or CLOCK must
not also contain a <disable spec> element.
• Any <cell entry> element containing a <function> element equal to
OUTPUT3 or BIDIR must also contain a <disable spec> element.

IEEE BSDL 2
• Any <cell entry> element including a <function> element equal to

OUTPUT2 and also containing a <disable spec> element must satisfy the
condition that the value of <cell number> will equal the value of <ccell>.
This implies that an OUTPUT2 cell may control itself.
• Any <cell entry> including a <function> element equal to CONTROL or
CONTROLR, the value of the <cell number> element of that <cell entry>
must appear as the value of the <ccell> element of the <disable spec>
element of other <cell entry> elements.
• The <ccell> element of a <disable spec> element may only have the
values permitted under the conditions of the two preceding rules.
• When the value of <conformance identification> is SDT_1149_1_1994,
two distinct <disable spec> elements in the <boundary register stmt>
have <ccell> elements with a common value, the <disable value>
elements of these two <disable spec> elements must also have a
common value.
• Any <port ID> element appearing in a <cell entry> element of the
<boundary register stmt>, a <VHDL identifier> with the same value as
the given <port ID> element must appear in an <identifier list> of a
<pin spec> in the <logical port description>.
• If a <VHDL identifier> appears in an <identifier list> of a <pin spec> in
the <logical port description> and the <pin type> appearing in that <pin
spec> has the value linkage, the given <VHDL identifier> may never
appear as a:
• <port ID> in any <cell entry> of the <boundary register stmt> ,or
• the initial <VHDL identifier> of a <subscripted port name> serving as
a <port ID> in any <cell entry> of the <boundary register stmt>.
• Except for the elements listed below, all <port ID> elements with a
<VHDL identifier> appearing in an <identifier list> of a <pin spec> also
including a <pin type> not equal to linkage (in the <logical port
description> of the BSDL description) must appear as a <port ID> in
the <boundary register stmt>. Specifically exempted from this check are
any <port ID> elements satisfying any condition of semantic checks:
• grouped ports
• scan port identification
• compliance enable description
This semantic check means all non-exempted system pins have to be

NOTE
associated with cells in the boundary-scan register.
The three preceding checks state what <port ID> elements in the <logical
port description> must appear in the <boundary register stmt> and
vice- versa. The following checks state the properties that must exist for
<function> elements within <cell entry> elements.

2 IEEE BSDL
• Additional <cell entry> elements with <function> OBSERVE_ONLY may

have <port ID> elements in common with any other <cell entry> that
obeys the following semantic checks.
Additional OBSERVE_ONLY cells always monitor the state of a system

NOTE
I/O pin.
• Any <port ID> element appearing in a <cell entry> element of the

<boundary register stmt>, when the <pin type> in the <pin spec> of that
<port ID> is:
• in - The <function> of the <cell entry> can be INPUT, CLOCK, or
OBSERVE_ONLY only.
• out - The <function> of the <cell entry> can be OUTPUT2 or
OUTPUT3 only; furthermore, no other <cell entry> containing the
same <port ID> may have <function> OUTPUT2 or OUTPUT3.
• buffer - The <function> of the <cell entry> can be OUTPUT2 only and
the <cell entry> must not contain a <disable spec>; furthermore, no
other <cell entry> containing the same <port ID> may have
<function> OUTPUT2.
• inout - The <function> of the <cell entry> can be BIDIR, OUTPUT2,
OUTPUT3, INPUT, or OBSERVE_ONLY only; if the <function> value is
BIDIR, no other <cell entry> containing the same <port ID> may have
<function> BIDIR, OUTPUT2, or OUTPUT3; if the <function> of the
<cell entry> is OUTPUT2 or OUTPUT3, then no other <cell entry>
containing the same <port ID> may exist with the <function> value of
OUTPUT2 or OUTPUT3, and, at least one other <cell entry>
containing the same <port ID> has to exist with the <function> value
of INPUT or OBSERVE_ONLY, and vice- versa.
• The <function> in a <cell entry> must be an existing <cell context>
within the <capture descriptor> of the cell named by <cell name>.
Define the INTEST support capability of a given <cell entry> as follows:
1 Retrieve the <capture descriptor list> of the cell design named by the
<cell name> element.
2 For the <function> element value of:
• INPUT, CLOCK, OUTPUT2, OUTPUT3, CONTROL, or CONTROLR, find
one <capture descriptor> element in the <capture descriptor list> that
contains a <cell context> element value that matches the <function>
element value and has a <capture instruction> element value of
INTEST.
• BIDIR, find two <capture descriptor> elements in the <capture
descriptor list>, one with <cell context> element value of BIDIR_IN
and one with <cell context> element value of BIDIR_OUT, that both
have a <capture instruction> element value of INTEST.

IEEE BSDL 2
3 If the preceding step can be satisfied, the <cell entry> has INTEST
support capability, otherwise it does not.
Intest support capability cannot be satisfied for <function> element

NOTE
value of OBSERVE_ONLY. An OBSERVE_ONLY cell cannot by itself
provide INTEST support capability.
If INTEST occurs as the value of an <instruction name> element in an

<opcode description> element of the <instruction opcode stmt>, then, for
each <port ID> element satisfying semantic check above, there must
exist a <cell entry> referencing that <port ID> that possesses INTEST
support capability.

2 IEEE BSDL
RUNBIST Description
The goal of this section of BSDL description is to provide support for the
RUNBIST instruction as IEEE specifies. In some cases this may not
completely define the Built- In Self_Test (BIST) operational environment. In
such cases additional information must be supplied externally.
The following features of BIST implementation are not explicitly supported
by BSDL:
• Timing related information (beyond active clock and number of clock
cycles)
• Frequency and phase relationships of clocks
RUNBIST is a self- contained health check of the component. The present
clause conforms to the following requirements and constraints imposed by
IEEE.
A duration for BIST to complete execution has to be specified. This is
independent of the board environment. This duration can be given in
terms of absolute time (for example, devices clocked by internally
generated clocks) or, more commonly, by the number of clock cycles of
TCK and/or the system clock(s).
The steps required for completion of the execution of RUNBIST are as
follows:
1 (Optional) Initialize the boundary- scan register (for example, by
PRELOAD). This is required if the pin state during BIST is to be
determined by the data in the latched parallel outputs of the register.
2 Initiate BIST: scan the RUNBIST instruction into the instruction
register.
3 Execute BIST: cause the TAP controller to remain in its Run- Test/Idle
controller state for the duration required for completion of the
execution of BIST.
4 Evaluate BIST results: bring the TAP controller to the Shift- DR
controller state and scan out the test results (a signature) from the
register connected to TDI and TDO by the RUNBIST instruction.

IEEE BSDL 2
RUNBIST description uses the following format:
Example 2-30 Runbist Description Syntax

<runbist description> ::=
attribute RUNBIST_EXECUTION of <component name>
: entity is " <runbist spec> ";
<runbist spec> ::= <wait spec> , <pin spec> , <signature spec>
<wait spec> ::= WAIT_DURATION ( <duration spec> )
<duration spec> ::= <clock cycles list> | <time> [ , <clock cycles list> ]
<clock cycles list> ::= <clock cycles> { , <clock cycles> }
<time> ::= <real number>
<clock cycles> ::= <port ID> <integer>
<pin spec> ::= OBSERVING <condition> AT_PINS
<condition> ::= HIGHZ | BOUNDARY
<signature spec> ::= EXPECT_DATA <det pattern>
<det pattern> ::= <bit> { <bit> }
<bit> ::= 0 | 1
A <det pattern> is a contiguous sequence of one or more 0 and 1

characters containing no spaces or format effectors. For example, 001100
and 110101 are legal. However, 100 X00 is not legal because of the
embedded space and the X character.
Time is specified in seconds (by the value of <time> element). Where both
time and clock cycles are specified, they are to be interpreted as the
maximum of the time specified or the time required to apply the required
number of clock cycles. Where more than one clock is specified, the
duration is the time required for all of the clock cycles. Where more than
one clock is specified, the duration is the time required for all of the clock
inputs to receive the specified number of clock cycles.
Example 2-31 Runbist Description Example #1

attribute RUNBIST_EXECUTION of BIST_IC1: entity is
"Wait_Duration (1.0e-3)," &
"Observing HIGHZ At_Pins,"&
"Expect_Data 010101";
In Example 2- 31, the value of <time> in the <wait spec> is specified at 1

millisecond which is the minimum duration the device needs to stay in the
Run- Test/Idle controller state. Also, note that the output pins are forced to
high impedance which implies that there is no need to initialize the
update latches of the boundary- scan register.

2 IEEE BSDL

"Wait_Duration (TCK 23000)," &
"Observing HIGHZ At_Pins, "&
In Example 2- 32, the device needs to wait in the Run- Test/Idle controller
state for the duration sufficient for the application of 23000 clock cycles of
TCK.

"Wait_Duration (1.0e-3, TCK 23000)," &
"Observing HIGHZ At_Pins,"&
In Example 2- 33, <wait spec> is to be interpreted to mean that the

desired delay is the maximum of 1 millisecond or the time required for
TCK to receive 23,000 cycles.

"Wait_Duration (CLK 100000, SYSK 24000)," &
"Observing BOUNDARY At_Pins," &
In Example 2- 34, <wait spec> is to be interpreted as the time required for

CLK and SYSK to receive 100000 and 24000 clock cycles respectively. Also
note that the boundary- scan register is visible at the pins indicating that
it needs to be initialized prior to the execution of RUNBIST.
The number of bits in the value of the <det pattern> element of the
<signature spec> element has to be equal to the number of bits explicitly
defined as the value of the <integer> element in the <register> element of
that <register association> element of the <register access description> in
which RUNBIST appears as the value of an <instruction name> element.
Any value of <port ID> in the <wait spec> statement either has to:
• appear as the value of <port ID> in the <TCK stmt> of the BSDL
description or,
• appear as the value of <port ID> in a <cell spec> of the <boundary
register stmt> in which the <function> element has the value CLOCK.
If the <runbist description> statement occurs in a BSDL description,
RUNBIST has to be the value of some <instruction name> element in the
<opcode table> of the <instruction opcode stmt>.

IEEE BSDL 2
Values of <time> and <clock cycles> must be greater than 0.

A given <port ID> may not appear more than once in the <runbist
description> element.
The existence of RUNBIST in the INSTRUCTION_OPCODE table does
NOTE
not require <runbist description> to be specified in a BSDL
description.

2 IEEE BSDL
INTEST Description
The goal of this section of a BSDL description is to describe:
• How test patterns are to be applied to the component when the INTEST
instruction is selected (the source of clock pulses for the component
and the time for which the test logic must remain in the Run- Test/Idle
controller state to permit execution of each applied test).
• The external behavior of the component while the INTEST instruction is
selected.
Note that the test patterns themselves are not specified and are assumed
to be provided by an alternative method, not specified here. For INTEST,
the duration is not the duration for the entire test (as is the case of
RUNBIST) but the time required for the application of a single vector.
With the application of each vector by the boundary- scan register, IEEE
permits the device to execute a single step of operation which may require
several clock cycles to complete. Otherwise, the interpretation of <pin
spec> is identical to that in RUNBIST_EXECUTION.
INTEST description uses the following format:
Example 2-35 Intest Description Syntax

<intest description> ::=
attribute INTEST_EXECUTION of <component name>
: entity is "<intest execution sequence>";
<intest execution sequence> ::= <wait spec> , <pin spec>
Example 2-36 Intest Description Example #1

attribute INTEST_EXECUTION of IC1: entity is
"Wait_Duration (1.0e-3)," &
"Observing HIGHZ At_Pins";
In Example 2- 36, the value of <time> in the <wait spec> is specified at 1

millisecond which is the minimum duration the device needs to stay in the
Run_Test/Idle controller state. Also, note that the output pins are forced
to high impedance.
Example 2-37 Intest Description Example #2

attribute INTEST_EXECUTION of IC3: entity is
"Wait_Duration (CLK 100, SYSK 200)," &
"Observing BOUNDARY At_Pins";

IEEE BSDL 2
In Example 2- 37, <wait spec> is to be interpreted as the time required for

CLK and SYSCK to receive 100 and 200 clock cycles respectively. Also
note that the state of the pins is controlled by the data held in the
boundary- scan register.
Ports specified in the Wait_Duration statement must:
• have a TAP_SCAN_CLOCK attribute, or
• have a <function> value CLOCK in the <cell entry> element in the
BOUNDARY_REGISTER attribute.
If the <intest description> statement occurs in a BSDL description, INTEST
has to be the value of some <instruction name> element in the <opcode
table> of the <instruction opcode stmt>.
Values of <time> and <clock cycles> must be greater than 0.
A given value of <port ID> may not appear more than once in the <intest
description> element.
The existences of INTEST in the INSTRUCTION_ OPCODE table does

NOTE
not require <intest description> to be specified in a BSDL description.

2 IEEE BSDL
User Extensions to BSDL

Optional BSDL extensions provide a way to expand BSDL for proprietary
needs without losing compatibility with the mainstream definition of
BSDL. The VHDL standard package STD_1149_1_2001 defines a VHDL
subtype BSDL_EXTENSION. It allows the user to define foreign attributes
as being BSDL extensions. These will be ignored by a BSDL parser. BSDL
extensions must appear in an entity description as the last section before
the (optional) DESIGN_WARNING. This way, they may reference any data
items defined previously.
User extensions use the following form:
Example 2-38 User Extensions Syntax

<BSDL extensions> ::= <BSDL extension> { <BSDL extension> }
<BSDL extension> ::= <extension declaration> | <extension definition>
<extension declaration> ::= attribute <extension name> : BSDL_EXTENSION;
<extension definition> ::= attribute <extension name> of <component name> :
entity is <extension parameter string>;
<extension name> ::= <entity defined name> | <VHDL package defined name>
<entity defined name> ::= <VHDL identifier>
<extension parameter string> ::= <string>
An <extension definition> has to appear after its corresponding <extension

declaration>. The <extension declaration> may appear in the description
itself or in a user- supplied VHDL package. If several BSDL extensions
exist in the description, they may be intermixed in any manner as long as
declaration of an attribute precedes definition of that attribute. The ability
to define BSDL extensions in user- supplied VHDL packages allows global
definition of extensions.
Example 2- 39 first gives a user- supplied VHDL package containing a BSDL
extension that will be referenced by the entity example.
Example 2-39 User Extensions Example #1

Package Global_extension is -- BSDL extension package
-- Does not define Boundary Cells, just extensions
use STD_1149_1_2001.all;
-- deferred constant declarations would go here, if any
attribute First_extension : BSDL_EXTENSION; -- declare BSDL extensions here
attribute Second_extension : BSDL_EXTENSION;
attribute Third_extension : BSDL_EXTENSION;
end Global_extension;
package body Global_extension is
-- deferred constant definitions would go here, if any
end Global_extension;

IEEE BSDL 2
Example 2- 40 shows an entity that uses global extensions as well as local

extensions defined in the entity.
Example 2-40 User Extensions Example #2

entity example is
generic (PHYSICAL_PIN_MAP : string := "DW_PACKAGE");
port (CLK:in bit; Q:out bit_vector(1 to 8); D:in bit_vector(1 to 8);
GND, VCC:linkage bit; OC_NEG:in bit; TDO:out bit; TMS, TDI, TCK:in bit);
use STD_1149_1_2001.all;
use Global_extension.all; -- Get definitions of Global extensions
..Many deleted lines...
attribute Local_extension1 : BSDL_extension; -- Declare Local attribute name
attribute Local_extension2 : BSDL_extension -- Declare Local attribute name
-- Now, define some proprietary extensions that were declared in package
Global_Extension
attribute First_extension of example:entity is -- Define attribute
" String of data " &
" in proprietary form. " ;
attribute Second_extension of example:entity is " More data, etc. ";
attribute Local_extension1 of example:entity is "Finally defined ";
-- Local definition
-- Optional Design Warning still located here --
end example;
Not all declared extensions are defined in the preceding example

(Third_extension).
Any <VHDL Identifier> appearing as a value of the <extension name>
element in an <extension definition> must also appear as the value of the
<extension name> element of an <extension declaration> that occurs earlier
in the BSDL description or a given VHDL package than does the given
<extension definition>. In the case in which the <extension declaration>
occurs in a VHDL package, appearance of the corresponding <extension
definition> in the BSDL description has to be considered as an
“appearance after” the given <extension declaration>.
When inventing names for <extension name> elements, take care to

NOTE
assure uniqueness of the names with respect to names created in
other organizations that are also inventing extensions. Avoid common
names that might be thought of by others. You could append your
company’s name to the name to maximize uniqueness.

2 IEEE BSDL
Design Warning
A component designer may know of situations in which the system usage
of a component can be subverted by the boundary- scan feature and cause
circuit problems. As a simple example, a component may have dynamic
system logic which requires clocking to maintain its state. Thus, clocking
must be maintained when bringing the component out of system mode and
into test mode for INTEST. The DESIGN_WARNING attribute can be
assigned a string message to alert future consumers of the potential for
problems. Design warning uses the following format:
Example 2-41 Design Warning Syntax

<design warning> ::=
attribute DESIGN_WARNING of <component name> : entity is <string> ;
Example 2-42 Design Warning Example

attribute DESIGN_WARNING of My_ICa:entity is
"Dynamic device, " &
"maintain clocking for INTEST."
This warning is for application specific display purposes only. It is a

textual message of arbitrary length with no specific syntax and is not
intended for software analysis.

IEEE BSDL 2
Standard VHDL Package STD_1149_1_2001

The following is the complete content of Standard VHDL Package
STD_1149_1_2001. Note that both the VHDL package and package body are
shown.
Example 2-43 Standard VHDL Package

-- STD_1149_1_2001 VHDL Package and Package Body in support of
-- BSDL Version 2.0
--
package STD_1149_1_2001 is -- Created 20010530
-- Give pin mapping declarations
attribute PIN_MAP : string;

subtype PIN_MAP_STRING is string;
-- Give TAP control declarations
type CLOCK_LEVEL is (LOW, BOTH);

type CLOCK_INFO is record
FREQ : real;
LEVEL: CLOCK_LEVEL;
end record;
attribute TAP_SCAN_IN : boolean;

attribute TAP_SCAN_OUT : boolean;
attribute TAP_SCAN_CLOCK: CLOCK_INFO;
attribute TAP_SCAN_MODE : boolean;
attribute TAP_SCAN_RESET: boolean;
-- Give instruction register declarations
attribute INSTRUCTION_LENGTH : integer;

attribute INSTRUCTION_OPCODE : string;
attribute INSTRUCTION_CAPTURE : string;
attribute INSTRUCTION_PRIVATE : string;
-- Give ID and USER code declarations
type ID_BITS is ('0', '1', 'x', 'X');

type ID_STRING is array (31 downto 0) of ID_BITS;
attribute IDCODE_REGISTER : ID_STRING;
attribute USERCODE_REGISTER: ID_STRING;
-- Give register declarations
attribute REGISTER_ACCESS : string;

2 IEEE BSDL
-- Give boundary cell declarations
type BSCAN_INST is (EXTEST, SAMPLE, INTEST);

type CELL_TYPE is (INPUT, INTERNAL, CLOCK, OBSERVE_ONLY,
CONTROL, CONTROLR, OUTPUT2,
OUTPUT3, BIDIR_IN, BIDIR_OUT);
type CAP_DATA is (PI, PO, UPD, CAP, X, ZERO, ONE);
type CELL_DATA is record
CT : CELL_TYPE;
I : BSCAN_INST;
CD : CAP_DATA;
end record;
type CELL_INFO is array (positive range <>) of CELL_DATA;
-- Boundary Cell defered constants (see package body)
constant BC_0 : CELL_INFO;

-- Boundary Register declarations
attribute BOUNDARY_LENGTH : integer;

attribute BOUNDARY_REGISTER : string;
-- Miscellaneous
attribute PORT_GROUPING : string;

attribute RUNBIST_EXECUTION : string;
attribute INTEST_EXECUTION : string;
subtype BSDL_EXTENSION is string;
attribute COMPLIANCE_PATTERNS : string;
attribute DESIGN_WARNING : string;
attribute COMPONENT_CONFORMANCE : string;
end STD_1149_1_2001; -- End of 1149.1-2001 Package
package body STD_1149_1_2001 is -- Standard Boundary Cells
-- Generic cell capturing minimum allowed data
constant BC_0 : CELL_INFO :=

((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, X),
(INPUT, SAMPLE, PI), (OUTPUT2, SAMPLE, PI),

IEEE BSDL 2
(INPUT, INTEST, X), (OUTPUT2, INTEST, PI),

(OUTPUT3, EXTEST, X), (INTERNAL, EXTEST, X),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, X),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, X),
(CONTROL, EXTEST, X), (CONTROLR, EXTEST, X),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, X),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PI),
(BIDIR_IN, INTEST, X), (BIDIR_OUT, INTEST, PI),
(OBSERVE_ONLY, SAMPLE, PI), (OBSERVE_ONLY, EXTEST, PI) );
-- Description for f11-18, f11-30, f11-34c, f11-34d, f11-36c, f11-46d

((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, PI),
(INPUT, INTEST, PI), (OUTPUT2, INTEST, PI),
(OUTPUT3, EXTEST, PI), (INTERNAL, EXTEST, PI),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, PI),
(CONTROL, EXTEST, PI), (CONTROLR, EXTEST, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI) );
-- Description for f11-14, f11-31, f11-35c, f11-35d, f11-37c,

-- f11-38c, f11-39(output) and f11-41c

((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, UPD),
(INPUT, INTEST, UPD), -- Intest on output2 not supported
(OUTPUT3, EXTEST, UPD), (INTERNAL, EXTEST, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, UPD),
(CONTROL, EXTEST, UPD), (CONTROLR, EXTEST, UPD),
-- Description for f11-15

((INPUT, EXTEST, PI), (INTERNAL, EXTEST, PI),
(INPUT, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(INPUT, INTEST, PI), (INTERNAL, INTEST, PI) );
-- Description for f11-16, f11-17, f11-39(input)

((INPUT, EXTEST, PI), -- Intest on input/observe_only not supported
(INPUT, SAMPLE, PI),
(CLOCK, EXTEST, PI), (INTERNAL, EXTEST, PI),

2 IEEE BSDL
(CLOCK, SAMPLE, PI), (INTERNAL, SAMPLE, PI),

(CLOCK, INTEST, PI), (INTERNAL, INTEST, PI),
(OBSERVE_ONLY, SAMPLE, PI), (OBSERVE_ONLY, EXTEST, PI) );
-- Description for f11-46c, a combined Input/Control

((INPUT, EXTEST, PI), (CONTROL, EXTEST, PI),
(INPUT, SAMPLE, PI), (CONTROL, SAMPLE, PI),
(INPUT, INTEST, UPD), (CONTROL, INTEST, UPD) );
-- Description for f11-38d, a reversible cell

-- !! Not recommended; replaced by BC_7 below !!

((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, UPD),
(BIDIR_IN, INTEST, UPD), (BIDIR_OUT, INTEST, PI) );
-- Description for f11-37d, self monitor reversible

-- !! Recommended over cell BC_6 !!

((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, PO),
(BIDIR_IN, INTEST, UPD), (BIDIR_OUT, INTEST, PI) );
-- Description for 11-40, f11-41d

-- Intest on bidir not supported
((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, PO),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PO) );

-- Self-monitoring output that supports Intest
((OUTPUT2, EXTEST, PO), (OUTPUT3, EXTEST, PO),
(OUTPUT2, SAMPLE, PI), (OUTPUT3, SAMPLE, PI),
(OUTPUT2, INTEST, PI), (OUTPUT3, INTEST, PI) );

-- Self-monitoring output that does not support Intest
((OUTPUT2, EXTEST, PO), (OUTPUT3, EXTEST, PO),
(OUTPUT2, SAMPLE, PO), (OUTPUT3, SAMPLE, PO) );
end STD_1149_1_2001; -- End of 1149.1-2001 Package Body

IEEE BSDL 2
User-Supplied VHDL Packages

• User- Supplied VHDL Package Structure
• Cell Description Constants
• Example of a User- Supplied VHDL package
User-Supplied VHDL Package Structure

A user- supplied VHDL package is used to express the behavior of
user- designed Boundary Register cells. It has a VHDL package section and
a VHDL package body section. The VHDL package section is abbreviated
compared to the Standard VHDL Package, since the definitions of BSDL
are supplied in the Standard Package specified by the <standard use
statement>. The names of the cells that are defined in the VHDL package
body are given (called deferred constants).
When writing a User-Supplied VHDL Package, it is possible to create

NOTE
an error if a later construct such as a BSDL_EXTENSION is referenced
that is not defined in an earlier-defined Standard Package specified in
the <standard use statement>. To avoid such an error, a 2001
User-Supplied package should reference STD_ 1149_1_2001.
Example 2-44 User-Supplied VHDL Package Structure

<user package> ::= package <user package name> is
{ <extension declaration> }
{ <deferred constant> }
end <user package name> ;
<user package name> ::= <VHDL identifier>
<deferred constant> ::= constant <cell name> : CELL_INFO;
<user package body> ::= package body <user package name> is
{ <cell description constant> }
end <user package name> ;
• The <user package name> value has to be unique.

• All <cell name> values have to be unique.
• The <user package name> value in <user package> has to match the
<user package name> value in the <user package body>.

2 IEEE BSDL
Cell Description Constants

Cell description constants use the following form:
Example 2-45 Cell Description Syntax

<cell description constant> ::=
constant <cell name> : CELL_INFO := ( <capture descriptor list> ) ;
<capture descriptor list> ::= <capture descriptor> { , <capture descriptor> }
<capture descriptor> ::= ( <cell context>, <capture instruction>, <data source> )
<cell context> ::= INPUT | OUTPUT2 | OUTPUT3 | INTERNAL | CONTROL |
CONTROLR | CLOCK | BIDIR_IN | BIDIR_OUT | OBSERVE_ONLY
<capture instruction> ::= EXTEST | SAMPLE | INTEST
<data source> ::= PI | PO | CAP | UPD | ZERO | ONE | X
A cell description constant is a specified VHDL constant record made up

of a variable number of data triples containing VHDL enumerated types.
For example, a capture descriptor looks like the following:
Example 2-46 Cell Description Example #1

(INPUT, EXTEST, PI)
This can be read as “for this cell used as an INPUT cell, while EXTEST is
in effect, the capture flip- flop loads the Parallel Input (PI) data at the
CAPTURE- DR state.”

(BIDIR_IN, INTEST, UPD)
This can be read as “for this cell used as a Bidirectional cell acting as an
input (BIDIR_IN), while INTEST is in effect, the capture flip- flop loads the
value of the Update flip- flop (or latch) data (UPD) at the CAPTURE- DR
state.”

(OUTPUT2, SAMPLE, PI)
This can be read as “for this cell used as a (2- state) output cell, while
SAMPLE is in effect, the capture flip- flop loads the Parallel Input (PI)
data at the CAPTURE- DR state.”

IEEE BSDL 2

(OUTPUT3, EXTEST, ZERO)
This can be read as “for this cell used as a (3- state) output cell, while
EXTEST is in effect, the capture flip- flop loads a 0 (ZERO) data at the
CAPTURE- DR state.”
Cell Context Values

Table 2- 4 lists the <cell context> values.
Table 2-4 Cell Context Element Values and Meanings
Cell Context Value Meaning

INPUT Control-and-Observe input cell
CLOCK Observe-only cell for clock pins (supports INTEST instruction)
OUTPUT2 Two-state output cell
OUTPUT3 Three-state output cell
CONTROL Output enable or direction control cell
CONTROLR CONTROL with preset/clear at TEST-LOGIC-RESET
BIDIR_IN Single-cell bidirectional pin acting as input
BIDIR_OUT Single-cell bidirectional pin acting as output
INTERNAL Control-and-Observe internal cell, not associated with an I/O pin
OBSERVE_ONLY Observe-only cell with no control capability, associated with an
I/O pin
With the exception of <cell context> values of BIDIR_IN and BIDIR_OUT,

all the <cell context> values in Table 2- 4 map onto the like- named
<function> values in Table 2- 3 and supporting text. The <cell context>
values of BIDIR_ IN and BIDIR_OUT both map onto the <function> value
BIDIR. The behavior of a BIDIR cell is dependent on whether it is
currently set to be driving data out (BIDIR_OUT) or receiving data in
(BIDIR_IN), as determined by the data value contained in the controlling
cell identified by the <ccell> value.

2 IEEE BSDL
Data Source Values

Table 2- 5 gives the values for <data source>. Figure 2- 5 gives a general
model of the data source possibilities.
Table 2-5 Data Source Element Values and Meaning
Data Source Value Meaning

PI Parallel input
PO Parallel output (the output pad if a driver is present)
CAP Capture flip-flop data
UPD Update flip-flop (or latch) data
ZERO Constant ’0’
ONE Constant ’1’
X Unknown data
KEEPER Output that weakly drives the most recently driven data state
when disabled.
It is important to know the context of a cell to know how to interpret the

data source. This context determines how the software interprets PI and
PO.
• If the cell is used as an input (or is a bidirectional acting as an input),
then PI must be interpreted as a system pin whose data is being
captured.
• If the cell is used as an output (or is a bidirectional acting as an
output), the PI must be interpreted as the output from the system logic;
during EXTEST, the cell would capture X unless a full simulation of the
system logic were used to predict the system logic output.
• If the cell is used as an output, the PO must be the system pin; during
EXTEST, the cell would capture board levels outside the component;
when the cell is used as an input, then PO would capture X.

IEEE BSDL 2
Figure 2-5 A General Model of a Boundary Register Cell Showing CAP Inputs
To next
cell Mode
PI
PO
0
0 1
1 2
X 3
4
5
6 CAP UPD
ClockDR UpdateDR
From TAP Controller
Semantic Checks
In the following tables, an L indicates legality. An M indicates legality in
the case of merged cells only. An A indicates legality when the cell is an
additional cell not mandated by IEEE. A <capture descriptor> is a (<cell
context> <capture instruction> <data source>) element. An example of an
illegal <capture descriptor> is (Input, Extest, UPD).
Table 2-6 Semantic Checks
<capture instruction> PI PO UPD CAP X ZERO ONE

<cell context> of INPUT, CLOCK, and BIDIR_IN
EXTEST L
SAMPLE L
INTEST L L L L L L L
<cell context> of OUTPUT2, OUTPUT3, and BIDIR_OUT
EXTEST L L L L L L L
SAMPLE L
INTEST L

2 IEEE BSDL
Table 2-6 Semantic Checks (continued)
<capture instruction> PI PO UPD CAP X ZERO ONE

<cell context> of CONTROL, and CONTROLR
SAMPLE L
INTEST L M
<cell context> of INTERNAL (see NOTE below)
SAMPLE L L L L L L L
INTEST L L L L L L L
<cell context> of OBSERVE_ONLY
EXTEST L
SAMPLE L
INTEST A
For a <cell context> of INTERNAL, a <capture descriptor> value of PI

NOTE
is essentially identical to X since internal cells do not capture anything
other than constant 0’s (ZERO), 1’s (ONE) or the values previously
shifted in (CAP, UPD, or PO).
No combination of <cell context> value and <capture instruction> value

appears more than once in a single <capture descriptor list>.
The <cell name> value of a <cell description constant> in a <user package
body> has to match the <cell name> value of a <deferred constant> in the
<user package>, where the <user package body> and <user package>
specify the same <user package name>.
In the 1990 version of BSDL, the RUNBIST instruction was included as

NOTE
one of the <capture instruction> elements, but does not appear in the
1994 version. This reflects the facts that RUNBIST may or may not
reference the Boundary Register, and that the RUNBIST_EXECUTION
attribute has been added to the 1994 version to describe RUNBIST
capture behavior.

IEEE BSDL 2
Example of a User-Supplied VHDL package

The following is an example of a user- supplied VHDL package that
describes two new cells. These cells are able to capture constants (0 and
1) during certain situations. For example, used as outputs, during EXTEST,
they capture constant data rather than the system logic values ( usually
interpreted as X). By using these cells in the output cell positions of a
Boundary Register, it is possible to implement an informal ID code. They
will capture a pattern of 1 and 0 bits.
Example 2-50 User-Supplied VHDL Package

-- User defined package describing two new cells
package USER_PACKAGE is
use STD_1149_1_2001.all; -- Get definition of "Cell_info""
-- Boundary Cell deferred constants (defined in package body)
constant USER_0 : CELL_INFO;

constant USER_1 : CELL_INFO;
end USER_PACKAGE; -- End of User Package
package body USER_PACKAGE is -- User Boundary Cells
use STD_1149_1_2001.all;
constant USER_0 : CELL_INFO :=

((OUTPUT2, EXTEST, ZERO),
(OUTPUT2, SAMPLE, PI),
(OUTPUT3, EXTEST, ZERO), (INTERNAL, EXTEST, ZERO).
(CONTROL, EXTEST, ZERO), (CONTROLR, EXTEST, ONE),
constant USER_1 : CELL_INFO :=

((OUTPUT2, EXTEST, ONE),
(OUTPUT2, SAMPLE, PI),
(OUTPUT3, EXTEST, ONE), (INTERNAL, EXTEST, ONE),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, PI),
(CONTROL, EXTEST, ONE), (CONTROLR, EXTEST, ONE),
end USER_PACKAGE; -- End of User Package Body

2 IEEE BSDL
Example Applications of BSDL

Boundary- Scan Register Description
The following examples illustrate the description of a number of special
case boundary- scan register structures.
• Multiple Cells Per Pin
• Internal Cells
• Merged Cells
Multiple Cells Per Pin

Component pins can be serviced by more than one cell. Each cell can
perform a different function. Note that this function is with respect to the
boundary cell and not the component pin. For example, on a bidirectional
pin, one cell can serve as an input receiver while the other serves as an
output driver. Additional OBSERVE_ONLY cells may be connected to any
I/O pin.
The component shown in Figure 2- 6 is used to illustrate a boundary- scan
register with several OBSERVE_ONLY cells.
• Cell 2 is an additional OBSERVE_ONLY cell associated with
bidirectional pin 9 of the component.
• Cell 7 is an additional OBSERVE_ONLY cell associated with output pin
8 of the component. Cells 9, 8, and 7 may be a programmable two cell
bidirectional implementation that was reprogrammed to a two- state
output.
• Cell 15 is an additional OBSERVE_ONLY cell associated with input pin
6 of the component. Cells 13 and 14 are also associated with pin 6 but
are described as INPUT cells and are connected to the system logic.
• Cell 17 is an additional OBSERVE_ONLY cell associated with input pin
5 of the component. Cell 16 is the normal INPUT cell for pin 5.
• If the component in Figure 2- 6 supports INTEST then cell 18 must be
of type CLOCK. If the component does not support INTEST cell 18
could be either an INPUT cell or an OBSERVE_ONLY cell.

IEEE BSDL 2
Internal Cells
Internal cells can be used to capture "constants" or system- logic- dependent
values (0s and 1s) within a design. One proposed use of this ability is
capturing of a hard- coded value (perhaps in the first few bits of the
boundary- scan register) as an informal identification code. Another
application is to monitor power connections to ensure that they are
receiving the correct input supply and to capture a data bit based on the
measured results. If the power connections are good, the data loaded will
be 1, for example, while a faulty power input would cause a 0 to be
captured. Internal cells, either with control- and- observe capability or
observe- only capability, may sit at the boundary between digital and
analog sections of the core circuitry. Finally, there may be extra, unused,
cells in a programmable component.
IEEE does not allow system logic to surround internal cells.

NOTE
The component shown in Figure 2- 6 is used to illustrate a boundary- scan

register with several INTERNAL cells.
• Cells 0 and 1 are INTERNAL cells between the digital system logic and
the analog system functions. Note that cells 0 and 1 are not associated
with pin 10.
• Cells 6, 9, and 12 are cells that are observing signals from the system
logic and are not associated with an I/O pin and are described as
INTERNAL cells.
• Cell 19 is an extra cell in the boundary- scan register. It is not
observing the system logic or an I/O pin and is described as an
INTERNAL cell.

2 IEEE BSDL
Figure 2-6 A Component Illustrating Observe_Only and Internal Cells (Copyright © 2001
IEEE All rights reserved)
INTERNAL
12
11
CONTROL
13
INPUT
OUTPUT3 10 7
14 OUTPUT_1
6 INPUT
INPUT_1
9
INTERNAL
15
OBSERVE_ONLY
8
OUTPUT2 8
16 OUTPUT_2
5 INPUT
INPUT_2
7
D OBSERVE_ONLY
17
OBSERVE_ONLY I
G 6
INTERNAL
I
4
T
INPUT_3 CONTROL 5
A
18 CLOCK,
INPUT, or L
OBSERVE_ONLY
4 9
OUTPUT3
BIDIR_1
19 3
INTERNAL INPUT
2
OBSERVE_ONLY
1
INTERNAL A
N 10
A
ANALOG
INTERNAL
0 L
O
G
3
TDI
2 11
TMS TAP Controller
TCK 1 TDO
The definition of the boundary- scan register for Figure 2- 6 is given in

Example 2- 51.

IEEE BSDL 2
Example 2-51 Definition of Boundary-Scan Register Illustrating Internal Cells

attribute BOUNDARY_LENGTH of Figure_6: entity is 20;
attribute BOUNDARY_REGISTER of Figure_6: entity is
--
--
" 0 ( BC_1, * internal, 0), "&
" 1 ( BC_1, *, internal, 1), "&
" 2 ( BC_0, BIDIR_1 observe_only, X) "&
" 3 ( BC_1. BIDIR_1 input, X), "&
" 4 ( BC)1, BIDIR_1, output3, 0), 5, 0, Z), "&
" 5 ( BC_1, *, control, 0), "&
" 6 ( BC_0, *, internal, X), "&
" 7 ( BC_0, OUTPUT_2, observe_only, X), "&
" 8 ( BC_1, OUTPUT_2, output2, 1), "&
" 9 ( BC_0, *, internal, X), "&
" 10 ( BC_1, OUTPUT_1, output3, 0, 11, 0, Z), "&
" 11 ( BC_1, *, control, 0), "&
" 12 ( BC_0, *, internal, X), "&
" 13 ( BC_1, INPUT_1, input, X), "&
" 14 ( BC_1, INPUT_1, input, X), "&
" 15 ( BC_0, INPUT-1, observe_only, X), "&
" 16 ( BC_1, INPUT_2, input, X), "&
" 17 ( BC_0, INPUT_2, observe_only, X), "&
" 18 ( BC_0, INPUT_3, observe_only, X), "&
" 19 ( bc_0, *, internal, X) ";
Merged Cells
The component shown in Figure 2- 7 on page 2- 66 is used to illustrate a
boundary- scan register description and which special cases are handled.
These special cases arise because IEEE allows boundary- scan cells to be
merged when the system logic between them is null. Cells may be merged
if the "logic" between them is simply a data path, such as a wire or buffer.
When merging is done, the resulting cell must obey a combination of the
rules of the merged cells.

2 IEEE BSDL
Figure 2-7 Component Illustrating Several Merged Cells
6
BIDIR2 BIDIR3
EN3
4
7
EN4
3 EN2
SYSTEM LOGIC
IN2
8 2 BIDIR1
1
OUT2
0 EN1
9
IN1 OUT1
TDI TDO
TCK TAP Controller TMS
The definition of the boundary- scan register for Figure 2- 7 is given in

Example 2- 52.

IEEE BSDL 2
Example 2-52 Definition of Boundary-Scan Register Illustrating Merged Cells

attribute BOUNDARY_LENGTH of Figure_7: entity is 10;
attribute BOUNDARY_REGISTER of Figure_7: entity is
--
__ num cell port function safe [ccell disval rslt]
--
" 0 ( BC_1, *, control, 0), "&
" 1 ( BC_1, out2, output2, 1, 1, 1, Weak1), "&
" 2 ( BC_7, BIDIR1, bidir, X, 3, 0, Z), "&
" 3 ( BC_2, *, control, 0), "&
" 4 ( BC_1. *, control, 0), "&
" 5 ( BC_1, BIDIR3, input, X), "&
" 5 ( BC_1, BIDIR2, ouptut3, X, 7, 1, Z), "&
" 6 ( BC_1, BIDIR2, input, X), "&
" 6 ( BC_1, BIDIR3, output3, X, 4, 0, Z), "&
" 7 ( BC_1, *, control, 1), *&
" 8 ( BC_1, IN2, input, X), "&
" 9 ( BC_1, IN1, input, X), "&
" 9 ( BC_1, OUT1, output3, X, 0, 0, Z) ";
• Cells 0, 4, and 7 are control cells located between the system logic and
the enable for signals OUT1, BIDIR2, and BIDIR3. Notice that values are
assigned to the "safe" subfields for these cells to cause the associated
drivers to disable.
• Cell 3 is the control for the reversible cell used on the bidirectional
signal BIDIR1. Notice its "safe" subfield is given the value that causes
BIDIR1 to be an input.
• Cell 1 is a 2- state output data cell. Note that it has the three extra
fields indicating that it controls its own open- collector, asymmetrical
driver. By placing a 1 in cell 1, the driver at OUT2 can be set to the
inactive drive state in which it will output the WEAK1 state.
• Cell 2 is a reversible cell serving either as an input (if the control cell
has turned off the output driver, meaning that cell 3 produces a 0) or
as the data source for the driver (if the output is enabled).
• Note that the structures for BIDIR2 AND BIDIR3 allow observation of
the driver, thus allowing a simple consistency check.
• Cell 5 (and similarly cells 6 and 9) has merged behavior: it serves as
the input receiver for BIDIR3, and as the data source for BIDIR2. As a
result, the cell has two lines of description in the boundary- scan
register definition. The first gives its behavior as an input cell while the
second describes its characteristics as an output cell. Note that cell
BC_1 used in this capacity must support both INPUT and OUTPUT3
functions. This is reflected in the definition of BC_1 where both
functions exist for all instructions.
The example in Figure 2- 7 is extreme and includes several unusual cases.
Most component implementations are quite simple and routine.

2 IEEE BSDL
Sample BSDL Description

Figure 2-9 Sample Device: TI Octal D-Type Flip-Flop
74BCT8374 DW PACKAGE
D8 15 8 D Q 0 10 Q8
D7 16 9 D Q 1 9 Q7
D6 17 10 D Q 2 8 Q6
D5 19 11 D Q 3 7 Q5
D4 20 12 D Q 4 5 Q4
D3 21 13 D Q 5 4
Q3
D2 22 14 D Q 6 3 Q2
D1 23 15 D Q 7 2
Q1
OC- 24 16
BCR
1 17 Register
CLK
Bypass
Register
Instruction
Register 11 TDO
TDI 14
TCK 13 TAP Controller

12 TMS

IEEE BSDL 2
Example 2-53 Sample BSDL Description

entity ttl74bct8374 is
generic (PHYSICAL_PIN_MAP : string := "DW");
port (CLK:in bit; Q:out bit_vector(1 to 8); D:in bit_vector(1 to 8);

GND, VCC:linkage bit; OC_NEG:in bit; TDO:out bit; TMS, TDI, TCK:in bit);
use STD_1149_1_2001.all; -- Get Std 1149.1-2001 attributes and definitions
attribute COMPONENT_CONFORMANCE of ttl74bct8374 : entity is "STD_1149_1_1990";
attribute PIN_MAP of ttl74bct8374 : entity is PHYSICAL_PIN_MAP;
constant DW: PIN_MAP_STRING:="CLK:1, Q:(2,3,4,5,7,8,9,10), " &

"D:(23,22,21,20,19,17,16,15)," &
"GND:6, VCC:18, OC_NEG:24, TDO:11, TCK:13, TDI:14";
constant FK: PIN_MAP_STRING:"CKL:9, Q:(10,11,12,13,16,17,18,19)," &

"D:(6,5,4,3,2,27,26,25)," &
"GND:14, VCC:28, OC_NEG:7, TDO:20, TMS:21, TCK:23, TDI:24";

attribute TAP_SCAN_CLOCK of TCK : signal is (20.0e6, BOTH);
attribute INSTRUCTION_LENGTH of ttl74bct8374 : entity is 8;
attribute INSTRUCTION_OPCODE of ttl74bct8374 : entity is

"BYPASS (11111111,10001000, 00000101, 00000001)," &
"EXTEST (00000000, 10000000)," &
"SAMPLE (00000010, 10000010)." &
"PRELOAD (00000010, 10000010)." &
"INTEST (00000011, 10000011)," &
"HIGHZ (00000110, 10000110)," & -- New 1149.1a HIGHZ instruction
"CLAMP (00000111, 10000111)," & -- New 1149.1a CLAMP instruction
"RUNT (00001001, 10001001)," & -- Boundary run test
"READBN (00001010, 10001010)," & -- Boundary read normal
"READBT (00001011, 10001011)," & -- Boundary read test,
"CELLTST(00001100, 10001100)," & -- Boundary self test normal
"TOPHIP (00001101, 10001101)," & -- Boundary toggle out test
"SCANCN (00001110, 10001110)," & -- BCR Scan normal
"SCANCT (00001111, 10001111)"; -- BCR Scan test
attribute INSTRUCTION_CAPTURE of ttl74bct8374 : entity is "10000001";
attribute REGISTER_ACCESS of ttl74bct8374 : entity is

"BOUNDARY (READBN, READBT, CELLTST)," &
"BYPASS (TOPHIP, SETBYP, RUNT, TRIPBYP), " &
"BCR [2] (SCAMCM. SCAMCT)"; -- 2-bit Boundary Control Register

2 IEEE BSDL
attribute BOUNDARY_LENGTH of ttl74bct8374 : entity is 18;
attribute BOUNDARY_REGISTER of ttl74bct8374 : entity is

"17 (BC_1, CLK, input, X), " &
"16 (BC_1, OC_NEG, input, X), " &
-- merged input/control
"16 (BC_1, *, control, 1), " &
"15 (BC_1, D(1), input, X), " &
"14 (BC_1, D(2), input, X), " &
"13 (BC_1, D(3), input, X), " &
"12 (BC_1, D(4), input, X), " &
"11 (BC_1, D(5), input, X), " &
"10 (BC_1, D(6), input, X), " &
"9 (BC_1, D(7), input, X), " &
"8 (BC_1, D(8), input, X), " &
"7 (BC_1, Q(1), output3, X, 16, 1, Z), " &
"6 (BC_1, Q(2), output3, X, 16, 1, Z), " &
"5 (BC_1, Q(3), output3, X, 16, 1, Z), " &
"4 (BC_1, Q(4), output3, X, 16, 1, Z), " &
"3 (BC_1, Q(5), output3, X, 16, 1, Z), " &
"2 (BC_1, Q(6), output3, X, 16, 1, Z), " &
"1 (BC_1, Q(7), output3, X, 16, 1, Z), " &
"0 (BC_1, Q(8), output3, X, 16, 1, Z) ";
end ttl74bct8374;

IEEE BSDL 2
BSDL Quick Reference

This reference section describes the VHDL statements used in BSDL and
the syntax for applying these statements. It provides parameter
descriptions, and examples of BSDL statements.
• Notes on BSDL Syntax
• List Of BSDL Statements
• BSDL Statement Descriptions
VHDL is the IEEE Standard 1076-1987: VHSIC Hardware Description
NOTE
Language.
Notes on BSDL Syntax

Before starting with the descriptions, let's take a look at some definitions
peculiar to BSDL.
• A VHDL identifier is a series of letters (a- z, A- Z), numbers (0- 9), and
the underscore character (_) that can be used in any combination to
describe a device, instruction, pin, port, or any other component. The
only restriction is that the first character of a VHDL identifier must be
a letter.
• BSDL is governed by syntax that is a subset of VHDL. The syntax is not
case- sensitive. It is free- form, which means that it does not follow
columnar organization, and extra spaces - used to enhance readability -
do not change a statement's meaning. Statements can run on for several
lines and are explicitly terminated by a semicolon (;).
• A comment is simply text used to annotate a program. It has no effect
on the program and can appear in any listing of the program. A
comment begins with a double- dash (- - ) and can contain any printable
character. The comment can be on a line by itself, or it can follow a
statement, but it must be the last item on a line. A comment is
terminated by the end of a line.
• Some of the information is conveyed in VHDL strings: sequences of
characters between quotation marks. This information is associated with
a VHDL attribute and has a BSDL syntax requirement. The syntax is
not checked by VHDL itself, but by applications that use the
information.
These strings are potentially long, and the concatenation operator &
(ampersand) is used to break them into manageable pieces.
The following instruction could have been written as one long string,
but the ampersand allows you to break the string at logical intervals to
make it easier to understand.

2 IEEE BSDL
attribute INSTRUCTION_OPCODE of My_IC : entity is

"Extest (0000), " &
"Bypass (1111), " &
"Sample (1100, 1010), " &
"Preload (1010)" ;
• The syntax for each statement shows you what information is needed to
use a statement properly. They are broken down into levels and each
level explains the information needed to complete an element of the
syntax.
An element that contains a stack of information (such as
Example 2- 54) shows that information for that level can be written
using any one of the combinations shown.
Example 2-54 Stacked Statement Elements

<Cell Table> can be: <Cell Entry>
<Cell Entry> , <Cell Entry>
<Cell Entry> , <Cell Entry> , ... <Cell Entry>
In this example, the element <Cell Table> can be described using a single
<Cell Entry>, or a list of <Cell Entry>s with each entry separated by a
comma (,).

IEEE BSDL 2
List Of BSDL Statements

The BSDL statements are summarized in alphabetical order below. Click
on any statement to see a detailed description of the statement and its
parameters.
Table 2-7 List of BSDL Statements
Statement Description
attribute BOUNDARY_CELLS Identifies which cells are used in the Boundary Register.
attribute BOUNDARY_LENGTH Defines the number of cells in the Boundary Register.
attribute BOUNDARY_REGISTER Describes the Boundary Register itself.
attribute COMPLIANCE_PATTERNS Identifies "compliance enable" pins and their static logic states.
attribute COMPONENT_CONFORMANCE Identifies the edition of the IEEE Standard to which a physical
component’s testability circuitry conforms.
attribute INSTRUCTION_CAPTURE States what bit pattern is loaded into the Instruction Register at
CAPTURE_IR.
attribute INSTRUCTION_LENGTH Defines the length of the device's Instruction Register.
attribute INSTRUCTION_OPCODE Identifies the operation codes of the Instruction Register.
attribute INSTRUCTION_PRIVATE Identifies opcodes that are private and potentially unsafe.
attribute (optional registers) Identifies whether optional registers prescribed by the IEEE
Standard are present.
attribute PIN_MAP Declares the pin mapping function for a device.
attribute REGISTER_ACCESS Tells software that registers other than those prescribed by the
IEEE Standard are present.
attribute TAP_SCAN_CLOCK Describes the devices Test Clock (TCK) port.
attribute TAP_SCAN_IN Identifies the devices Test Data In (TDI) port.
attribute TAP_SCAN_MODE Identifies the devices Test Mode Select (TMS) port.
attribute TAP_SCAN_OUT Identifies the devices Test Data Out (TDO) port.
attribute TAP_SCAN_RESET Identifies the devices Test Reset (TRST) port.
BSDL extension Optional BSDL extensions provide a way to expand BSDL for
proprietary needs without losing compatibility with the
mainstream definition of BSDL. For information about using BSDL
extensions, see User Extensions to BSDL.
constant (entity) Describes the mapping between logical port names and physical
pins.

2 IEEE BSDL
Table 2-7 List of BSDL Statements
Statement Description
constant (package) Declares the name of a constant and references it within the
package body.
constant (package body) Describes the parameters of a Boundary-Cell design.
end Marks the end of an entity, package, or package body.
entity Marks the beginning of a block of statements that outline the
overall description of a device.
generic Selects among several packaging options for a device.
package Marks the beginning of a block of statements that describe the
IEEE Standard or a user-specified boundary-cell definition.
package body Marks the beginning of a block of statements that provide the
detailed descriptions of Boundary-Register cells.
port Assigns meaningful symbolic names to the device's system
terminal.
use Identifies a VHDL package needed to define the attributes for a
device.

IEEE BSDL 2
BSDL Statement Descriptions

This section describes each BSDL statement, its syntax and parameters,
and provides examples of how to use the statements.
attribute BOUNDARY_CELLS (BSDL)

One of three statements that describe the device's Boundary Register. The
BOUNDARY_CELLS attribute identifies which cells are used in the
Boundary Register. These cells can come from the IEEE Standard or they
can be user- defined cells that adhere to the standard's guidelines.
Syntax
attribute BOUNDARY_CELLS of <device id>: entity is "<Cell List>";
<device id> is a <VHDL identifier>
<Cell List> can be: <Cell Name>
<Cell Name> , <Cell Name>
<Cell Name> , <Cell Name>, . . . <Cell Name>
<Cell Name> is a VHDL IDENTIFIER
Parameters
<Cell List> Identifies the cell designs employed by the Boundary Register.
Most of the time these cells will be part of the intrinsic set of cells
described by IEEE Standard 1149.1. However, these cells may also
be user- designed cells that follow IEEE Standard rules.
<Cell Name> The cells for the IEEE Standard are labeled BC_1 through BC_6
and are used in a standard practice. User- designed cells can have
almost any label except those established as a BSDL standard
practice.
Examples
attribute BOUNDARY_CELLS of My_IC : entity is "BC_1, MyCell";
General Information
(none)

2 IEEE BSDL
attribute BOUNDARY_LENGTH (BSDL)

One of three statements that describe the device’s Boundary Register. The
BOUNDARY_LENGTH attribute defines the number of cells in the
Boundary Register. The length of the register must be at least one.
Syntax
attribute BOUNDARY_LENGTH of <device id>: entity is <integer>;
Parameters
(none)
Examples
attribute BOUNDARY_LENGTH of My_IC : entity is 3;
General Information
(none)

IEEE BSDL 2
attribute BOUNDARY_REGISTER (BSDL)

One of three statements that describe the device’s Boundary Register. This
attribute is a string containing a list of elements that describe the cells
used, their related ports, and their functions.
Syntax
attribute BOUNDARY_REGISTER of <device id>: entity is "<Cell Table>";
<Cell Table> can be: <Cell Entry>
<Cell Entry> , <Cell Entry>
<Cell Entry> , <Cell Entry> , . . . <Cell Entry>
<Cell Entry> can be: <Cell Number> ( <Cell Info> )
<Cell Number> is an <integer>
<Cell Info> can be: <Cell Spec>
<Cell Spec> , <Disable Spec>
<Cell Spec> can be: <Cell ID>,<Port ID>,<Function>,<Safe Value>
<Cell ID> is an <VHDL identifier>
<Port ID> can be: <Port Name>
*
<Port Name> is a <VHDL Identifier>
<Function> can be: Input
Output2
Output3
Control
Controlr
Internal
Clock
Bidir
<Safe Value> can be : 0
1
X
<Disable Spec> can be: <Disable Cell>,<Disable Val>,<Disable Result>
<Disable Cell> can be: <Cell Number>
<Disable Val> can be: 0
1
<Disable Result> can be: Z
Weak0
Weak1
Parameters
<Cell Table> This parameter is a string containing cell numbers and
specifications that define what the cell does.
<Cell Info> The Cell Info parameter contains the cell and port identifications,
the cell's function, and its safe value. It may also contain the
disable specification for the cell if it is a bidirectional cell or
busable output.

2 IEEE BSDL
<Port ID> The Port ID parameter can be either a symbolic name given to a
port in the logical port description, or an asterisk (*) if the cell
serves as an output control or is an internal cell.
<Function> The Function parameter identifies the cells primary function.
<Safe Value> This parameter identifies the value that a device designer prefers
to have loaded into the UPDATE flip- flop when the software
would otherwise choose a value randomly. An X in this position
signifies that the value does not matter.
<Disable Spec> The disable specification provides the number of the controlling
cell, the value that the controlling cell (ccell) must have to disable
the output driver, and the state (result) that the disabled driver
goes to, which can be a high- impedance state (Z), a weak 1, or a
weak 0.
Examples
attribute BOUNDARY_REGISTER of My_IC : entity is
" 0 (BC_1, IN, input, X), " &
" 1 (BC_1, *, control, 0), " &
"
2 (MyCell, OUT, output3, X, 1, 0, Z)";
General Information
(none)

IEEE BSDL 2
attribute COMPLIANCE_PATTERNS (BSDL)

This optional attribute is used when a device has "compliance enable" pins
that must be conditioned to static logic states at any time the 1149.1
features of a device are to be used. This attribute identies those pins and
their logic states.
Syntax
attribute COMPLIANCE_PATTERNS of <device id> : entity is <compliance pattern
string> ;
<compliance pattern string>::= " ( <compliance port list> ) ( <pattern list> )"
<compliance port list>::= <port ID> { , <port ID>}
<pattern list>::= <pattern> { , <pattern> }
Parameters
<port ID> A pin name of the device. Note this pin is NOT provisioned with
boundary register cells. It is an error if such a pin is identified
here.
<pattern> A binary pattern of digits "0", "1" or "X" characters containing no
embedded spaces. These are associated right- to- left, one per <port
ID> in the compliance port list. There must be exactly as many
binary pattern digits as there are <port ID> elements. A <pattern>
may contain X bits to reduce the size of a <pattern list>. As an
example, the <pattern list> 1111X, 0XXX0 specifies 10 unique bit
patterns that enable compliance.
Examples
attribute COMPLIANCE_PATTERNS of My_IC: entity is
"(Pin_A, Pin_B, Pin_P, Pin_C1, Pin_C2) (00011)";
General Information
Tests using test facilities defined by 1149.1 must assure that any
compliance- enable conditions are first set up before exercising the TAP of
the affected IC. A compliance- enable pattern must be held constant for the
duration of all boundary- scan testing.

2 IEEE BSDL
attribute COMPONENT_CONFORMANCE (BSDL)

The conformance statement identifies the edition of this standard to which
the testability circuitry of a physical component conforms.
It is possible for a component designed in 1990 to be described by the
version of BSDL defined in 2001, but this does not imply that the
component conforms to the rules of IEEE Std 1149.1- 2001. The
component_conformance statement allows tools to account for changes in
the rules that may occur in past and future editions of this standard.
Syntax
attribute COMPONENT_CONFORMANCE of <device id>: entity is <conformance string> ;
<conformance string>::= " <conformance identification> "
<conformance identification>::= STD_1149_1_1990 | STD_1149_1_1993 |
STD_1149_1_2001
Parameters
STD_1149_1_1990 refers to IEEE Std 1149.1- 1990.
STD_1149_1_1993 refers to to IEEE Std 1149.1a- 1993.
STD_1149_1_2001 refers to IEEE Std 1149.1- 2001.
Subsequent editions of this annex may add new values to the conformance
identification syntax.
Examples
attribute COMPONENT_CONFORMANCE of My_Old_IC:entity is
"STD_1149_1_1990"; -- old 1990 component
General Information
(none)

IEEE BSDL 2
attribute INSTRUCTION_CAPTURE (BSDL)

One of four statements that describe the device- dependent characteristics
of the TAP Controller Instruction Register. The INSTRUCTION_CAPTURE
attribute states what bit pattern is loaded into the shift register portion of
the Instruction Register when the TAP Controller passes through the
CAPTURE- IR state.
Syntax
attribute INSTRUCTION_CAPTURE of <device id>: entity is "<Pattern>";
<Pattern> is a <binary string>
Parameters
<Pattern> The pattern is a binary string that identifies the capture function.
The two right- most bits of this pattern must be 01 as prescribed
by the IEEE Standard. Xs are allowed if unknown data is captured
in higher order bits.
Examples
attribute INSTRUCTION_CAPTURE of My_IC : entity is "0101";
General Information
(none)

2 IEEE BSDL
attribute INSTRUCTION_LENGTH (BSDL)

One of six statements that describe the device- dependent characteristics of
the TAP Controller. The INSTRUCTION_LENGTH attribute identifies the
length of the device's Instruction Register; it must be at least two bits
long.
Syntax
attribute INSTRUCTION_LENGTH of <device id>: entity is <integer>;
Parameters
(none)
Examples
attribute INSTRUCTION_LENGTH of My_IC : entity is 4;
General Information
(none)

IEEE BSDL 2
attribute INSTRUCTION_OPCODE (BSDL)

the TAP Controller. The INSTRUCTION_OPCODE attribute identifies the
operation codes of the device's Instruction Register.
Syntax
attribute INSTRUCTION_OPCODE of <device id>: entity is "<Opcode Table>";
<Opcode Table> can be: <Opcode Desc>
<Opcode Desc>, <Opcode Desc>
<Opcode Desc>, <Opcode Desc>, . . .<Opcode Desc>
<Opcode Desc> can be: <Opcode Name> ( <Pattern List> )
<Pattern List> can be: <Pattern>
<Pattern> , <Pattern>
<Pattern>, <Pattern>, . . . <Pattern>
<Pattern> is a <binary string>
<Opcode Name> can be : Extest
Sample
Preload
Intest
Runbist
Bypass
IDcode
Usercode
VHDL identifier
Parameters
<Pattern> The pattern is a binary string that identifies the opcode of a
particular function. This string can include 1s 0s or Xs. You
should be careful when you use an X to ensure that the resulting
opcode is not ambiguous such that it might decode to a function
other than what is intended. The BSDL compiler would reject the
code and issue an error message if an ambiguity occurred. The
binary string's length must match the length of the
INSTRUCTION_LENGTH attribute. All related opcodes must also be
the same length. Any unspecified bit pattern will default to the
BYPASS function.
<Opcode Name> The opcode name identifies the function, which is a test name or
user- specified instruction. The bit patterns for the opcode names
are assigned by the device designer except for EXTEST and
BYPASS, which have patterns mandated by IEEE Standard 1149.1.
These two opcode names may have additional bit patterns assigned
by the device designer.
Examples
attribute INSTRUCTION_OPCODE of My_IC : entity is
"Extest (0000), " &
"Bypass (1111), " &

2 IEEE BSDL
"Sample (1100, 1010), " &

"Preload (1010)," &
"Hi_Z (0101), " &
"Secret (0001) ";
attribute INSTRUCTION_OPCODE of My_IC2 : entity is
"Extest (00000000), " &
"Bypass (11111111), (XX111111), " & ! example of using an "X" that results
"Sample (11001100), (00111111), " & ! in an ambiguous decode with sample
General Information
(none)

IEEE BSDL 2
attribute INSTRUCTION_PRIVATE (BSDL)

the TAP Controller. The INSTRUCTION_PRIVATE attribute identifies
opcodes that are private and potentially unsafe for access.
Syntax
attribute INSTRUCTION_PRIVATE of <device id>: entity is "<Opcode List>";
<Opcode List> can be: <Opcode Name>
<Opcode Name>, <Opcode Name>
<Opcode Name>, <Opcode Name>, . . .<Opcode Name>
<Opcode Name> is a VHDL IDENTIFIER
Parameters
<Opcode Name> The opcode (operation code) parameter for this statement is a
VHDL identifier provided by the device designer. It gives the
code(s) that are potentially unsafe for access.
Examples
attribute INSTRUCTION_PRIVATE of My_IC : entity is "Secret";
General Information
(none)

2 IEEE BSDL
attribute (optional registers) (BSDL)

Tells application software that optional registers prescribed by the IEEE
standard are present in the device. The IDCODE and USERCODE registers
identify the device, its part number, and manufacturer.
Syntax
attribute <attribute name> of <device id>: entity is "<Pattern>";
<attribute name> can be: IDCODE_REGISTER
USERCODE_REGISTER
<Pattern> is a <special binary string>
Parameters
<special binary string>The special binary string identifies the optional register. An X
is allowed in this string to specify a “don't care” state for that
position.
Examples
attribute IDCODE_REGISTER of My_IC : entity is
"0011" & -- 4 bit version
"1111000011110000" & -- 16 bit part number
"00000000111" & -- 11 bit manufacturer
"1"; -- mandatory LSB
attribute USERCODE_REGISTER of My_IC : entity is
"10XX" &
"0011110011110000" &
"00000000111" &
"1";
General Information
(none)

IEEE BSDL 2
attribute PIN_MAP (BSDL)

A standard practice of BSDL. It declares the pin mapping function for a
device.
Syntax
attribute PIN_MAP of <device id>: entity is PHYSICAL_PIN_MAP;
Parameters
(none)
Examples
attribute PIN_MAP of ttl74bct8374 : entity is PHYSICAL_PIN_MAP;
General Information
(none)

2 IEEE BSDL
attribute REGISTER_ACCESS (BSDL)

Tells the software that registers other than those prescribed by the IEEE
standard exist, what the length of the registers are, and what the
associated instructions are.
Syntax
attribute REGISTER_ACCESS of <device id>: entity is "<Register String>";
<Register String> can be: <Register Assoc>
<Register Assoc> , <Register Assoc>
<Register Assoc>, <Register Assoc>, . . .<Register Assoc>
<Register Assoc> can be: <Register> ( <OpcodeList> )
<Register> can be: <VHDL Identifier> [register length]
BOUNDARY
BYPASS
IDCODE
<Opcode List> can be: Opcode Name>
<Opcode Name>, <Opcode Name>
<Opcode Name>,<Opcode Name>, . . .<Opcode Name>
<Opcode Name> can be: Runbist
VHDL IDENTIFIER
Parameters
<Register Assoc> This parameter identifies the registers associated with the
specified opcode(s).
<Opcode Name> The opcode name identifies the function, which is a user- specified
instruction.
Examples
attribute REGISTER_ACCESS of My_IC : entity is
"Boundary (Secret, User1), " &
"Bypass (Hi_Z, User2), " &
"MyReg [4] (LoadSeed, ReadTest)";
General Information
(none)

IEEE BSDL 2
attribute TAP_SCAN_CLOCK (BSDL)

One of five statements that describe the device's scan ports. The
TAP_SCAN_CLOCK attribute describes the devices Test Clock (TCK) port.
Syntax
attribute TAP_SCAN_CLOCK of <port name>: signal is ( <clock record> );
<clock record> is <real number>, <state value>
<state value> can be: low
both
Parameters
<clock record> The clock record parameter identifies the maximum operating
frequency for TCK and the state at which the clock can be
stopped.
<real number> The <real number> parameter specifies the maximum clock
frequency in hertz at which the test clock can run. VHDL requires
that this number include a decimal point.
<state> The <state> parameter tells you what state you can stop the test
clock in without the TAP Controller losing its state. There are only
two possible values for this parameter:
• low tells you that TCK can be stopped only in the low
state.
• both tells you that TCK can be stopped in either state.
Examples
attribute TAP_SCAN_CLOCK of TCK : signal is (17.5e6, BOTH);
General Information
(none)

2 IEEE BSDL
attribute TAP_SCAN_IN (BSDL)

TAP_SCAN_IN attribute identifies the devices Test Data In (TDI) port.
Syntax
attribute TAP_SCAN_IN of <port name>: signal is <boolean>;
<port name> is <VHDL Identifier>
<boolean> is true
Parameters
<boolean> The value of the boolean for this attribute has no particular
function; it simply satisfies the VHDL syntactical needs of the
statement.
Examples
General Information
(none)

IEEE BSDL 2
attribute TAP_SCAN_MODE (BSDL)

TAP_SCAN_MODE attribute identifies the devices Test Mode Select (TMS)
port.
Syntax
attribute TAP_SCAN_MODE of <port name>: signal is <boolean>;
<boolean> is true
Parameters
statement.
Examples
General Information
(none)

2 IEEE BSDL
attribute TAP_SCAN_OUT (BSDL)

TAP_SCAN_OUT attribute identifies the devices Test Data Out (TDO) port.
Syntax
attribute TAP_SCAN_OUT of <port name>: signal is <boolean>;
<boolean> is true
Parameters
statement.
Examples
General Information
(none)

IEEE BSDL 2
attribute TAP_SCAN_RESET (BSDL)

TAP_SCAN_RESET attribute identifies the devices Test Reset (TRST) port.
This attribute is optional.
Syntax
attribute TAP_SCAN_RESET of <port name>: signal is <boolean>;
<boolean> is true
Parameters
statement.
Examples
attribute TAP_SCAN_RESET of TRST : signal is true;
General Information
(none)

2 IEEE BSDL
constant (entity) (BSDL)

This statement can be used in one of three ways, depending on whether
the statement is located in the entity, the package, or the package body.
In an entity, the constant statement describes the mapping between the
logical port names and the physical pins of a device. The type of this
constant must be PIN_MAP_STRING. This is a standard practice of BSDL.
Syntax
constant <VHDL identifier>: PIN_MAP_STRING := "<Map String>";
<Map String> can be: <Port Name> : <Pin List>, . . .<Port Name>: <Pin List>
<Port Name> can be: <VHDL identifier>
<Pin List> can be: <Pin ID>
( <Pin ID, . . . <Pin ID> )
<Pin ID> can be: <integer>
<VHDL identifier>
Parameters
<Map String> The Map String parameter identifies the mapping between port
names and physical pin numbers.
<Port Name> The Port Name parameter identifies the device pin that the
constant defines. The name of the port must match that given in
the logical port description.
<Pin ID> This parameter identifies the physical pin of a device to which the
port name is mapped. This parameter is typically a pin number,
but can consist of an alphanumeric identifier (A7) for devices such
as pin grid arrays.
Examples
constant dw_package : PIN_MAP_STRING := "CLK:1, Q:(2,3,4,5,7,8,9,10)";
constant fk_package : PIN_MAP_STRING := "CLK:9, Q:(10,11,12,13,14,15,16,17)";
constant PGA_package: PIN_MAP_STRING := "CLK:7, Q:(A4, A5, A6, A7)"
General Information
(none)

IEEE BSDL 2
constant (package) (BSDL)

In a package, the constant statement declares the name of a constant and
references that constant within the package body.
Syntax
constant <VHDL identifier>: CELL_INFO ;
Parameters
(none)
Examples
constant BC_1 : CELL_INFO ;
General Information
(none)

2 IEEE BSDL
constant (package body) (BSDL)

In the package body, the constant statement describes the parameters of a
boundary- cell design for a device.
Syntax
constant <VHDL id>: CELL_INFO := ((<function code>), . . .(<function code>) )
<function code> is <function>, <instruction>, <CAP data source>
<function> can be: Input
Output2
Output3
Control
Controlr
Internal
Clock
Bidir_in
Bidir_out
<instruction> can be: Extest
Sample
Intest
Runbist
<CAP data source> can be: PI
PO
UPD
CAP
X
ZERO
ONE
Parameters
<function code> This parameter provides the description of a part of the behavior
of a Boundary Register cell. It tells you for a given cell function,
while a certain instruction is in effect, what data is loaded into
the CAPTURE flip- flop when passing through the CAPTURE- DR
state.
<function> The function parameter describes the cells role in the Boundary
Register.
<instruction> The instruction parameter identifies the instruction in effect.
<CAP data source> This parameter identifies the data that will be loaded into the
CAPTURE flip- flop. The value loaded into the CAP flip- flop can
come from:
PI the cell’s parallel input
PO a feedback from the cell's parallel output

IEEE BSDL 2
UPD a feedback from the cell's update flip- flip, which recalls
previously loaded CAP data
CAP a feedback from the cell's capture flip- flop, which retains
data loaded in the CAP
X an input loading an X (don’t care)
ZERO an input loading a constant 0
ONE an input loading a constant 1
Examples
constant BC_3: CELL_INFO :=
( (input, extest, pi), (internal, extest, pi),
(input, sample, pi), (internal, sample, pi) )
General Information
(none)

2 IEEE BSDL
end (BSDL)
Marks the end of an entity, package, or package body. The identifier of the
end statement must match that of the statement that it terminates.
Syntax
end <VHDL identifier>;
Parameters
(none)
Examples
end My_New_Cells; -- terminates the package or package body called My_New_Cells
end ttl74bct8374; -- terminates the entity for a specified device
General Information
(none)

IEEE BSDL 2
entity (BSDL)
Marks the beginning of a block of statements that provide the overall
description a device within VHDL. Within the entity, the boundary- scan
parameters of a device are described. The entity relies upon the package
to provide device attribute information. The definitions related to IEEE
Standard 1149.1 come from a pre- written, standard VHDL package (and
related package body).
Syntax
entity <device id> is
Parameters
(none)
Examples
entity ttl74bct8374 is -- identifies a device as the entity
General Information
The entity statement is an element of VHDL.

2 IEEE BSDL
generic (BSDL)
This statement is a parameter within the entity description. It selects
among several packaging options that a device may have. Each option may
have a different mapping between the package pins and the device's
bonding pads. The generic parameter must have the name
PHYSICAL_PIN_MAP so software can identify it.
Syntax
generic ( PHYSICAL_PIN_MAP : string := "<string expression>" );
Parameters
<string expression> This parameter initializes the string to an arbitrary value when
“undefined” and will not pass the parameter; the package will have
to be selected using an external mechanism. If the string is
initialized to a specified value, the parameter will pass its
information.
Examples
generic ( PHYSICAL_PIN_MAP : string := "UNDEFINED") ! the package option will
! have to be specified by an external mechanism
generic (PHYSICAL_PIN_MAP : string := "FK_Package")
! selects the FK package option
General Information
The generic parameter is a VHDL construct used to pass data into a VHDL
model. The external mechanism used by Boundary- Scan Software is the - p
option when running SPD. For more information, refer to Scan Port
Driver.

IEEE BSDL 2
package (BSDL)
Marks the beginning of a block of statements that describe IEEE Standard
1149.1 or user- specific boundary cell definitions. The package typically
contains general statements that reference items with the related package
body.
Packages are referenced by entities with the use statement. The entity
uses the package to describe the rules under which the device must
operate.
Syntax
package <VHDL identifier> is
Parameters
(none)
Examples
package STD_1149_1_2001 is -- declares the IEEE Standard as the package
package My_New_Cells is -- declares the user-specified cells'
definitions as the package
General Information
(none)

2 IEEE BSDL
package body (BSDL)

Marks the beginning of a block of statements that provide the detailed
descriptions of a device's function and application. The package body is
referenced by declarations in the package. The identifier of the package
body must match that of the package.
Syntax
package body <VHDL identifier> is
Parameters
(none)
Examples
package body STD_1149_1_2001 is -- declares the IEEE Standard as the
package body
package body My_New_Cells is -- declares the user-defined cells' package
body
General Information
(none)

IEEE BSDL 2
port (BSDL)
Assigns meaningful symbolic names to the device's system terminals. These
names are used in subsequent descriptions of package pin mapping, scan
port identification, and the Boundary Register descriptions. The names
found in these subordinate statements must match those assigned by the
logical port statement.
Syntax
port ( <pin id>; <pin id>; . . . <pin id> );
<pin id> can be : <identifier list> : <mode> <pin type>
<identifier list> can be: <VHDL id>
<VHDL id> , <VHDL id>
<VHDL id>, <VHDL id>, . . . <VHDL id>
<mode> can be: in
out
inout
buffer
linkage
<pin type> can be: bit
bit_vector ( <range> )
<range> can be: <numeric constant> to <numeric constant>
<numeric constant> downto <numeric constant>
Parameters
<pin id> The pin id assigns a logical port name to a particular signal or set
of signals. The pin id includes an identifier that is referenced by
subsequent program descriptions, a mode assignment that
identifies how the pin is used, and a type assignment that shows
if the pin is used for a single signal or a group of signals.
<mode> The mode identifies how the system uses a device's pin. The
modes include:
• in – Identifies the pin as an input.
• out – Identifies the pin as an output that may participate in
busses.
• buffer – Identifies the pin as an output that may not
participate in buses.
• inout – Identifies the pin as a bidirectional signal pin.
• linkage – Used for other pins such as power, ground, analog,
or no- connect.

2 IEEE BSDL
<pin type> Specifies the type of the pin. Pin types include:
• bit_vector – Identifies the group of pins that handle a group
of signals within a specified range. The signals are indexed to
allow the system to identify which one is needed at a given
time.
• bit – Identifies a pin as one that handles a single signal. Each
pin assigned must have a unique name.
<range> Specifies the range of a group of signals for a pin vector.
Examples
port (CLK:in bit; Q:out bit_vector (1 to 8) );
-- assigns CLK and Q as port names
-- CLK is an input of type bit
-- Q is an output group of type bit_vector
-- with eight signals Q(1) through Q(8)
General Information
The pin types used with this statement are bit and bit_vector, which
are types known to VHDL. The types are used in this standard practice for
BSDL.

IEEE BSDL 2
use (BSDL)
Identifies a VHDL package needed to define the attributes of a device. For
BSDL, the use statement specifies the established package for IEEE
Standard 1149.1. BSDL also allows for user- specified packages that
address design applications beyond those established by the IEEE
standard, but that comply with the standard’s rules.
Syntax
use <VHDL identifier>;
Parameters
(none)
Examples
use STD_1149_1_2001.all -- Retrieves IEEE Standard 1149.1 information
use My_New_Cells.all -- Retrieves package defining user-specified cells
General Information
The standard practice for packages requires the .all extension to be
included in the use statements.

2 IEEE BSDL

2 Ieee BSDL: Medalist I3070 In-Circuit Test System Boundary-Scan Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 Ieee BSDL: Medalist I3070 In-Circuit Test System Boundary-Scan Testing

Uploaded by

Copyright:

Available Formats

Medalist i3070 In-circuit Test System

IEEE 1149.1 and BSDL History

2-2 Boundary-Scan Testing

Boundary-Scan Testing 2-3

2-4 Boundary-Scan Testing

Boundary-Scan Testing 2-5

Commonly Used Syntactic Elements

Example 2-1 Port ID Syntax

An <instruction name> is an instruction name defined by a manufacturer.

Example 2-2 Instruction Name Syntax

SAMPLE is used as an abbreviated name for SAMPLE/PRELOAD.

2-6 Boundary-Scan Testing

Components of a BSDL Description

Example 2-3 Entity

The order of the elements within the entity, as shown above, is a

Boundary-Scan Testing 2-7

• A package body contains declarations that define the function of the

A double-dash (--) is the VHDL convention for comments.

Figure 2-1 A Typical Entity, Package, and Package Body

2-8 Boundary-Scan Testing

The Entity Description

VHDL permits some elements within an entity description to be in an

The <component name> identifies a particular integrated circuit. Any

Boundary-Scan Testing 2-9

Generic Parameter Statement

Example 2-4 Generic Paramater Statement Syntax

In the first alternative <generic parameter> statement syntax, a <pin

2-10 Boundary-Scan Testing

• the <default device package type> specified in the <generic parameter>

Example 2-5 Generic Parameter Examples

generic (PHYSICAL_PIN_MAP : string := "DW_Package")

In the first example above, note that the string is initialized to an

Logical Port Description

Example 2-6 Logical Port Description Syntax

Boundary-Scan Testing 2-11

Table 2-1 Pin Types

The <port dimension> defines the number of signals comprising a port. If

2-12 Boundary-Scan Testing

Standard Use Statement

Example 2-7 Standard Use Statement Syntax

The <standard VHDL package identifiers> is the name of the Standard

Example 2-8 Use Statement Syntax

Example 2-9 Use Statement Example

Boundary-Scan Testing 2-13

Component Conformance Statement

Example 2-10 Component Conformance Statement Syntax

STD_1149_1_1990 refers to the 1990 issue of this standard,

Example 2-11 Component Conformance Statement Example

2-14 Boundary-Scan Testing

Copyright © 2001 IEEE All rights reserved.

Device Package Pin Mappings

Example 2-12 Device Package Pin Mappings Syntax

No subscripting of <port name> is allowed. Only the base name of a

Example 2-13 Device Package Pin Mappings Example

Attribute PIN_MAP is a string that is set to the value of the parameter

Boundary-Scan Testing 2-15

a name matching the value of PIN_MAP. BSDL’s standard practice

Example 2-14 Map String Example

2-16 Boundary-Scan Testing

Any <port name> element in a <port mapping> element of a given BSDL

Grouped Port Identification

Example 2-15 Grouped Port Identification Syntax

The <representative port> pin is to be treated as the positive ( + ) pin of