491© Springer International Publishing Switzerland 2016 K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5

Appendix ABSDL Syntax Specifi cations

This Appendix is a condensed listing of 2001 BSDL lexicography and syntax. It does not include the myriad semantic rules found in the BSDL specifi cation as provided by the IEEE [ IEEE01 ]. This information may be helpful to someone contemplating writing a BSDL parser, or to someone needing a quick reference guide for BSDL syntax when writing a BSDL description. It is assumed the reader is familiar with formalized specifi cation of language.

A.1 Conventions

All reserved words, predefi ned words, and punctuation are shown in Courier New type within this document. VHDL reserved and predefi ned words will be shown in lowercase letters, and BSDL reserved words will be shown in UPPERCASE letters. (BSDL itself is case-insensitive; this convention is adopted for descriptive clarity.)

A.2 Lexical Elements of BSDL

The lexical elements of BSDL are a subset and standard practice of those of VHDL as defi ned in IEEE Std 1076-1993. The following sections enumerate the lexical elements needed to understand the BSDL language defi nition.

A.2.1 Character Set

• Upper- and lowercase letters: A to Z and a to z (the language is not case sensitive).

492

• Digits: 0 – 9. • Special characters: " & ‘ ( ) * , - . : ; < = > • Logical separators: The space character, horizontal tabulation, vertical tabulation,

carriage return, line feed, and form feed.

A.2.2 Identifi ers

Identifi ers are user-supplied names and reserved words functioning as names. Identifi ers start with a letter and may contain letters, digits, or the underscore character. For example, the following are valid identifi ers:

Boundary_Scan IEEE_Std_1149_1

There is no limit to the number of characters in an identifi er. The underscore character ( _ ) is not allowed as the last character in an identifi er (by VHDL).

IEEE_STD_1149_ -- This is not a legal identifi er.

Adjacent underscore characters ( _ _ ) are not allowed.

A.2.3 BSDL Reserved Words

The identifi ers listed in this section are BSDL reserved words with a fi xed signifi -cance in the language. These identifi ers cannot be used for any other purpose in a BSDL description. For example, a reserved word cannot be used as an explicitly declared identifi er. BC_0 to BC_99 are variable names used in the Standard VHDL Package. Names BC_0 through BC_ 10 are used today, while BC_11 through BC_99 are reserved for future use. Similarly, the names STD_1149_1_1990 , STD_1149_1_1993 , STD_1149_1_1994 and STD_1149_1_2001 have been reserved, with the potential for new names to be added later. Therefore, avoid using identifi ers that start with “ STD_1149_ ”.

AT_PINS INTERNAL BC_0 to BC_99 INTEST BIDIR INTEST _ EXECUTION BIDIR_IN KEEPER BIDIR_OUT LOW BOTH OBSERVE_ONLY BOUNDARY OBSERVING BOUNDARY_ LENGTH ONE BOUNDARY_ REGISTER OUTPUT2

A BSDL Syntax Specifi cations

493

BSCAN_INST OUTPUT3 BSDL_EXTENSION PHYSICAL_PIN_ MAP BYPASS PI CAP PIN_ MAP CAP_DATA PIN_ MAP _STRING CAPTURES PO CELL_DATA PORT_ GROUPING CELL_INFO PRELOAD CELL_TYPE PULL0 CLAMP PULL1 CLOCK REGISTER_ ACCESS CLOCK_INFO RUNBIST CLOCK_LEVEL RUNBIST _ EXECUTION COMPLIANCE_ PATTERNS SAMPLE COMPONENT_ CONFORMANCE STD_1149_1_1990 CONTROL STD_1149_1_1993 CONTROLR STD_1149_1_1994 DESIGN_ WARNING STD_1149_1_2001 DEVICE_ID TAP_SCAN_ CLOCK DIFFERENTIAL_CURRENT TAP_SCAN_ IN DIFFERENTIAL_VOLTAGE TAP_SCAN_ MODE EXPECT_DATA TAP_SCAN_ OUT EXTEST TAP_SCAN_ RESET HIGHZ UPD ID_BITS USERCODE ID_STRING USERCODE _ REGISTER IDCODE WAIT_DURATION IDCODE _ REGISTER WEAK0 INPUT WEAK1 INSTRUCTION_ CAPTURE X INSTRUCTION_ LENGTH Z INSTRUCTION_ OPCODE ZERO INSTRUCTION_ PRIVATE

A.2.4 VHDL Reserved and Predefi ned Words

The identifi ers listed below are called VHDL ( IEEE Standard 1076 -1993) reserved and predefi ned words with a fi xed signifi cance in the language. These identifi ers may not be used for any other purpose in a BSDL description. For example, a reserved word cannot be used as an explicitly declared identifi er. Reserved words shown in the list below in lowercase letters are part of the BSDL subset of VHDL. Those in uppercase letters are not part of BSDL, but should not be used as

A.2 Lexical Elements of BSDL

494

identifi ers. The latest edition of the VHDL standard [ IEEE93b ] shall be consulted as the fi nal authority .

ABS GUARDED REGISTER ACCESS IF REJECT AFTER IMPURE REM ALIAS in REPORT all INERTIAL RETURN AND inout ROL ARCHITECTURE is ROR array LABEL SELECT ASSERT LIBRARY SEVERITY attribute linkage SHARED BEGIN LITERAL signal bit LOOP SLA bit_vector MAP SLL BLOCK MOD SRA body NAND SRL buffer NEW string BUS NEXT subtype CASE NOR THEN COMPONENT NOT to CONFIGURATION NULL TRANSPORT constant of true DISCONNECT ON type downto OPEN UNAFFECTED ELSE OR UNITS ELSIF OTHERS UNTIL end out use entity package VARIABLE EXIT port WAIT false positive WHEN FILE POSTPONED WHILE FOR PROCEDURE WITH FUNCTION PROCESS XNOR GENERATE PURE XOR generic range GROUP record

A.2.5 Strings

A string is defi ned as a sequence of zero or more characters enclosed between quo-tation marks. A quotation mark character is not allowed within a string in BSDL. For example,

A BSDL Syntax Specifi cations

495

"Mary had a little lamb" -- Allowed "Fred said ""HELP""" -- Not allowed

Strings are used extensively in BSDL. Because many of the BSDL strings are potentially much longer than a single line, the concatenation operator & is used to break them into manageable pieces. For example,

"Jack be nimble," & " Jack be quick."

is a single string, identical to

"Jack be nimble, Jack be quick."

BSDL does not permit replacement of the quotation mark with any other charac-ter. A string literal must fi t on one line since it is a lexical element.

A.2.6 Comments

Any text between a double dash ( -- ) symbol and the end of a line is treated as a comment. The text is allowed to contain any characters allowed by VHDL. Comments syntactically terminate a line of a description. Comments may be interspersed with lexical elements. For example, the following represents a single VHDL string:

"This is" & -- An example of a string split by a comment " a single string"

A.3 Notes on Syntax Defi nition

A.3.1 BNF Conventions

• Any item enclosed in chevrons (i.e., between the character “<” and the character “>”) is the name of a syntax item that will be defi ned in this appendix.

• Items enclosed by braces (i.e., between the character “{” and the character “}”) may be omitted or included one or more times.

• Items enclosed between square brackets (i.e., between the character “[” and the character “]”) may be omitted or included only one time.

• Items enclosed between the symbols “→” and “←” may appear in any order. • Except with regard to case, text shown in Courier New type font has to be

included exactly as it is presented in this appendix. • Alternative syntaxes are separated by a vertical bar (“|” ). • The symbol “::=” should be read as “is defi ned as.” Note that the non-boldface

“::=” is only part of a BNF description; in the BSDL fi le, the boldface characters “ := ” are used to indicate assignment.

A.3 Notes on Syntax Defi nition

496

• White space (spaces, tabulation, carriage returns, etc.) is used in these BNF descriptions to enhance readability and is not part of the syntax. However, white space needed for resolving lexical ambiguity is required.

A.3.2 Lexical Atoms

• A <VHDL identifi er> is a valid identifi er, chosen as a name for an item. • An <integer> is an unsigned VHDL integer made up of an unsigned numeric

character sequence not containing an underscore (_) character and not using an exponent fi eld.

• A <real number> is a VHDL real number of the form <integer> . <integer> or <integer> . <integer> E <integer> all written contiguously without spaces or for-mat effectors. Note 1E3 is not real because it does not 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 con-taining no spaces. 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 left bracket character ( [ ). • A <right bracket> is the right bracket character ( ] ).

Lexical ambiguity exists in certain situations and has to be resolved by context. For example, a <pattern> that starts with an X has to be differentiated from a <VHDL identifi er> by context derived from the syntax. Similarly, a <pattern> that does not contain an X has to be differentiated from an integer such as 100 (one hundred).

A.3.3 Commonly Used Syntactic Elements

• A <port ID> identifi es a component signal that may be used to interface to exter-nal 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.

<port ID>::= <port name> | <subscripted port name> <port name>::= <VHDL identifi er> <subscripted port name>::= <VHDL identifi er> ( <subscript> ) <subscript>::= <integer>

• An <instruction name> is an instruction name defi ned in this standard or a name given to an instruction by the manufacturer of a component.

<instruction name>::= BYPASS | CLAMP | EXTEST | HIGHZ | IDCODE | INTEST | PRELOAD | RUNBIST | SAMPLE | USERCODE | <VHDL identifi er>

A BSDL Syntax Specifi cations

497

A.4 BSDL Syntax

The BSDL entity description must have the following structure:

<BSDL description>::= entity <component name> is <generic parameter> <logical port description> <standard use statement> {<use statement>} <component conformance statement> <device package pin mappings> [<grouped port identifi cation>] <scan port identifi cation> [<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 identifi er>

<generic parameter>::= generic (PHYSICAL_PIN_ MAP : string); | generic (PHYSICAL_PIN_ MAP : string := <default device package type> ); <default device package type>::= " <VHDL identifi er> " <logical port description>::= port ( <pin spec> {; <pin spec>} ); <pin spec>::= <identifi er list> : <pin type> <port dimension> <identifi er 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> <standard use statement>::= use <standard VHDL package identifi er> .all ; <standard VHDL package identifi er>::= STD_1149_1_1990 | STD_1149_1_1994 | STD_1149_1_2001 | <other package identifi er> <other package identifi er>::= <VHDL identifi er>

A.4 BSDL Syntax

498

<use statement>::= use <user VHDL package identifi er> .all ; <user VHDL package identifi er>::= <VHDL identifi er> <component conformance statement>::= attribute COMPONENT_CONFORMANCE of <component name> : entity is <conformance string> ; <conformance string>::= " <conformance identifi cation> " <conformance identifi cation>::= STD_1149_1_1990 | STD_1149_1_1993 | STD_1149_1_2001 <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 identifi er> <map string>::= " <port map> { , <port map>} " <port map>::= <port name> : <pin list> <pin list>::= <pin ID> | ( <pin ID> { , <pin ID>} ) <pin ID>::= <VHDL identifi er> | <integer> <grouped port identifi cation>::= 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> <scan port identifi cation>::= → <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;

A BSDL Syntax Specifi cations

499

<TRST stmt>::= attribute TAP_SCAN_RESET of <port ID> : signal is true; <clock record>::= <real number> , <halt state value> <halt state value>::= LOW | BOTH <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> } <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> ) <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> "

A.4 BSDL Syntax

500

<32-bit pattern list>::= <32-bit pattern> {, <32-bit pattern>} <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 identifi er> <left bracket> <register length> <right bracket> <register length>::= <integer> <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 bit> <cell name>::= <VHDL identifi er> <port ID or null>::= <port ID> | * <function>::= INPUT | OUTPUT2 | OUTPUT3 | CONTROL | CONTROLR | INTERNAL | CLOCK | 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 | PULL1 | KEEPER <runbist description>::= attribute RUNBIST _ EXECUTION of <component name>

A BSDL Syntax Specifi cations

501

: 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 <intest description>::= attribute INTEST _ EXECUTION of <component name> : entity is " <intest execution sequence> "; <intest execution sequence>::= <wait spec> , <pin spec> <BSDL extensions>::= <BSDL extension> { <BSDL extension> } <BSDL extension>::= <extension declaration> | <extension defi nition> <extension declaration>::= attribute <extension name> : BSDL_EXTENSION; <extension defi nition>::= attribute <extension name> of <component name> : entity is <extension parameter string> ; <extension name>::= <entity defi ned name> | <VHDL package defi ned name> <entity defi ned name>::= <VHDL identifi er> <VHDL package defi ned name>::= <VHDL identifi er> <extension parameter string>::= <string> <design warning>::= attribute DESIGN_WARNING of <component name> : entity is <string> ;

A.5 User Package Syntax

<user package>::= package <user package name> is <standard use statement> { <extension declaration> } { <deferred constant> } end <user package name> ;

<user package body>::= package body <user package name> is

A.5 User Package Syntax

502

<standard use statement> { <cell description constant> } end <user package name> ;

<user package name>::= <VHDL identifi er> <deferred constant>::= constant <cell name> : CELL_INFO; <cell name>::= <VHDL identifi er> <cell description constant>::= constant <cell name> : CELL_INFO := ( <capture descriptor list> ) ; <cell name>::= <VHDL identifi er> <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.6 1149.6 Extention Attribute Syntax

The 1149.6 extension contains some new attributes with a specifi c syntax that needs to be recognized by tools that support 1149.6. An example is shown in Sect. 8.6.3 on page 331. This syntax is listed here:

<AIO Extension> ::= <AIO component conformance statement> → [<AIO optional EXTEST_PULSE description>] [<AIO optional EXTEST_TRAIN description>] ← [<AIO optional pin behavior description>]

<AIO component conformance statement> :: = attribute AIO_Component_Conformance of <component name> : entity is <AIO conformance string> ; <AIO conformance string> ::= " <AIO conformance identifi cation> " <AIO conformance identifi cation> ::= STD_1149_6_2003

<AIO optional EXTEST_PULSE description> :: = attribute AIO_EXTEST_Pulse_Execution of <component name> : entity is <AIO EXTEST_Pulse string> ; <AIO EXTEST_Pulse string> ::= " <AIO EXTEST_Pulse spec> "

A BSDL Syntax Specifi cations

503

<AIO EXTEST_Pulse spec> ::= wait_duration <time spec> <time spec> ::= <real number> | <clock cycles> <clock cycles> ::= <port ID> <integer>

<AIO optional EXTEST_TRAIN description> :: = attribute AIO_EXTEST_Train_Execution of <component name> : entity is <AIO EXTEST_Train string> ; <AIO EXTEST_Train string> ::= " <AIO EXTEST_Train spec> " <AIO EXTEST_Train spec> ::= <min pulse count> [ , <max time spec> ] <min pulse count> ::= train <pulse count> <max time spec> ::= maximum_time <real number> <pulse count> ::= <integer>

<AIO optional pin behavior description> :: = attribute AIO_Pin_Behavior of <component name> : entity is <AC pin string> ; <AC pin string> ::= " <AC pin info list> " <AC pin info list> ::= <AC pin info> { ; <AC pin info> } <AC pin info> :: = <AC port list> [ : [<AC/DC select cell> ][ <time constants> ]] <AC port list> ::= <AC port> { , <AC port> } <time constants> ::= [ <LP time constant> ] [ <HP time constant> ] <AC port> ::= <port ID> [ <input cell list> ] <input cell list> ::= <left bracket> <cell number list> <right bracket> <cell number list> ::= <cell number> { , <cell number> } <AC/DC select cell> ::= AC_Select = <cell number> <LP time constant> ::= LP_time = <time constant> <HP time constant> ::= HP_time = <time constant>[ On_chip ] <time constant> ::= <real number>

A.6 1149.6 Extention Attribute Syntax

505© Springer International Publishing Switzerland 2016 K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5

Appendix B2013 BSDL Syntax Revisions

This Appendix is a compendium of changes to the 2001 version of BSDL lexicog-raphy and syntax which were introduced in the 2013 version of the 1149.1 standard. It does not include the myriad semantic rules found in the BSDL specifi cation as provided by the IEEE [ IEEE13 ]. This information supplements that found in Appendix A and follows the same conventions. It also completes the introductory information in Chap. 11 which serves to motivate why these changes exist.

B.1 Reserved Word Changes

There are two categories of reserved words in BSDL; fi rst are those inherited from VHDL (see Sect. A.2.4 ) and second are those defi ned by BSDL itself (see Sect. A.2.3 ).

B.1.1 VHDL Reserved Words

In Sect. A.2.4 there is a table of VHDL reserved words. These are divided into two groups with one group (in lowercase letters) being a set of reserved words from VHDL that have specifi c meaning in BSDL. The second group (in uppercase letters) were other VHDL reserved words not adopted by BSDL. These were considered reserved anyway and BSDL code was not to use them, since that would prevent

506

such code from being parsed by a VHDL tool. That is no longer the case with the 2013 release, so the only VHDL reserved words are shown in this abbreviated table.

All Entity Positive Array Generic Range Attribute In Record Bit Inout Signal Bit_vector Is String Body Of Subtype Buffer Others To Constant Out True Downto Package Type End Port Use

B.1.2 BSDL Reserved Words

In Sect. A.2.3 there is a table of BSDL reserved words. This list has been lengthened by adding the following 66 reserved words.

Broadcastfi eld Open0 Broadcastvalues Open1 Clamp_hold OpenX Clamp_release Power_0 Default Power_pos DelayPO Power_neg Domain Power_port_association Domain_external Pulse0 Domctrl Pulse1 Dompor Register_access ECID Register_assembly ECIDcode Register_association Expect0 Register_constraints Expect1 Register_fi elds Hierreset Register_mnemonics IC_reset Reset_select Init_data Resetval Init_run Segment Init_setup Segmux Init_setup_clamp Segsel Init_Status Segstart Linkage_buffer Selectmux Linkage_in Selectfi eld Linkage_inout Selectvalues Linkage_mechanical Shared

B 2013 BSDL Syntax Revisions

507

Linkage_out TAPreset Mon Tie0 NoPI Tie1 NoPO TMP_Status Noretain TRSTreset NoUPD User One_hot Vref_in Open Vref_out

B.1.3 Numeric Literals

Appendix A lists several numeric literals: <integer>, <real number>, <pattern> and <32-bit pattern> (see Sect. A.3.2 ). The 2013 revision of BSDL adds three new numeric literal types:

• <binary pattern> is a contiguous string starting with 0b or 0B , followed by one character from the set [01xX] and zero or more characters from the set [01xX_] . No spaces or format effectors 1 may be embedded.

• <hex pattern> is a contiguous string starting with 0x or 0X , followed by one character from the set [0-9a-fA-F] followed by zero or more characters from the set [0-9a-fA-F_] . No spaces or format effectors may be embedded.

• <decimal pattern> is an unsigned contiguous string of characters from the set [0-9] , that does not have ‘ 0 ’ for the most signifi cant (leftmost) digit of a multi- digit number, contains no spaces or format effectors, and has a binary representa-tion that fi ts within a 32-bit binary fi eld. 2

B.1.4 Identifi ers

Identifi ers are user-supplied names with the syntax token of <VHDL identifi er> (see Sect. A.2.2 ). The 2013 revision of BSDL adds the concept of a <mnemonic identifi er> and it is formed according a list of requirements. It also defi nes <prefi x identifi er>.

A <mnemonic identifi er> any combination of alphabetic characters (case insen-sitive), digits and certain special characters such that:

• It contains at least one alphabetic character. • It cannot be resolved to a <real>, <integer>, <binary pattern> <hex pattern>,

<decimal pattern> or <pattern> value. • It is not the single character “U” (or “u”).

1 Format effectors include carriage returns, tab characters, line feeds, page ejects, etc. 2 This means the decimal number must be less than or equal to 2 32 -1, which is 4,294,967,295.

B.1 Reserved Word Changes

508

• It cannot start with, or contain the BSDL comment characters, that is, double- dash “--”.

• It may include these special characters:

– At-sign (@) – Asterisk (*) – Underscore (_) – Minus sign (−) – Plus sign (+) – Vertical bar (|) – Percent sign (%) – Tilde (~) – Period (.)

• It may be a valid <VHDL identifi er>.

A <prefi x identifi er> is any combination of letters (case insensitive), digits and the underscore character, not starting with a digit. A valid <VHDL identifi er> may serve as a <prefi x identifi er>. (With the exception of case insensitivity, a <prefi x identifi er> follows the rules for Verilog identifi ers. 3 ) Prefi x identifi ers are used in <register fi elds statement> descriptions (see Sect. 11.4.20 ) and certain PDL state-ments (see Sect. 11.5 ).

B.1.5 Information Tags

An <information tag> is a nearly free-form string of zero or more characters with very few restrictions. They are used to convey descriptive information, more like comment text rather than strict syntax.

An <information tag> is:

• Zero or more characters contained between enclosing chevrons (< >). • The enclosed characters may not include the right chevron (>), quotation mark

(“), double-dash (--) or format effectors.

An <information tag> cannot contain a BSDL comment and though it appears in BSDL strings, it cannot itself contain a quotation mark. Since BSDL strings can be expressed as concatenated smaller strings, a long information tag can be broken up with the string concatenation method.

B.1.6 Port Types

The defi nition of <port type> is greatly expanded. These new types were added to replace the LINKAGE type: LINKAGE_BUFFER , LINKAGE_IN , LINKAGE_INOUT , LINKAGE_MECHANICAL , LINKAGE_OUT , POWER_0 ,

3 Verilog is a hardware description language alternative to VHDL in common use.

B 2013 BSDL Syntax Revisions

509

POWER_NEG , POWER_POS , VREF_IN and VREF_OUT . See 11.4.7 for a discussion of what these terms mean.

B.1.7 Pin Description

In Sect. A.4 you will see pins identifi ed by <pin ID> tokens, and these can be either <integer> values, or <VHDL identifi er> values, refl ecting pins that are numbered (33, 52, etc.), or have alphanumeric names like G13 or B7. This has been expanded in the 2013 revision so <pin ID> has been recast as <pin desc> and we see this syntax:

<pin desc> ::= <pin ID> | OPEN | TIE0 | TIE1 <pin ID>::= <VHDL identifi er> | <integer>

These keywords allow a bit more descriptive information to be associated with ports that touch the Boundary register, but are not bonded out of the package in some of the packaging options. The details of pin descriptions are given in Sect. 11.4.11 .

B.1.8 Instructions

In Sect. A.3.3 we see a defi nition of <instruction name>. This has been expanded with the 2013 release of BSDL.

<instruction name>::= BYPASS | CLAMP | EXTEST | HIGHZ | IDCODE | INTEST | PRELOAD | RUNBIST | SAMPLE | USERCODE | ECIDCODE | CLAMP_HOLD | CLAMP_RELEASE | TMP_STATUS | IC_RESET | INIT_SETUP | INIT_SETUP_CLAMP | INIT_RUN | <VHDL identifi er>

The new instructions are only defi ned for the 2013 release, so the conformance identifi cation must be STD_1149_1_2013 for them to appear.

B.2 BSDL Syntax

A BSDL entity description documents an IC at the die level, and also includes infor-mation about one or more packaging alternatives, including just a bare die, if it is ever operated as such. 4 The 2013 revision of BSDL added a number of new descrip-tive attributes to the language, and made some other changes. Those are shown

4 For example, if the Boundary-Scan circuitry is tested on an IC tester before packaging, the die pad mapping will be needed.

B.2 BSDL Syntax

510

below and are commented on the right side of the page. The comments are not part of the description.

The BSDL entity description must have the following structure:

<BSDL description>::= entity <component name> is <generic parameter> <logical port description> --changed at 2013 <standard use statement> {<use statement>} <component conformance statement> <device package pin mappings> --changed at 2013 [<grouped port identifi cation>] <scan port identifi cation> [<compliance enable description>] <instruction register description> [<optional register description>] [<register access description>] --changed at 2013 <boundary-scan register description> --changed at 2013 [<runbist description>] [<intest description>] [<system clock description>] --added at 2013 {<register mnemonics description>} --added at 2013 {<register fi elds description>} --added at 2013 {<register assembly description>} --added at 2013 {<register constraints description>} --added at 2013 {<register association description>} --added at 2013 {<power port association description>} --added at 2013 {<BSDL extensions>} [<design warning>]

end <component name>;

The changed or added syntax structures are described in the remainder of this section.

B.2.1 Logical Port Description

The <logical port description> syntax has undergone a few simple changes, in the area of <pin type>:

<logical port description>::= port <left paren> <pin spec> { <semicolon> <pin spec> } <right paren> <semicolon> <pin spec>::= <identifi er list> <colon> <pin type> <port dimension> <identifi er list>::= <port name> { <comma> <port name>}

B 2013 BSDL Syntax Revisions

511

<pin type>::= in | out | buffer | inout | LINKAGE_INOUT | LINKAGE_BUFFER | LINKAGE_IN | LINKAGE_OUT | LINKAGE_MECHANICAL | POWER_0 | POWER_POS | POWER_NEG | VREF_IN | VREF_OUT

<port dimension>::= bit | <bit vector spec> <bit vector spec> ::= bit_vector <left paren> <range> <right paren> <range>::= <up range> | <down range> <up range> ::= <integer1> to <integer2> <down range> ::= <integer2> downto <integer1> <integer1>::= <integer> <integer2>::= <integer>

The pin type assignments are expanded. See Sect. 11.4.7 for their meanings.

B.2.2 Device Package Mappings

Some new detail is provided by the <device package pin mappings> area of BSDL. This is <pin desc> information and is described in Sect. 11.4.11 .

<device package pin mappings>::= <pin map statement> <pin mappings> <pin map statement>::= attribute PIN_MAP of <component name> <colon>

entity is PHYSICAL_PIN_MAP <semicolon> <pin mappings>::= <pin mapping> { <pin mapping> } <pin mapping>::= constant <pin mapping name> <colon>

PIN_MAP_STRING := <map string> <semicolon> <pin mapping name>::= <VHDL identifi er> <map string>::= <quote> <port map> { <comma> <port map> } <quote> <port map>::= <port name> <colon> <pin or list> <pin or list>::= <pin desc> | <pin list> <pin list> ::= <left paren> <pin desc> { <comma> <pin desc>} <right paren> <pin desc> ::= <pin ID> | OPEN | TIE0 | TIE1 <pin ID>::= <VHDL identifi er> | <integer>

B.2.3 Register Access Description

The original <register access description appears as part of Sect. A.4 . It has been expanded as shown here:

<register access description> ::= attribute REGISTER_ACCESS of <component name> <colon> entity is <register access string> <semicolon>

B.2 BSDL Syntax

512

<register access string>::= <quote> <register association> { <comma> <register association> } <quote>

<register association>::= <register> <left paren> <instruction capture list> <right paren> <instruction capture list>::= <instruction capture> { <comma>

<instruction capture> } <instruction capture>::= <instruction name> [ CAPTURES <pattern> ] <register>:: = <std fi xed register> | <std var register> | <design

specifi c register> <std fi xed register>::= BOUNDARY | BYPASS | DEVICE_ID | TMP_STATUS <std var register>:: = <std var reg name> [ <left bracket>

<reg length> <right bracket> ] <std var reg name>::= ECID | INIT_DATA | INIT_STATUS | RESET_SELECT <design specifi c register>::= <VHDL identifi er> [ <left bracket> <reg length> <right bracket> ] <reg length>::= <integer> | <asterisk>

B.2.4 Boundary-Scan Register Description

The Boundary-Scan register syntax has been expanded to describe both the pre- 2013 “static” or “fi xed” register and the new “segmented” register form. More descriptive detail for individual cells is also included, as discussed in Sect. 11.4.13 . The syntax of Boundary register description starts out like this:

<boundary-scan register description> ::= <fi xed boundary stmts> | <segment boundary stmts> <fi xed boundary stmts> ::= <boundary length stmt> <boundary register stmt> <segment boundary stmts> ::= <assembled boundary length stmt> <boundary register segments>

Here we see the two forms, fi xed and segmented. Each has a length statement followed by the register description, either fi xed or segmented. First let’s look at the fi xed form, discussed in Sect. 11.4.14 .

<boundary length stmt> ::= attribute BOUNDARY_LENGTH of <component name> <colon> entity is <register length> <semicolon> <register length> ::= <integer> <boundary register stmt> ::= attribute BOUNDARY_REGISTER of <component name> <colon> entity is <cell table string> <semicolon> <cell table string> ::= <quote> <cell table> <quote> <cell table> ::= <cell entry> { <comma> <cell entry> }

B 2013 BSDL Syntax Revisions

513

<cell entry> ::= <cell number> <left paren> <cell info> <right paren> <cell number> ::= <integer> <cell info> ::= <cell spec> [ <comma> <input or disable spec> ] <cell spec> ::= <cell name> <comma> <port ID or null> <comma> <function> <comma> <safe bit> <cell name> ::= <VHDL identifi er> <port ID or null> ::= <port ID> | <asterisk> <function> ::= INPUT | OUTPUT2 | OUTPUT3 | CONTROL | CONTROLR | INTERNAL | CLOCK | BIDIR | OBSERVE_ONLY <safe bit>::= 0 | 1 | X <input or disable spec> ::= <input spec> | <disable spec> <input spec> :: = EXTERN0 | EXTERN1 | PULL0 | PULL1 | OPEN0 | OPEN1 | KEEPER | OPENX | EXPECT1 | EXPECT0 <disable spec>::= <ccell> <comma> <disable value> <comma> <disable result> <ccell>::= <integer> <disable value>::= 0 | 1 <disable result>::= WEAK0 | WEAK1 | PULL0 | PULL1 | OPEN0 | OPEN1 | KEEPER | Z

Note above that both <input spec> and <disable result> have expanded lists of keywords, as discussed in Sect. 11.4.13 . Also note that a token called <input or dis-able spec> has been inserted into the <cell info> syntax. This accounts for the new <input spec> that may appear in a cell entry.

Next, here is the syntax for segmented Boundary register description, discussed in Sect. 11.4.15 .

<assembled boundary length stmt> ::= attribute ASSEMBLED_BOUNDARY_LENGTH of <component name> <colon> entity is <left paren> <reset length> <comma> <register length> <right paren> <semicolon> <reset length> ::= <integer> <boundary register segments> ::= <boundary register segment> { <boundary register segment> } <boundary register segment> ::= attribute BOUNDARY_SEGMENT of <component name> <colon> entity is <boundary segment string> <semicolon> <boundary segment string>::= <quote> <boundary segment list> { <comma> <boundary segment list> } <quote> <boundary segment list>::= <boundary segment name> <left bracket> <boundary segment length> <right bracket> <left paren> <cell table> <right paren> < boundary segment name > ::= <VHDL identifi er> <boundary segment length> ::= <integer>

B.2 BSDL Syntax

514

Note that <register length> and <cell table> defi nitions are given up in the fi xed register syntax, and is the same. The length statement differs in that it gives two numbers for the Boundary register length, a “reset length” followed by a “register length”. This is also discussed in Sect. 11.4.15 .

B.2.5 System Clock Description

In some cases, an instruction will not work without a system clock being supplied for its operation. The 1149.1 working group has provided a way in BSDL to describe where such clocking is needed. This is the new SYSCLOCK_REQUIREMENTS attribute. Here is the syntax:

<system clock description> ::= attribute SYSCLOCK_REQUIREMENTS of <entity target> is <system clock description string> <semicolon> <system clock description string>::= <quote> <system clock requirement> { <comma> < system clock requirement> } <quote> <system clock requirement>::= <left paren> <port ID> <comma> <min freq> <comma> <max freq> <comma> <clocked instructions> <right paren> <min freq> ::= <real> <max freq> ::= <real> <clocked instructions> ::= <clocked instruction> { <comma> <clocked instruction> } <clocked instruction> ::= RUNBIST | INTEST | INIT_SETUP | INIT_RUN | INIT_SETUP_CLAMP | ECIDCODE | IC_RESET | <VHDL identifi er>

The <port ID> must refer to a port with an input capability (IN, INOUT, LINKAGE_IN or LINKAGE_INOUT) and if it is a differential clock input pair, the representative port is identifi ed. Note that if the compliance level of the device is pre-2013, then only RUNBIST or INTEST may be the clocked instruction. If the device is a 2013-compliant device, then more standard instructions are allowed (see <clocked instruction> above) but not those like EXTEST, BYPASS, SAMPLE, PRELOAD, etc. These instructions use only TCK for clocking. Designer-specifi ed instructions that require clocking are provided by their <VHDL identifi er>. See more discussion and an example in Sect. 11.4.17 .

B.2.6 Register Mnemonics Description

Register Mnemonics are a way in BSDL to associate names (called <mnemonic identifi ers>, see Sect. A.1.4) with numeric bit patterns (binary, hexadecimal, or decimal) and also attach an optional descriptive <information tag> (see Sect. A.1.5) with them. See usage detail and examples in Sect. 11.4.18 .

B 2013 BSDL Syntax Revisions

515

This is the register mnemonic description syntax:

<register mnemonics description>::= attribute REGISTER_MNEMONICS of <target> is <register mnemonics string> <semicolon> <target>::= <entity target> | <package target> <entity target>::= <component name> <colon> entity <package target>::= <user package name> <colon> package <register mnemonics string>::= <quote> <mnemonic defi nition>

{ <comma> <mnemonic defi nition> } <quote> <mnemonic defi nition>::= <mnemonic group name> <left paren>

<mnemonic list> <right paren> <mnemonic group name>::= <VHDL identifi er> <mnemonic list>::= <mnemonic assignment>

{ <comma> <mnemonic assignment> } <mnemonic assignment>::= <mnemonic identifi er> <left paren> <pattern specifi cation> <right paren> [ <information tag> ] <pattern specifi cation>::= <binary pattern> | <hex pattern> | <decimal pattern> | others

A <register mnemonics description is basically a comma-separated list of <mnemonic defi nition> terms, each consisting of a group name <VHDL identi-fi er> followed by a parentheses-enclosed list of comma-separated <mnemonic assignment> terms. Each such <mnemonic assignment> associates a <mnemonic identifi er> with a <pattern specifi cation> followed, optionally, with an <informa-tion tag>. All <mnemonic group name> elements must be unique within its con-taining entity or package description. All <mnemonic identifi er> elements that appear in a <mnemonic list> must be unique within that list, but duplicates could appear across multiple <mnemonic list> elements if more than one exists. Each <mnemonic list> must contain at least one <mnemonic assignment> containing a <binary pattern>, <hex pattern> or <decimal pattern>. This means you cannot have a <mnemonic list> containing only one <mnemonic assignment> which contains the keyword others .

When listing patterns in a <mnemonic list>, regardless of their being expressed in binary, hex or decimal, they must be unique; however, all possible patterns do not need to be specifi ed. Note that “X” bits may exist in (only) a binary pattern. This indicates that bit position may have either a ‘0’ or ‘1’ bit present, implying multiple patterns. When such a binary pattern is used, all of its implied patterns belong to the associated <mnemonic identifi er> and must not be found in another portion of the <mnemonic list>.

Unused pattern values may be referenced with the others keyword, and if this keyword is listed in a <mnemonic list>, it must be the last one listed. When a <mne-monic identifi er> is associated with the others keyword, then all the patterns not otherwise specifi ed earlier in the list have that <mnemonic identifi er> and that (optional) <information tag>.

B.2 BSDL Syntax

516

B.2.7 Register Fields Description

The register fi elds description is used to describe a data register and any segments that make it up. The overall length of a register is given, followed by a listing of its seg-ments, also named and with lengths provided. Note that not all bits of the data register may be described within some segment, that is, some may be left undefi ned. The syntax is given next, but, is divided into two portions. The fi rst portion is unique to the register fi elds attribute. The second is used by both the register fi elds and register assembly attribute (see Sect. A.2.8) and it provides defi nitions of items like <value assignment>, <type assignment> and <reset assignment>. The fi rst syntax portion is:

<register fi elds description> ::= attribute REGISTER_FIELDS of <target> is <register fi elds string> <semicolon> <register fi elds string>::= <quote> <register fi eld list> { <comma> <register fi eld list> } <quote> <register fi eld list>::= <reg or seg name> <left bracket> <reg or seg length> <right bracket> <left paren> <register fi elds> <right paren> <reg or seg name>::= <TDR> | <segment name> <TDR>::= BOUNDARY | BYPASS | DEVICE_ID | TMP_STATUS | ECID | INIT_DATA | INIT_STATUS | RESET_SELECT | <design specifi c TDR name> <segment name>::= <VHDL identifi er> <design specifi c TDR name>::= <VHDL identifi er> <reg or seg length>::= <integer> <register fi elds>::= <left paren> <register fi eld element> <right paren> { <comma> <left paren> <register fi eld element> <right paren> } <register fi eld element>::= <register fi eld> | <prefi x statement> <register fi eld>::= <extended fi eld name> <fi eld length> is <bit list and options> <extended fi eld name> ::= <prefi x string> <fi eld name> <prefi x string>::= { <prefi x identifi er> <period> } <fi eld name>::= <VHDL identifi er> <fi eld length>::= <left bracket> <integer> <right bracket> <bit list and options>::= <bit list> { <fi eld options> } <fi eld options> ::= <type assignment> | <value assignment> | <reset assignment> <bit list>::= <left paren> [ <bit fi eld> { <comma> <bit fi eld> } ] <right paren> <bit fi eld>::= <range> | <integer> <prefi x statement>::= PREFIX <integer> <prefi x name> <prefi x name> ::= <prefi x identifi er> | <minus sign>

The defi nition of <range> is found in Sect. A.4 . The defi nition of <prefi x identi-fi er> is found in Sect. A.1.4. When a <reg or seg name> is that defi ned by the stan-

B 2013 BSDL Syntax Revisions

517

dard (e.g., DEVICE_ID, BOUNDARY, etc.) then the value of <reg or seg length> must equal the length of the register as already provided. Any bit number listed in a <bit list> must be less than the <reg or seg length> for that <reg fi eld list>. The bit number zero is closest to TDO. When one or more <prefi x statement> elements are fi rst found in a <register fi eld list>, then they must be listed in numerical order start-ing with Prefi x 0. If a <prefi x statement> is found in a subsequent <register fi eld list>, then it will overwrite the previous <prefi x statement> with the same number and erase all statements with larger numbers. If a <prefi x statement> is given with a name of <minus sign> that will erase all previously defi ned prefi xes. When an <extended fi eld name> is encountered and there are defi ned prefi xes, then that name will have all of the prefi xes prepended in their numerically ascending order, sepa-rated with ‘.’ characters. All <extended fi eld name> elements must be unique within a BSDL entity or package. When a <fi eld length> is zero, then the associated <bit list> must be empty “()”. A test register bit number may be referenced in more than one <register fi eld>, but within a given <register fi eld>, it may only appear once. See examples in Sect. 11.4.20 .

Next is the second portion of syntax, shared with the register assembly attribute:

<value assignment>::= <value keyword> <left paren> <assignment> <right paren> <value keyword>::= CAPTURES | DEFAULT | SAFE | RESETVAL | <user extension> <user extension>::= USER <colon> <user keyword> <user keyword>::= <VHDL identifi er> <assignment>::= <assignment value> | <asterisk> | <minus sign> <assignment value>::= <binary pattern> | <hex pattern> | <decimal pattern> | <mnemonic association> <mnemonic association>::= [ PACKAGE <package hierarchy> <colon> ] <mnemonic group name> <left paren> <mnemonic default> <right paren> <mnemonic default>::= <mnemonic identifi er> | <asterisk> | <minus sign> <type assignment>::= NOPI | NOPO | NOUPD | MON | PULSE0 | PULSE1 | DELAYPO | NORETAIN | SHARED | <user extension> <reset assignment>::= PORRESET | TRSTRESET | TAPRESET | CHRESET | DOMPOR | HIERRESET | <local reset assignment> <local reset assignment>::= <reset type> <left paren> <reset ident> <right paren> <reset type::= RESETOUT | RESETIN <reset ident>::= <VHDL identifi er> <domain assignment>::= <association type> <left paren> <associa-tion name> <right paren> <association type>::= DOMAIN | DOMAIN_EXTERNAL | SEGMENT <association name>::= <VHDL identifi er>

B.2 BSDL Syntax

518

B.2.8 Register Assembly Description

The register assembly description is used to defi ne registers or segments of registers by the concatenation of segments and/or fi elds in a specifi ed order. Yes, this attri-bute is complex. The syntax for this is as follows:

<register assembly description> ::= attribute REGISTER_ASSEMBLY of <target> is <register assembly string> <semicolon> <register assembly string>::= <quote> <register assembly list> { <comma> <register assembly list> } <quote> <register assembly list>::= <reg or seg name> <left paren> <register assembly elements> <right paren> <register assembly elements>::= <left paren> <register element> <right paren> { <comma> <left paren> <register element> <right paren> } <register element> ::= <instance and options> | <fi eld and options> | <instance reference> | <selected segment element> | <boundary instance> | <using statement> <instance and options> ::= <instance defi nition> { <fi eld assign-ments> } <instance defi nition> ::= <instance ident> is [ PACKAGE <package hierarchy> <colon> ] <reg or seg name> <instance ident> ::= <segment ident> | <array ident> <segment ident> ::= <VHDL identifi er> <array ident>::= ARRAY <array segment ident> <left paren> <range> <right paren> <array segment ident>::= <VHDL identifi er> <fi eld assignments> ::= <fi eld value assignment> | <fi eld reset assignment> | <fi eld domain assignment> | <fi eld selection assignment> <fi eld value assignment> ::= [ <fi eld ident> <colon> ] <value assignment> <fi eld reset assignment> ::= [ <fi eld ident> <colon> ] <reset assignment> <fi eld domain assignment> ::= [ <fi eld ident> <colon> ] <domain assignment> <fi eld ident> ::= { <instance name> <period> } <fi eld name> <instance name> ::= <segment ident> | <array instances> <array instances> ::= <array segment ident> <bit list> <fi eld and options>::= <fi eld name> <fi eld length> { <fi eld options> } <instance reference> ::= <segment ident> | <array instance> <array instance> ::= <array segment ident> <left paren> <index> <right paren> <index> ::= <integer>

B 2013 BSDL Syntax Revisions

519

<selected segment element> ::= SELECTMUX <left paren> <selectable segment> <right paren> { <comma> <left paren> <selectable segment> <right paren> } <fi eld selection assignment> <selectable segment> ::= <instance and options> | <instance reference> <fi eld selection assignment> ::= <selection fi eld> <selection values> [ <broadcast fi eld> <broadcast values> ] <selection fi eld> ::= SELECTFIELD <left paren> <fi eld reference> <right paren> <fi eld reference> ::= { <instance reference> <period> } <fi eld name> <selection values> ::= SELECTVALUES <left paren> <segment selection> { <segment selection> } <right paren> <segment selection> ::= <left paren> <instance reference> <colon> <fi eld value> { <comma> <fi eld value> } <right paren> <fi eld value> ::= <mnemonic identifi er> | <binary pattern> | <hex pattern> | <decimal pattern> <broadcast fi eld> ::= BROADCASTFIELD <left paren> <fi eld reference> <right paren> <broadcast values> ::= BROADCASTVALUES <left paren> <broadcast selection> { <broadcast selection> } <right paren> <broadcast selection> ::= <left paren> <instance reference> { <comma> <instance reference> } <colon> <fi eld value> { <comma> <fi eld value> } <right paren> <boundary instance> ::= <segment ident> is [ PACKAGE <package hierarchy> <colon> ] < boundary segment name > <using statement>::= USING <package prefi x> <package prefi x> ::= <package hierarchy> | <minus sign> <package hierarchy>::= <user package name> { <period> <user pack-age name> }

The <register assembly elements> are ordered with the fi rst being closest to TDI and the last being closest to TDO. If the <reg or seg name> is that of a standard register (e.g., Device_ID) then the length must be what is specifi ed in the standard (e.g., 32) or what has been described before in a register access statement. In the case of the Boundary register, it must match either the length given in <boundary length stmt> or the minimum length given in an <assembled boundary length stmt>. Otherwise, the specifi ed length is used for a register that has a deferred length speci-fi cation [*]. For user registers specifi ed in a <package target> the length shall be the sum of the lengths of the non-excludable segments in the <register assembly>.

B.2 BSDL Syntax

520

In a <fi eld and options> segment, the <fi eld name> must be unique in any <reg-ister assembly list>. Also, all <segment ident> and <array segment ident> elements within a <register assembly list> must be unique within an entity or package. A <reg or seg name> in an <instance defi nition> must be defi ned in a <register fi eld list> or <register assembly list> contained in the current entity or package, or in a package the <package hierarchy> given by the most recent “USING” statement.

Between a SEGSEL (or SEGSTART 5 ) element and a SEGMUX element that are associated with the same segment <association name>, all register assembly ele-ments listed are excludable as a unit.

Between a SELECTMUX element and a SELECTFIELD element, all register assembly elements listed are members of a parallel group of segments, of which only one is selected by the SELECTVALUES element to drive out towards TDO. Optionally, following the selection elements there may be a BROADCASTFIELD and BROADCASTVALUES element pair that enumerate which of the parallel segments, receive TDI data in parallel for a given selection value. In both cases, all segments mentioned between SELECTMUX and SELECTFIELD must appear as selectable segments in the SELECTVALUE and BROADCASTVALUE lists.

When multiple <array ident> statements have the same <array segment ident> then all associated <range> specifi cation must not have any duplicated indices, and all indices must be present or implied within the total range specifi cation.

The defi nition of the <fi eld reference> register used in a SELECTFIELD or BROADCASTFIELD element must have a RESETVAL specifi cation, so the selected segment upon reset is known.

When the register being assembled is the Boundary register, then it must be com-posed only of instances of DOMCTRL, SEGSEL, SEGSTART or SEGMUX regis-ter fi elds, which are defi ned in the standard package STD_1149_1_2013 (see Sect. A.3 ), or defi ned <boundary segment name> elements defi ned found in a Boundary_Segment attribute (see Sect. A.2.4 ). Note that any excludable segment in a Boundary register must have a DOMCTRL and SEGSEL fi eld associated with that segment in the same register assembly list. This does not preclude having other such controls in (say) the Init_Data register, but these are duplicates. 6

Any excludable segments in the Init_Data register must be controlled by DOMCTRL and SEGSEL fi elds in the Init_Data register. All excludable seg-ments in a public TDR (standard or design-specifi c) must have DOMCTRL and SEGSEL fi elds in that same TDR, or, in another public TDR that is not the Boundary register. This means all such exclusion controls for public registers must be visible (public).

5 SEGSEL represents a 1-bit register cell that directly precedes an excludable segment, In the case where this bit exists in a different register, then SEGSTART, a zero-length segment indicator starts the excludable segment. All must have the same < association name > . 6 In effect, the duplicate bits are OR-ed with those in the Boundary register to control the power/exclusion mechanism. Thus, to exclude a segment, you should be aware of any duplicate bits else-where and manage them along with the bits in the Boundary register.

B 2013 BSDL Syntax Revisions

521

The <package hierarch> construct is used to point to a specifi c name (<mne-monic group name>, <reg or seg name>, or <boundary segment name>) to remove any ambiguity when there may be identical names a more than one hierarchical level. A <using statement> is available to shorten name references by being a prefi x prepended to a name. The “USING (-)” form erases an existing prefi x.

Note that the 2013 revision of BSDL can be used to describe an older compo-nent, but since the concept of domains and excludable segments were not supported before 2013, a register assembly for a pre-2013 component may not contain DOMCTRL, SEGSEL, SEGSTART or SEGMUX fi elds. This is known from the <component conformance> statement (see Sect. A.4 referring to a pre-2013 level of conformance.

B.2.9 Register Constraints Description

The register constraints attribute allows the description of register contents that should be avoided—for example, where two domain control cells that turn on power to two domains should not be both turned on at the same time (see example in Sect. 11.4.22 ) because the hardware itself cannot support this. Here is the register con-straints syntax:

<register constraints description> ::= attribute REGISTER_CONSTRAINTS of <target> is <constraints string> <semicolon> <constraints string>::= <quote> <constraints list> { <comma> <constraints list> } <quote> <constraints list>::= <constraint domain> <left paren> <constraint checks> <right paren> <constraint domain> ::= <reg or seg name> | entity | package <constraint checks>::= <left paren> <check expression> <right paren> <constraint severity> <information tag> { <comma> <left paren> <check expression> <right paren> <constraint severity> <information tag> } <constraint severity> ::= error | warning | info <check expression> ::= <short expression> | <binary expr> <short expression> ::= <nested expr> | <unary expr> | <fi eld reference> | <oper val> <nested expr> ::= <left paren> <check expression> <right paren> <unary expr> ::= <logical inv expr> | <bit-wise inv expr> | <one hot expr> <logical inv expr> ::= <logical inversion> <short expression> <bit-wise inv expr> ::= <bit-wise inversion> <short expression> <one hot expr> ::= <one hot> <nested expression> <binary expr> ::= <short expression> <binary operator> <check expression>

B.2 BSDL Syntax

522

<binary operator> ::= <exponentiation> | <multiplication> | <divi-sion> | <remainder> | <addition> | <subtraction> | <right shift> | <left shift> | <less than> | <greater than> | <equals> | <less than or equal> | <greater than or equal> | <not equals> | <bit-wise and> | <bit-wise xor> | <bit-wise or> | <logical and> | <logical or> <oper val> ::= <mnemonic pattern> | <binary pattern> | <hex pat-tern> | <decimal pattern> <mnemonic pattern> ::= [ [ PACKAGE <package hierarchy> <colon> ] <mnemonic group name> ] <left brace> <mnemonic identifi er> <right brace>

The logical expression formulation is a subset adopted from section Sect. 11.2 of SystemVerilog [ IEEE12a ].

The defi nition of <target> is found in Sect. A.2.6 . A <constraint domain> of PACKAGE or ENTITY must match the type of <target>. The <fi eld reference> must be a previously defi ned register or register fi eld, as provided by the standard (e.g., Boundary or ECID) or by a register access, register fi elds or register assembly defi nition. A <mnemonic pattern> must resolve to previously defi ned mnemonic value given in a register mnemonics defi nition.

A <check expression> must contain at least one <fi eld reference>. (For example, the expression “2 < 3” does not meet this requirement.) The fi eld length of a <fi eld reference> must be greater than zero. Operator meanings, precedence and symbols are given in below in Table A.1 . The logical value of zero if FALSE, and the logical value of a non-zero number is TRUE. Note a binary number with ‘x’ bits is consid-ered non-zero. Arithmetic operators do not operate on ‘x’ bits, only ‘1’ and ‘0’ bits are allowed in operands.

Operators of higher precedence (that is, lower precedence number) are evaluated before those of lower precedence. Operators of the same precedence are evaluated left-to-right.

B.2.10 Register and Power Port Association Description

These two new optional attributes are described together since they share some syntax defi nitions and rules of use. These attributes allow ports of an IC to have associated information that may be quite helpful during test debugging or defect diagnosis.

<register association description> ::= attribute REGISTER_ASSOCIATION of <target> is <register association string> <semicolon> <register association string>::= <quote> <register association list>

B 2013 BSDL Syntax Revisions

523

{ <comma> <register association list> } <quote> <register association list>::= <reg fi eld or instance> <colon> <association list> { <association list> } <reg fi eld or instance> ::= <fi eld or instance name> [ <left paren> < index > <right paren> ] <fi eld or instance name> ::= <extended fi eld name> | <segment ident> | <array segment ident> | <TDR> <association list> ::= <port list> | <info list> | <clock list> | <user list> | <unit> <port list> ::= port <port association list> <port association list> ::= <left paren> <port ID> { <comma> <port ID> } <right paren> <info list> ::= info <left paren> <information tag> { <comma> <information tag> } <right paren> <clock list> ::= sysclock <left paren> <port ID> { <comma> <port ID> } <right paren> <user list> ::= user <user list name> <left paren> <single or multi list> <right paren>

Table A.1 Constraint operator defi nitions

Precedence Operator token Operator Type (comments)

1 <logical inversion> <bit-wise inversion> <one hot>

! ~ One_hot

Logical Bit-wise Logical result, true if exactly one operand bit is ‘1’ (Binds to nested expression on its right)

2 <exponentiation> ** Arithmetic 3 <multiplication>

<division> <remainder>

* / %

Arithmetic

4 <addition> <subtraction>

+ −

Arithmetic

5 <left shift> <right shift>

<< >>

Arithmetic (Right operand is the number of shifts)

6 <left than> <greater than> <less than or equal> <greater than or equal>

< > <= =>

Arithmetic (Result is logical)

7 <equals> <not equal>

== !=

Bit-wise (Result is logical)

8 <bit-wise and> & Bit-wise 9 <bit-wise xor> ̂ Bit-wise 10 <bit-wise or> | Bit-wise 11 <logical and> && Logical 12 <logical or> || Logical

B.2 BSDL Syntax

524

<user list name> ::= <VHDL identifi er> <single or multi list> ::= <single word user list> | <multi-word user list> <single word user list> ::= <VHDL identifi er> { <comma> <VHDL iden-tifi er> } <multi-word user list> ::= <information tag> { <comma> <informa-tion tag> } <unit> ::= unit <left paren> <unit name> <unit defi nition> <right paren> <unit defi nition> ::= <left brace> <unit value> [ <unit scale> ]

[ <unit link> ] <right brace> <unit name> ::= <VHDL identifi er> <unit value> ::= <hex pattern> <unit scale> ::= <real> <unit link> ::= <information tag> <power port association description> ::= attribute POWER_PORT_ASSOCIATION of <entity target> is <power port association string> <semicolon> <power port association string>::= <quote> <power port association list> { <comma> <power port association list> } <quote> <power port association list>::= <power port id> <colon> <port association list> <power port id> ::= <port ID>

Any fi eld reference must be a previously defi ned register or register fi eld, as provided by the standard (e.g., Boundary or ECID) or by a register access, register fi elds or register assembly defi nition. A <fi eld or instance name> must appear only once in a <register association list>. The value of an integer <index> associated with a <fi eld name> must be less than the <fi eld length> of the register fi eld (see Sect. A.2.7). When an <index> is associated with a <array segment ident>, it must be a valid index into the <range> of an <array ident> described in a Register_Assembly attribute. An <index> can only be associated with a <power port id> when that <port ID> was defi ned as a bit_vector and the index is a valid member of the <range> of the <port ID>.

All <port ID> elements listed in a <port association list> must be previously defi ned in a <logical port description> (see Sect. A.4 ), and shall appear only once in that list.

An <association list> contains, within parenthesis, either a single entry which is associated with all of the bits contained in a <reg fi eld or instance>, or it must con-tain a comma-separated list of entries with length equal to the number of bits con-tained in the <reg fi eld or instance>, associated with those bits in TDI-to-TDO order.

Any <port ID> in a <clock list> must have been identifi ed as a system clock in a SYSCLOCK_REQUIREMENTS attribute (see Sect. A.2.5 ). Each <user list name> must be unique within a <register association list>.

B 2013 BSDL Syntax Revisions

525

A <unit> appearing in an <association list> allows the naming of a <unit value>, which is a <hex pattern> of 22 characters as defi ned in section Sect. 4.11 of IEEE Std 1451.0-2007 [ IEEE07 ]. Any <unit link> supplied must be a valid fi le (fi le://…) or Internet (http://…) URL locating a transducer electronic data sheet (TED) as defi ned in IEEE Std 1451.

A <power port id> must be a <port ID> in the <logical port description> with a <pin type> of POWER_POS, POWER_NEG, POWER_0 or VREF_IN.

B.3 The STD_1149_1_2013 Standard Package

The 2013 BSDL standard package has some changes from the previous (2001) ver-sion. The package comes in two sections, the “package” and then the “package body”. The 2013 package body contains cell descriptions that are very similar to the previous package body so to conserve space, refer to the 2001 package body seen in Sect. 2.6.1 for those cell descriptions.

The fi rst section in the standard package is essentially a set of data and type dec-larations. These were used to support VHDL compilers so that they could understand data structures in BSDL. There are additions that come with the 2013 version. These are shown next. Those statements that have been added by the 2013 revision are commented at the right side of the page.

-- STD_1149_1_2013 BSDL Package and Package Body -- -- source : IEEE Std 1149.1-2013, B.9 -- -- NOTE-Where fi gures from the standard are cited, -- the suffi x ‘c’ denotes a control cell, and ‘d’ -- denotes a data cell. -- package STD_1149_1_2013 is -- Give component conformance declaration. attribute COMPONENT_CONFORMANCE : string; -- 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;

B.3 The STD_1149_1_2013 Standard Package

526

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 θ) of ID_BITS; attribute IDCODE_REGISTER : ID_STRING; attribute USERCODE_REGISTER: ID_STRING; -- Give register declarations attribute REGISTER_ACCESS : string; attribute REGISTER_MNEMONICS : string; attribute REGISTER_FIELDS : string; attribute REGISTER_ASSEMBLY : string; attribute REGISTER_CONSTRAINTS : string; attribute POWER_PORT_ASSOCIATION : string; attribute REGISTER_ASSOCIATION : string; -- 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 deferred constants (see package body) constant BC_0 : CELL_INFO; constant BC_1 : CELL_INFO; constant BC_2 : CELL_INFO; constant BC_3 : CELL_INFO; constant BC_4 : CELL_INFO; constant BC_5 : CELL_INFO; -- BC_6 omitted in 2013 constant BC_7 : CELL_INFO; constant BC_8 : CELL_INFO; constant BC_9 : CELL_INFO; constant BC_10 : CELL_INFO; -- Boundary-scan register declarations attribute BOUNDARY_LENGTH : integer;

B 2013 BSDL Syntax Revisions

527

attribute BOUNDARY_REGISTER : string; attribute ASSEMBLED_BOUNDARY_LENGTH : array (0 to 1) of integer; -- added 2013 attribute BOUNDARY_SEGMENT : string; -- added 2013 -- Miscellaneous attribute PORT_GROUPING : string; attribute RUNBIST_EXECUTION : string; attribute INTEST_EXECUTION : string; attribute SYSCLOCK_REQUIREMENTS : string; -- added 2013 subtype BSDL_EXTENSION is string; attribute COMPLIANCE_PATTERNS : string; attribute DESIGN_WARNING : string; end STD_1149_1_2013; -- End of 1149.1-2013 Package

The standard package body follows here. The cell descriptions are substantially unchanged from 2001 (see Sect. 2.6.1 ). These are omitted for brevity.

package body STD_1149_1_2013 is --Standard boundary cells

… cell descriptions omitted … … the next two attributes added at 2013 …

attribute REGISTER_MNEMONICS of STD_1149_1_2013:package is "STD_MUX(Include (1) <chain segment is included>,"&

"Exclude (0) <chain segment not included>),"& "STD_POWER(On (1) <Domain is functionally on>, " & " Off (0) <Domain is functionally off>), " & "STD_DOMSET(Override (1) <Force domain ON>, " & "Normal (0) <Domain in normal mode>) ";

attribute REGISTER_FIELDS of STD_1149_1_2013:package is "DOMCTRL[1] ((DOMCTRL[1] IS (0) MON " &

" DEFAULT(STD_DOMSET(Normal)) " & " RESETVAL(STD_DOMSET(Normal))) "&

-- A reset type must be specifi ed where this -- is instantiated ")," & "SEGSEL[1] ((SEGSEL[1] IS (0) DELAYPO " &

" DEFAULT(STD_MUX(Exclude)) "& " RESETVAL(STD_MUX(Exclude)) "&

-- A reset type must be specifi ed where this -- is instantiated

" CAPTURES(STD_POWER(-)) ))," & "SEGMUX[0] ((SEGMUX [0] IS ()) )," & "SEGSTART[0] ((SEGSTART [0] IS ()) )"; end STD_1149_1_2013; -- End of IEEE STD 1149.1-2013

-- Package Body

B.3 The STD_1149_1_2013 Standard Package

528

B.4 User Package Syntax

The syntax for a user package is expanded to account for nesting of IP packages and register mnemonics, fi elds, assembly, constraints and association descriptions. The syntax below has comment in the right sides of lines that are added by the 2013 revision. (These comments are not part of the description.)

<user package> ::= <user package stmt> <user package body>

<user package stmt>::= package <user package name> is <standard use statement> { <extension declaration> } { <deferred constant> }

end <user package name> ; <user package body>::= package body <user package name> is

<standard use statement> { <use statement> } --added 2013 { <cell description constant> } { <register mnemonics description> } --added 2013 { <register fi elds description> } --added 2013 { <register constraints description> } --added 2013 { <register association description> } --added 2013 { <extension defi nition> } --added 2013 [ <design warning> ] --added 2013

end <user package name> ;

<user package name>::= <VHDL identifi er> <deferred constant>::= constant <cell name> : CELL_INFO; <cell name>::= <VHDL identifi er> <cell description constant>::= constant <cell name> : CELL_INFO := (

<capture descriptor list> ) ; <cell name>::= <VHDL identifi er> <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

The various register descriptions used above are defi ned in this Appendix. The addition of a design warning inside a user package will allow IP providers to alert their users to any special considerations their IP requires.

B 2013 BSDL Syntax Revisions

529

B.5 Modifi ed 1149.6 Extention Attribute Syntax

The 1149.6 extension contains syntax that defi nes 1149.6 attributes. This syntax may appear in the extension area of an entity (chip) description, or in the extension area of a user package. Note that the two extensions differ in that for an entity exten-sion, the <AIO port link behavior description> syntax may not appear, and in a user package extension, a <AIO optional pin behavior description> may not appear. Both of these items appear in the following syntax description since they make use of some common elements. Three of the fi ve statements are identical to the 2003 version and the comments point to their defi nition in Sect. A.6 .

<AIO Extension> ::= <AIO component conformance statement> (see Sect. A.6 ) [<AIO optional EXTEST_PULSE description>] (see Sect. A.6 ) [<AIO optional EXTEST_TRAIN description>] (see Sect. A.6 )

[<AIO optional pin behavior description>] (see Sect. A.5.1) [<AIO port link behavior description>] (see Sect. A.5.2)

The value of a conformance identifi cation has been expanded in 2015 to have two values: STD_1149_6_2003 and STD_1149_6_2015 . Note that when confor-mance is claimed for the 2015 level, then the conformance attribute of the entity BSDL must be STD_1149_1_2013 or later.

There is a restriction for Extest_Pulse descriptions that appear in a user package; the clock specifi cation refers to a time only, not a <port ID>, since ports are not known at the package level.

B.5.1 Pin Behavior Description (Entity)

AIO Pin behavior at the entity level is described by an AIO_Pin_Behavior attribute. The documentation of the AC parameters of a pin are given in Sect. A.5.3.

Note that a pin behavior description may reference “port links”, which are described by a port link behavior description (see Sect. A.5.2) in a package refer-enced in a BSDL use statement. Here is the syntax for pin behavior description.

<AIO optional pin behavior description> :: = attribute AIO_Pin_Behavior of < entity target > is < quote > <AC entity info list> < quote > < semicolon > <AC entity info list> ::= <entity pin info> { <semicolon> <entity pin info> } <entity pin info> ::= <AC port list> < colon > [ <AC/DC select cell> ]

<AC parameters> <AC port list> ::= <AC ports> { < comma > <AC ports> } <AC ports> ::= <AC port> [ <input cell list> ]

B.5 Modifi ed 1149.6 Extention Attribute Syntax

530

<AC port> ::= < port name > | <subscripted port name > | <ranged port name>

<subscripted port name> ::= < port name > < left paren > < intege r> < right paren > <ranged port name> ::= < port name > < left paren > < range > < right paren > <input cell list> ::= < left bracket > <cell number list> < right bracket > <cell number list> ::= <cell reference> { < comma > < cell number > } <cell reference> ::= [ < boundary segment name > < colon > ] < cell number > <AC/DC select cell> ::= AC_Select <equal> <cell reference> <AC parameters> ::= <AC parameter list> | <AC port link list>

NOTE— The defi nition of <AC parameter list> is given in A.5.3.

<AC port link list> ::= [ PACKAGE < package hierarchy > <colon> ] <port link reference list>

<port link reference list> ::= <port link reference> { < comma > <port link reference> }

<port link reference> ::= <port link name ref> [ <input threshold> ]

NOTE— The <input threshold> element is defi ned in A.5.3

<port link name ref> ::= <port link name> | <subscripted port link name> | <ranged port link name> <subscripted port link name> ::= <port link name> < left paren > < integer > < right paren > <ranged port link name> ::= <port link name> < left paren > < range > < right paren > <port link name> ::= < VHDL identifi er >

See discussion about Pin Behavior Description in Sect. 12.3.5 .

B.5.2 Port Link Behavior Description (Package)

AIO Port Link behavior at the package level is described by an AIO_Port_Behavior attribute. The documentation of the AC parameters of a port link is given in Sect. A.5.3. Here is the syntax for port link behavior description.

<AIO port link behavior description> :: = attribute AIO_Port_Behavior of <package target> is <quote> <port link declaration list > <AC package info list> <quote> <semicolon> <port link declaration list>::= port_link_list <left paren> <port link declaration> { <semicolon> <port link declaration> } <right paren> <semicolon> <port link declaration> ::= <port links> <colon> <port link type>

<port dimension>

B 2013 BSDL Syntax Revisions

531

<port links> ::= <port link name> { <comma> <port link name> } <port link name> ::= <VHDL identifi er> <port link type> ::= in | buffer | out | inout <AC package info list> ::= <package pin info>

{ <semicolon> <package pin info> } <package pin info> ::= <port link list> <colon> <AC parameter list>

NOTE— The defi nition of <AC parameter list> is given in Sect. A.5.3.

<port link list> ::= <port link> { <comma> <port link> } <port link> ::= <port link name> | <subscripted port link name> |

<ranged port link name>

NOTE – The defi nitions of <port link name>, <subscripted port link name> and <ranged port link name> were given above in Sect. A.5.1.

See discussion about Port Behavior Description in Sect. 12.3.6 .

B.5.3 AC Parameters Description

AC parameters document the characteristics of AC pin drivers or test receivers that may be important to board test debugging and effi cacy, and diagnostic processing. In the pre-2015 years, we did not have this information in machine readable form and if a test engineer was having trouble debugging a test, it may have been due to a mismatch of AC parameters that he might have found out about by reading some obscure data sheet. Now these are brought out into view in BSDL, and in principle, some debugging can even be enhanced automatically, with software able to look at drivers and attached receivers and see if any problematic AC parameter mismatches are possible. This is even more important as we see more driver/receiver parameters than are programmable—are they programmed to be compatible?

AC parameter syntax appears below. Note the numerous keywords—these are explained in Sect. 12.3.2 .

<AC parameter list> ::= [ <LP time constant> ] [ <HP time constant> ] <voltage parameters> [ No_pulse ]

<voltage parameters> ::= <voltage parm> <voltage parm> [ <voltage parm> <voltage parm> ]

<voltage parm> ::= <output VCM> | <output VPP> | <input threshold> | <input hysteresis>

<LP time constant> ::= <LP key> < equal> <time constant> <LP key> ::= LP_time | edge_detect_time <HP time constant> ::= <HP key> <equal> <time constant> [ <cap spec> ]

[ <detection modifi er> ] <HP key> ::= HP_Time | coupling_time <time constant> ::= <real> <cap spec> ::= On_Chip | On_Chip_Programmable | On_Chip_AC | On_Chip_AC_Programmable | <group on-chip>

B.5 Modifi ed 1149.6 Extention Attribute Syntax

532

<group on-chip> ::= <group keyword> <left paren> <group name> <right paren> <group keyword> ::= On_Chip_Bus_Programmable |

On_Chip_AC_Bus_Programmable <detection modifi er> ::= Detect_EXTEST_High | Detect_EXTEST_Low |

Detect_EXTEST_Both | Detect_EXTEST_Both_Grouped <output VCM> ::= AIO_VCM <equal> <Volt choice> <Volt choice> ::= <millivolts> | programmable | <group programmable> <group programmable> ::= bus_programmable <left paren>

<group name> <right paren> <output VPP> ::= AIO_VPP <equal> <Volt choice> <input threshold> ::= AIO_VTH <equal> <VTH choice> <VTH choice> ::= <millivolts> | <source pin> | programmable |

<group programmable> | AIO_VCM | external <input hysteresis> ::= AIO_VHys t <equal> <Volt choice> <millivolts> ::= <integer> | <negative integer> <source pin> ::= <port_ID> <group name> ::= <VHDL identifi er>

B 2013 BSDL Syntax Revisions

533© Springer International Publishing Switzerland 2016 K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5

References

[Agra88] “Test Generation for VLSI Chips”, V. D. Agrawal and S. C. Seth, IEEE Computer Society Press , Los Alamitos CA, 1988

[Albe01] “A Practical Guide to Combining ICT and Boundary-Scan Testing”, A. Albee, Proceedings, International Test Conference , Baltimore MD, pp 487–494, Oct 2001

[AMD91] “Am29030 and Am29035 Microprocessors User's Manual and Data Sheet”, Advanced Micro Devices, Inc. 1991

[Avra87] “A VHSIC ETM-Bus Compatible Test and Maintenance Interface”, L. Avra, Proceedings, International Test Conference , pp 964–971, Washington DC, 1987

[Ball89] “Board-Level Boundary-Scan: Regaining Observability with an Additional IC”, W. D. Ballew and L. Streb, Proceedings, International Test Conference , pp 182–189, Washington DC, Aug 1989

[Barr00] “End-to-End Testing for Boards and Systems Using Boundary-Scan”, R. Barr and E. Wallace, Proceedings, International Test Conference , Atlantic City NJ, pp 585–591, Oct 2000

[Been85] “Systematic and Structured Methods of Digital Board Testing”, F. P. M. Beenker, Proceedings, International Test Conference , pp 380–385, Philadelphia, Nov 1985

[Blee93] “Boundary-Scan Test: A Practical Approach”, H. Bleeker, P. van den Eijnden and F. de Jong, Kluwer Academic Publishers, Norwell MA, 1993

[Breu88] “A Test and Maintenance Controller for a Module Containing Testable Chips”, M. A. Breuer and J. C. Lien, Proceedings, International Test Conference , Washington DC, pp 502–513, 1988

[Bruc91] “Implementing 1149.1 on CMOS Microprocessors”, W. C. Bruce, M. G. Gallup, G. Giles and T. Munns, Proceedings, International Test Conference , Nashville TN, pp 879–886, Oct 1991

[Bull87] “Designing SMT Boards for In-Circuit Testability”, M. Bullock, Proceedings, International Test Conference , pp 606–613, Washington DC, Sept 1987

[Bush84] “Measuring Thermal Rises Due to Digital Device Overdriving”, G. S. Bushanam et al, Proceedings, International Test Conference , pp 400–407, Philadelphia PA. Oct 1984

[Cald92] “Is IEEE 1149.1 Boundary-Scan Cost Effective: A Simple Case Study”, B. Caldwell, T. Langford, Proceedings, International Test Conference , pp 106–109, Baltimore MD, Sept 1992

[Chil91] “Using Boundary-Scan Description Language in Design”, D. Chiles and J. DeJaco, Proceedings, International Test Conference , pp 865–868, Nashville TN. Oct 1991

[Chun01] “AC-JTAG: Empowering JTAG Beyond Testing DC Nets”, S. Chung, S. Baeg, Proceedings, International Test Conference , pp 30–37, Baltimore MD, Oct 2001

534

[Clar10] “Solutions for Undetected Shorts on IEEE 1149.1 Self-Monitoring Pins”, Clark, C. J., Dubberke, D., Parker, K. P., Tuthill, B., Proceedings, International Test Conference , Paper 19.1, Austin TX, Oct 2010

[Cogs02] “A Structured Graphical Tool for Analyzing Boundary-Scan Violations”, M. Cogswell, S. Mardhani, K. Melocco and H. Arora, Proceedings, International Test Conference , Baltimore MD, 755–762, Oct 2002

[Coom95] “Printed Circuits Handbook, 5 th Edition”, C. F. Coombs, Editor, McGraw-Hill, New York, 2001

[Covi92] “Boundary-Scan Testing with ATEs”, R. R. Covington, R. C. Goodwin, T. A. Reed, Proceedings, ATE&I Conference , pp 32–37, Anaheim CA. Jan 1992

[Croo79] “Analog In-Circuit Component Measurements: Problems and Solutions”, D. T. Crook, Hewlett-Packard Journal , vol 30, No. 3, March 1979

[Crou94] “Low Power Mode and IEEE 1149.1 Compliance: A Low Power Solution”, A. L. Crouch, R. Ramus, C. Maunder, Proceedings, International Test Conference , pp 660–669, Washington DC, Oct 1994

[Dahb89] “An Optimal Test Sequence for the JTAG Boundary-Scan Controller”, A. Dahbura, M. U. Uyar and C. W. Yau, Proceedings, International Test Conference , Washington DC, pp 55–62, Aug 1989

[DeJo91] “Testing the Integrity of the Boundary-Scan Test Infrastructure”, F. de Jong and F. van der Heyden, Proceedings, International Test Conference , Nashville TN, pp 106–112, Oct 1991

[DeJo00] “Power Pin Testing: Making the Test Coverage Complete”, F. de Jong and R. Schuttert, Proceedings, International Test Conference , Atlantic City NJ, pp 575–584, Oct 2000

[DeJo01] “Testing and Programming Flash Memories on Assemblies During High Volume Production”, F. de Jong, A. S. Biewenga, D. van Geest and T. F. Waayers, Proceedings, International Test Conference , Baltimore MD, 470–479, Oct 2001

[Derv88] “Using Scan Technology for Debug and Diagnostics in a Workstation Environment”, B. I. Dervisoglu, Proceedings, International Test Conference , Washington DC, pp 976–986, 1988

[Dubb08] “Solving In-Circuit Defect Coverage Holes with a Novel Boundary-Scan Application”, D. Dubberke, J. J. Grealish, B. van Dick, Proceedings, International Test Conference , paper 11.2, Santa Clara, CA, Oct 2008

[EDIF91] “EDIF Test Technical Subcommittee Test Extension”, Version 2 0 32, EDIF Test Technical Subcommittee , Oct 1991

[Eklo01] “Unsafe Board States During PC-Based Boundary-Scan Testing”, B. Eklow, R. Sedmak and D. Singletary, Proceedings, International Test Conference , Baltimore MD, pp 615–623, Oct 2001

[Eklo02] “IEEE P1149.6: A Boundary-Scan Standard for Advanced Digital Networks”, B. Eklow, C. F. Barhart, K. P. Parker, Proceedings, International Test Conference , pp 1056–1065, Baltimore MD, Oct 2002

[Eklo05] "An update on IEEE 1149.6 - successes and issues", B. Eklow, Proceedings, International Test Conference, Austin TX, Nov 2005

[Fasa89] “ASIC Testing in a Board/System Environment”, F. P. Fasang, IEEE Custom Integrated Circuits Conference , New York NY, pp 22.4.1–22.4.4, 1989

[Fout06] “Automation of IEEE 1149.6 Boundary Scan Synthesis in an ASIC Methodology”, B. Foutz, V. Chickermane, B. Li, H. Linzer, G. Kunzelman, 15 th Asian Test Symposium , Fukuoka Japan, Nov 2006

[Gall90] “The Testability Features of the 68040”, M. Gallup et al, Proceedings, International Test Conference , pp 749–757, Washington DC, Sept 1990

[Gree93] “Benefi ts of Boundary-Scan to In-Circuit Test”, D. A. Greene, Proceedings, International Test Conference , p 263, Baltimore MD, Oct 1993

[Gols00] “Test and On-Line Debug Capabilities of IEEE Std 1149.1 in UltraSparc(TM)-III Microprocessor”, F. Golshan, Proceedings, International Test Conference , Atlantic City NJ, pp 141–150, Oct 2000

References

535

[Hall89] “Prototype Testing Simplifi ed by Scannable Buffers and Latches”, A. Halliday, G. Young and A. Crouch, Proceedings, International Test Conference , pp 174–181, Washington DC, Aug 1989

[Hans89a] “The Impact of Boundary-Scan on Board Test Strategies”, P. Hansen, Proceedings, ATE&I Conference , Boston MA. pp 35–40, June 1989

[Hans89b] “Testing Conventional Logic and Memory Clusters Using Boundary-Scan Devices as Virtual ATE Channels”, P. Hansen, Proceedings, International Test Conference , Washington DC, pp 166–173, Aug 1989

[Harr01] “Hierarchical Boundary-Scan: A Scan Chip-Set Solution”, S. Harrison, G. Noeninckx, P. Horwood and P. Collins, Proceedings, International Test Conference , Baltimore MD, pp 480–486, Oct 2001

[Hawk85] “Electrical Characteristics and Testing Considerations for Gate Oxide Shorts in CMOS ICs”, C. F. Hawkins and J. M. Soden, Proceedings, International Test Conference , pp 544–555, Philadelphia, Nov 1985

[Hill92] “Boundary-Scan Testing for Multichip Modules”, S. C. Hilla, Proceedings, International Test Conference , pp 224–231, Baltimore MD, Sept 1992

[Hird02] “Test Coverage: What Does It Mean When a Board Test Passes?”, K. Hird, K. P. Parker and B. Follis, Proceedings, International Test Conference , Baltimore MD, 1066–1074, Oct 2002

[Hewl85] “SAFEGUARD In-Circuit, a Description of HP's Safe Implementation of Digital In-Circuit Test”, Product Note 3065-2 , Hewlett-Packard Manufacturing Test Division, Loveland CO. Sept 1985

[Huan97] “Analog Fault Diagnosis for Unpowered Circuit Boards”, J. L. Huang and K. T. Cheng, Proceedings, International Test Conference , pp 640–648, Washington DC, Nov 1997

[IEEE90] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard 1149.1–1990, IEEE Standards Board , 345 East 47th St. New York NY 10017, May 1990

[IEEE92] “Extended Digital Serial Subset”, Proposed IEEE Standard P1149.2/D0.2, IEEE Standards Board , 345 East 47th St. New York NY 10017, Feb 1992

[IEEE93a] “IEEE Standard 1149.1 Draft Supplement”, IEEE Standard 1149.1a-1993, IEEE Standards Board , 345 East 47thSt. New York NY 10017, 1993 (Now included in [IEEE01])

[IEEE93b] “IEEE Standard VHDL Language Reference”, IEEE Standard 1076-1987, IEEE Standards Board , 345 East 47th St. New York NY 10017, 1993

[IEEE94] “IEEE Standard 1149.1 Draft Supplement”, IEEE Standard 1149.1b-1994, IEEE Standards Board , 345 East 47thSt. New York NY 10017, 1994 (Now included in [IEEE01])

[IEEE95] “IEEE Standard Module Test and Maintenance (MTM) Bus Protocol”, IEEE Standard 1149.5-1995, IEEE Standards Board , 345 East 47th St. New York NY 10017, 1995

[IEEE99] “IEEE Standard for a Mixed Signal Test Bus”, IEEE Standard 1149.4-1999, IEEE Standards Board , 345 East 47th St. New York NY 10017, 1999

[IEEE01] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard 1149.1-2001, IEEE Standards Board , 345 East 47th St. New York NY 10017, 2001

[IEEE02] “IEEE Standard for In-System Confi guration of Programmable Devices”, IEEE Standard 1532-2002, IEEE Standards Board , 345 East 47th St. New York NY 10017, 2003

[IEEE03] “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”, IEEE Standard 1149.6-2003, IEEE Standards Board , 345 East 47th St. New York NY 10017, 2003

[IEEE07] “IEEE Standard for a Smart Transducer Interface for Sensors and Actuators—Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats”, IEEE Standard 1451.0-2007 , IEEE-SA Standards Board, 3 Park Avenue, New York, NY 10016-5997, 2007

References

536

[IEEE12] “IEEE Standard for Boundary-Scan-Based Stimulus of Interconnections to Passive and/or Active Components”, IEEE Standard 1149.8.1-2012, IEEE-SA Standards Board , 3 Park Avenue, New York, NY 10016-5997, 2012

[IEEE12a] “IEEE Standard for SystemVerilog--Unifi ed Hardware Design, Specifi cation, and Verifi cation Language”, IEEE Standard 1800-2012 , IEEE-SA Standards Board, 3 Park Avenue, New York, NY 10016-5997, 2012

[IEEE13] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard 1149.1–2013, IEEE Standards Board , 3 Park Avenue, New York NY 10016-5997, 2013

[IEEE15] “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”, IEEE Standard 1149.6-2015, IEEE Standards Board , 345 East 47th St. New York NY 10017, 2015

[Inte91] “Intel486 DX Microprocessor Data Book”, Intel Corporation, June 1991 [Jaco03] “The In-System Confi guration Handbook: A Designer’s Guide to ISC”, N. Jacobson,

Kluwer Academic Publishers, Norwell MA, (to appear 2003) [Jarw89] “A Unifi ed Theory for Designing Optimal Test Generation and Diagnosis Algorithms

for Board Interconnects”, N. Jarwala and C. W. Yau, Proceedings, International Test Conference , pp 71–77, Washington DC, Aug 1989

[Jarw94] “Designing ‘Dual Personality’ IEEE 1149.1 Compliant Multi-Chip Modules”, N. Jarwala, Proceedings, International Test Conference , pp 446–455, Washington DC, Oct 1994

[JEDE86] “Standard Manufacturer's Identifi cation Code”, Joint Electron Device Engineering Council , JEDEC Publication 106-A, Washington DC, 1986

[Jose93] “Test Features of the HP PA7100LC Processor”, D. D. Josephson, D. J. Dixon and B. J. Arnold, Proceedings, International Test Conference , pp 764–772, Baltimore MD, Oct 1993

[Kaji92] “Practical Test Generation with IEEE 1149.1 Boundary-Scan”, H. Kajitani, H. Sato, H. Saito and S. Oresjo, Proceedings, ATE&I Conference , pp 10–17, Anaheim CA. Jan 1992

[Kaut74] “Testing of Faults in Wiring Interconnects”, W. K. Kautz, IEEE Transactions on Computers , vol C-23, No. 4, pp 358–363, April 1974

[Ke96] “Backplane Interconnect Test in a Boundary-Scan Environment”, W. Ke, Proceedings, International Test Conference , Washington DC, pp 717–724, Oct 1996

[Kim01] “Frequency Detection-Based Boundary-Scan Testing of AC Coupled Nets”, Y. Kim, B. Lai, K. P. Parker, J. Rearick, Proceedings, International Test Conference , pp 46–53, Baltimore MD, Oct 2001

[Kris02] “Improved Digital I/O Ports Enhance Testability of Interconnections”, A. Kristof, Proceedings, International Test Conference , Baltimore MD, 763–772, Oct 2002

[Lage89] “Testing Multiple Power Connections with Boundary-Scan”, D. van de Lagemaat, Proceedings, European Test Conference , pp 127–130, Paris Fr., April 1989

[Lang93] “Utilizing Boundary-Scan to Implement BIST”, T. Langford, Proceedings, International Test Conference , pp 167–173, Baltimore MD, Oct 1993

[Lavo00] “A Good Excuse for Reuse: 'Open' TAP Controller Design”, D. Lavo, Proceedings, International Test Conference , Atlantic City NJ, pp 1090–1099, Oct 2000

[Lefe90] “Functional Test and Diagnosis: A Proposed JTAG Sample Mode Scan Tester”, M. F. Lefebvre, Proceedings, International Test Conference , pp 294–303, Washington DC, Sept 1990

[Lofs96a] “A Demonstration IC for the P1149.4 Mixed-Signal Test Standard”, K. Lofstrom, Proceedings, International Test Conference , pp 92–98, Washington DC, Oct 1996

[Lofs96b] “Early Capture for Boundary-Scan Timing Measurements”, K. Lofstrom, Proceedings, International Test Conference , pp 417–422, Washington DC, Oct 1996

[Liu91] “Testing and Diagnosis of Analog Circuits and Systems”, R. Liu, Van Nostrand Reinhold, New York, 1991

References

537

[Maun87] “Boundary-Scan — A Framework for Structured Design for Test”, C. M. Maunder and F. P. M. Beenker, Proceedings, International Test Conference , pp 714–723, Washington DC, Sept 1987

[Maun90] “The Test Access Port and Boundary-Scan Architecture”, C. M. Maunder and R. E. Tulloss, IEEE Computer Society Press , Los Alamitos CA, Sept 1990

[McDe98a] “Limited Access Testing: Ability and Requirements”, J. McDermid, Proceedings, NEPCON 1998 , Anaheim CA, Feb 1998

[McDe98b] “Solving Limited Access Constraints in ICT”, J. McDermid, Electronics Engineer , July 1998

[McDe98c] “Limited Access Testing: 1149.4 Instrumentation and Methods”, J. McDermid, Proceedings, International Test Conference , Washington DC, Oct 1998

[Milo95] “Success with Boundary-Scan, A Case Study”, P. Milo, Evaluation Engineering , pp 72–74, Feb 1995

[Muri90] “Integrating Boundary-Scan Test into an ASIC Design Flow”, M. Muris, Proceedings, International Test Conference , pp 472–477, Washington DC, Sept 1990

[Muri93] “Using Boundary-Scan to Test Random Access Memory Clusters”, M. Muris and A. Biewenga, Proceedings, International Test Conference , pp 174–179, Baltimore MD, Oct 1993

[Nade95] “A New Hardware Fault Insertion Scheme for System Diagnostics Verifi cation”, B. Nadeau-Dostie, H. Hulvershorn and S. M. I. Adham, Proceedings, International Test Conference , pp 994–1002, Washington DC, Oct 1995

[Nadi77] “Signature Analysis - Concepts, Examples and Guidelines”, H. J. Nadig, Hewlett- Packard Journal, pp 15–21, May 1977

[Norr08] “Augmenting Boundary-Scan Tests for Enhanced Defect Coverage”, D. Norrgard and K.P. Parker, Proceedings International Test Conference , paper 11.3, Oct 2008

[Nuri97a] “The Trend of Technology and Standardization in Boundary-Scan Test Technology”, K. Nuriya, K. Hirayama, K. P. Parker, and M. Kawai, Journal of Japan Institute for Interconnecting and Packaging Electronic Circuits , Vol. 12, No. 1, pp 4–5, Jan 1997 (In Japanese)

[Nuri97b] “Moving Towards 100% Manufacturing Defect Coverage for Mixed-Signal Boards”, K. Nuriya, A. Kukutsu, A. Matsuzawa, K. Hirayama, and K. P. Parker, Nikkei Electronics No. 685, pp 183–198, March 1997 [In Japanese]

[Oakl00] “Considerations for Implementing IEEE 1149.1 on System-on-a-Chip Integrated Circuits”, S. Oakland, Proceedings, International Test Conference , Atlantic City NJ, pp 628–637, Oct 2000

[Ores92] “Board Test Issues when Implementing Boundary-Scan IEEE 1149.1”, S. Oresjo and J. Stoltman, Proceedings, ATE&I Conference , pp 207–213, Anaheim CA. Jan 1992

[Osse99] “The 1149.4 Mixed-Signal Test Bus”, A. Osseiran Ed., Kluwer Academic Publishers, Norwell MA, 1999

[Park87] “Integrating Design and Test: Using CAE Tools for ATE Programming”, K. P. Parker, IEEE Computer Society Press , Los Alamitos CA, 1987

[Park89] “The Impact of Boundary-Scan on Board Test”, K. P. Parker, IEEE Design and Test of Computers , vol 6, pp 18–30, August 1989

[Park90a] “Production Board Testing in a Boundary-Scan Environment”, K. P. Parker, Proceedings, ATE&I Conference , Anaheim CA. pp 11–18, Jan 1990

[Park90b] “A Language for Describing Boundary-Scan Devices”, K. P. Parker and S. Oresjo, Proceedings, International Test Conference , pp 222–234, Washington DC, Sept 1990

[Park91] “A Language for Describing Boundary-Scan Devices”, K. P. Parker and S. Oresjo, Journal of Electronic Testing; Theory and Applications , vol 2, no. 1, pp 43–75, March 1991

[Park93] “Structure and Metrology for an Analog Testability Bus”, K. P. Parker, J. E. McDermid, S. Oresjo, Proceedings, International Test Conference , pp 309–322, Baltimore MD, Oct 1993

References

538

[Park97] “Design, Fabrication and Use of Mixed-Signal IC Testability Structures”, K. P. Parker, J. E. McDermid, R. A. Browen, K. Nuria, K. Hirayama, A. Matsuzawa, Proceedings, International Test Conference , pp 489–498, Washington DC, Nov 1997

[Park00] “System Issues with Boundary-Scan Board Test”, K. P. Parker, Proceedings, International Test Conference , pp 724–728, Atlantic City NJ, Oct 2000

[Park03] "Defect Coverage of Boundary-Scan Tests: What does it mean when a Boundary-Scan Test Passes?", Parker, K. P., Proceedings, International Test Conference , Charlotte NC, Sep 2003

[Park04] “A New Probing Technique for High-Speed/High-Density Printed Circuit Boards”, Parker, K. P., Proceedings, International Test Conference , paper 13.1, Charlotte NC, Oct 2004

[Park05] "The Effects of Defects on High-Speed Boards", Parker, K. P., Proceedings, International Test Conference , Austin TX, Nov 2005

[Park05a] “Bead Probes in Practice”, Parker, K. P., Proceedings, International Test Conference, Austin TX, Nov 2005

[Park08] "Boundary-Scan Testing of Power/Ground Pins", Parker, K. P. and Jacobson, N. G., Proceedings, International Test Conference , Santa Clara CA, Oct 2008

[Park10] “Surviving State Disruptions Caused by Test: the “Lobotomy Problem”, Parker, K. P., Proceedings, International Test Conference , paper 19.2, Austin TX, Oct 2010

[Park11] “Surviving State Disruptions Caused by Test: A Case Study”, Parker, K. P., Kameyama, S., Dubberke, D., Proceedings, International Test Conference , Paper 5.2, Anaheim CA, Sept 2011

[Park12] “Capacitive Sensing Testability in Complex Memory Devices”, Parker, K. P., Proceedings, International Test Conference , Paper 13.1, Anaheim CA, Nov 2012

[Poss91] “A Design-For-Testability Architecture for Multichip Modules”, K. E. Posse, Proceedings, International Test Conference , pp 113–121, Nashville TN, Oct 1991

[Pyro95] “Implementing 1149.1 in the PowerPC TM RISC Microprocessor Family”, C. Pyron and W. C. Bruce, Proceedings, International Test Conference , pp 844–850, Washington DC, Oct 1995

[Raym95] “Algorithmic Extraction of BSDL from 1149.1-Compliant Sample ICs”, D. W. Raymond, D. E. Wedge, P. J. Stringer, H. W. Ng, S. T. Jennings, C. T. Pynn, W. Soule, Proceedings, International Test Conference , pp 561–568, Washington DC, Oct 1995

[Reed95] “Improving Board and System Test: A Proposal to Integrate Boundary-Scan and I DDQ ”, D. Reed, J. Doege and A. Rubio, Proceedings, International Test Conference , pp 577–585, Washington DC, Oct 1995

[Robi83] “Investigation of Potential Damage Resulting from Digital In-Circuit Testing”, R. Robinson, Proceedings, ATE East Conference , Boston MA. Jan 1983

[Robi90] “Interconnect Testing of Boards with Partial Boundary-Scan”, G. D Robinson, J. G. Deshayes, Proceedings, International Test Conference , pp 572–581, Washington DC, Sept 1990

[Robi93a] “Technology-Independent Boundary-Scan Synthesis (Design Flow Issues)”, M. F. Robinson, Proceedings, European Design Automation Conference , Hamburg Germany, Sept 1993

[Robi93b] “Technology-Independent Boundary-Scan Synthesis (Technology and Physical Issues)”, M. F. Robinson, F. Mailhot and J. Konsevich, Proceedings, International Test Conference , pp 157–166, Baltimore MD, Oct 1993

[Shar92] “Test Generation for Structural Testing with Boundary-Scan”, R. Sharma, Proceedings, ATE&I Conference , pp 194–205, Anaheim CA. Jan 1992

[Sing97] “A Symbolic Simulation-Based ANSI/IEEE Std 1149.1 Compliance Checker and BSDL Generator”, H. Singh, G. Patankar, J. Beausang, Proceedings, International Test Conference , pp 256–264, Washington DC, Nov 1997

[Sobo82] “The Effects of Backdriving Digital Integrated Circuits During In-Circuit Testing”, L. J. Sobotka, Proceedings, International Test Conference , pp 269–286, Philadelphia PA. Oct 1982

References

539

[Stan02] “An Implementation of IEEE 1149.1 to Avoid Timing Violations and Other Practical In-compliance Improvements”, D. Stang and R. Dandapani, Proceedings, International Test Conference , Baltimore MD, 746–753, Oct 2002

[Sunt95] “The P1149.4 Mixed-Signal Test Bus: Costs and Benefi ts”, Proceedings, International Test Conference , pp 444–450, Washington DC, Oct 1995

[Sunt96] “Cost/benefi t Analysis of the P1149.4 Mixed-Signal Test Bus”, S. Sunter, IEEE Proceedings, Circuits, Devices, and Systems , December 1996, pp 393–398.

[Sunt01] “A General Purpose 1149.4 IC with HF Analog Test Capabilities”, S. Sunter, K. Filliter, J. Woo, P. McHugh, Proceedings, International Test Conference , Baltimore MD, Oct. 2001, pp 38–45

[Sunt02] “Complete, Contactless I/O Testing - Reaching the Boundary in Minimizing Digital IC Testing Cost”, S. Sunter, B. Nadeau-Dostie, Proceedings, International Test Conference , Baltimore MD, Oct 2002

[Sunt09] "Testing Bridges to Nowhere - Combining Boundary-Scan and Capacitive Sensing", Sunter, S. and Parker, K. P., Proceedings, International Test Conference , Austin TX, Nov 2009

[Swee88] “JTAG Boundary-Scan: Diagnosing Module Level Functional Failures”, J. Sweeney, National Communications Conference , 1988, pp 1801–1804

[Swen86] “Thermal Analysis of Backdriven Output Transistors”, R. L. Swent and M. J. Ward, Proceedings , International Test Conference , pp 295–303, Washington DC, Sept 1986

[Tege96] “Opens Board Test Coverage: When is 99% Really 40%?”, M. V. Tegethoff, K. P. Parker and K. Lee, Proceedings, International Test Conference , pp 333–339, Washington DC, Oct 1996

[Tell52] “A General Network Theorem with Applications”, B. D. H. Tellegen, Phillips Research Report No. 7, pp 259–269, 1952

[Texa90] “ASSET Diagnostic System Overview”, (Literature SATT113), Texas Instruments, Inc., 1990

[Texa91a] “54BCT8244/74BCT8244 Octal Buffer with Boundary-Scan”, Texas Instruments, Inc., 1991

[Texa91b] “54BCT8374/74BCT8374 Octal D Flip-Flop with Boundary-Scan”, Texas Instruments, Inc., 1991

[That93] “Towards a Test Standard for Board and System Level Mixed-Signal Interconnects”, C. W. Thatcher and R. E. Tulloss, Proceedings, International Test Conference , pp 300–308, Baltimore MD, Oct 1993

[USP93] “Powered Testing of Mixed Conventional/Boundary-Scan Logic”, United States Patent 5,260,649, Nov 1993

[Verm02] “IEEE 1149.1-Compliant Access Architecture for Multiple Core Debug on Digital System Chips”, B. Vermeulen, T. Waayers, S. Bakker, Proceedings, International Test Conference , pp 55–63, Baltimore MD, Oct 2002

[Vinn98] “Analog and Mixed-Signal Test”, B. Vinnakota, Editor, Prentice Hall, Upper Saddle River, NJ, 1998

[Wagn87] “Interconnect Testing with Boundary-Scan”, P. T. Wagner, Proceedings, International Test Conference , pp 52–57, Washington DC, Sept 1987

[Wagn88] “Design for Testability of Mixed-Signal Integrated Circuits”, K. D. Wagner and T. W. Williams, Proceedings, International Test Conference , pp 823–828, Washington DC, Oct 1988

[Wagn91] “Enhancing Board Functional Self-Test by Concurrent Sampling”, K. D. Wagner and T. W. Williams, Proceedings, International Test Conference , pp 633–640, Nashville TN, Oct 1991

[Whet90] “Event Qualifi cation: a Gateway to At-Speed System Testing”, L. Whetsel, Proceedings, International Test Conference , pp 135–141, Washington DC, Sept 1990

[Whet92] “A Proposed Method of Accessing 1149.1 in a Backplane Environment”, L. Whetsel, Proceedings, International Test Conference , pp 206–216, Baltimore MD, Sept 1992

References

540

[Whet95] “Improved Boundary Scan Design”, L. Whetsel, Proceedings, International Test Conference , pp 851–860, Washington DC, Oct 1995

[Whet97] “An IEEE 1149.1 Based Test Access Architecture for ICs with Embedded Cores”, L. Whetsel, Proceedings, International Test Conference , pp 69–78, Washington DC, Nov 1997

[Wibl99] “Design a Production and Test Strategy for PLD-based PCBs”, K. Wible, Test and Measurement World , pp 37–44, March 1999

[Will83] “Design for Testability — A Survey”, T. W. Williams and K. P. Parker, Proceedings of the IEEE , vol. 71, No. 1, Jan 1983

[Xili90] “XC 4000 Logic Cell Array Family”, Xilinx Inc. 1990 [Xili92] “Boundary-Scan Emulator for XC 3000”, Application Note XAPP-007.0, Xilinx Inc.

1992 [Xili98] “The Programmable Logic Data Book”, Xilinx Inc, 1998 [Yau89] “A New Framework for Analyzing Test Generation and Diagnosis Algorithms for

Wiring Interconnects”, C. W. Yau and N. Jarwala, Proceedings, International Test Conference , pp 63–70, Washington DC, Aug 1989

References

541© Springer International Publishing Switzerland 2016 K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5

A ABM. See Analog boundary module (ABM) AC/DC selection cells , 286–287, 305, 312,

316, 317 AC EXTEST , 269, 283, 284, 287, 290, 298,

301, 303, 306, 459 AC EXTEST instruction

EXTEST_PULSE , 283, 284 EXTEST_TRAIN , 283, 284

AC EXTEST working group , 269 AC parameter description , 461–462, 465 AC pins

defi ned , 281 drivers , 283–287 test facilities , 282–288

AC test mode , 282, 298, 303 Addressable shadow port , 200 Advanced I/O

AC pins , 282–289, 315–318 BSDL example , 423 DC pins , 281–283, 287, 312 defects , 288–292, 300, 318–320 defi nition , 280 example , 270, 273, 274, 277, 279, 280 inter-IC communication , 270–275 problem , 270–280 testing , 269–320

Agilent HDMP-2689 , 45, 377 Aliasing , 131–134, 176 Ambiguity Class , 221, 223 Am29035 , 163 Analog boundary module (ABM) , 231, 232, 234,

242–250, 253, 254, 257, 262, 376 Analog boundary-scan , 203, 227–267 Analog test access port (ATAP)

AT1 , 233, 236, 237

AT2 , 233, 235–237 AT1N , 233, 256 AT2N , 233, 256

Analog test bus AB1 , 234 AB2 , 234 AB1N , 234 AB2N , 234

Anti-aliasing PTV , 134 Application specifi c integrated circuit (ASIC) ,

46, 118–120, 151 ATAP. See Analog test access port (ATAP) ATE. See Automatic test equipment (ATE) ATPG. See Automatic test program generation

(ATPG) AT&T 479AA , 195 Automatic test equipment (ATE) , 4, 5, 8, 15, 17,

32, 40, 45, 49, 52, 53, 99, 117–120, 122, 125, 130, 131, 141–143, 147, 148, 156, 164, 167, 172, 178, 179, 196, 208–212, 215, 218, 226–228, 250, 251, 256, 265, 335, 340, 341, 436

Automatic test program generation (ATPG) , 93, 97, 119, 146

B Ball-grid array (BGA) , 65, 133, 163, 169, 171,

224, 225 Basic test algorithm , 115–116, 120, 122, 129,

130, 353 BILBO. See Built-in logic block

obser(BILBO) Blind interrogation , 35, 199 Boundary register , 4, 50, 112, 151, 173, 231,

282, 330, 347, 382, 456

Index

542

Boundary register cell ABM , 231, 234, 242–247 abstraction of , 90, 91 AC_1 , 306, 309, 310, 315, 466 AC_2 , 306, 309, 310, 466 AC_7 , 306, 307, 309, 310 AC_8 , 306, 308–310 AC_9 , 308–310 AC_10 , 309, 311, 466, 467 AC_40 , 460, 466, 467 AC_41 , 460, 466, 467 AC_SelU , 305, 309, 310, 315, 466 AC_SelX , 305, 309, 310, 466 BC_0 , 86, 87 BC_1 , 73, 80, 81, 84, 86, 87, 90, 92–93,

101, 106, 168 BC_2 , 81, 86, 309, 310 BC_3 , 86, 88 BC_4 , 86, 88, 460, 466 BC_5 , 86, 88, 96, 97, 184 BC_6 , 86, 88, 106 BC_7 , 86, 89, 309, 310, 331, 409 BC_8 , 86, 89, 92, 99–102, 306, 309, 310, 351 BC_9 , 86, 89, 92, 101, 181, 308–310 BC_10 , 86, 89, 92, 99–101, 106, 308, 309,

311, 356–358 BC_99 , 92 bidir , 80 bidir_in , 91, 92 bidir_out , 91, 92 capture data , 90, 91, 102, 114, 124, 180,

437, 438, 450 cell count , 23, 79, 99, 182 clock , 41–42 constant “0/1” capture , 70, 102, 287 control , 30, 39, 42 controlr , 74, 411–413 DBM , 31, 231, 247–248 fl awed design , 25 general design , 53 hardware fault insertion , 167–168 input , 25, 27, 93 internal , 26, 29, 32 internal cell , 26, 32, 90, 92, 94, 102, 286,

305, 316 logical symbol , 27, 28, 41 merged cells , 78–81 observe_only , 74, 86, 88, 460 optimizing , 28–29 output2 , 80, 88 output3 , 81 parallel in , 20, 23, 91, 120 parallel out , 23, 37, 91, 92, 94, 182, 334, 420 reversible cell , 88, 92

self-monitoring output , 89, 101, 182, 239, 310, 311, 357

shift in , 23, 168, 305 shift out , 23, 338 signal inversion , 25 single-cell bidirectional , 182, 331 ST_10 , 357 test receiver , 304 three-cell bidirectional , 359 two-cell bidirectional , 182, 245

Boundary-scan description language (BSDL) attribute ( see Boundary-scan description

language (BSDL) attribute) automated creation , 201 boundary-scan register descriptions

boundary register assembly , 412–486 fi xed boundary register description ,

409–410 segmented boundary register

description , 410–412 cell description constants , 89–92 certifying , 187 comment , 49, 58–60, 89, 105, 315, 404 component conformance , 64–65, 83, 85, 105 damaged by electronic mail , 60 design warnings , 61, 78, 84, 87, 106 device package pin mapping , 61, 65–66, 313 entity , 59, 480–486 extensions , 61, 64, 77, 84, 87, 104, 106,

304–318, 459, 460, 466 extensions for 1149. , 304–318 generic parameter , 58, 61–62, 65, 66, 105, 312 grouped port identifi cation , 61, 66–67, 83,

314 identifi er , 58, 61, 62, 65, 105, 403, 415–417 IEEE version , 50, 51, 64, 107 information tag , 404, 415, 416, 418, 432, 433 initial (1990) version , 50 instruction register description , 61, 69–70, 314 INTEST execution description , 76–77 ISC algorithms , 322 linkage , 62, 63, 66, 75, 83, 312 logical port , 61–63, 66, 312, 405 mnemonic identifi ers , 403, 415–417 numeric literals , 403 pad-to-pin mapping , 57 PHYSICAL_PIN_MAP , 61, 62, 65, 83,

312, 313, 407, 481, 485 pin description , 62–63 PIN_MAP , 61, 62, 65, 83, 85, 312, 313,

407, 481, 485 port types , 66, 404–407 power port association description ,

433–434

Index

543

pre-defi ned constants , 85 prefi x identifi ers , 403 register assembly description , 407, 410,

412, 421, 424–431 register association description , 433–434 register constraint description , 431–433 register fi elds description , 416–425, 489 register mnemonics description , 415–417 2013 revisions , 57, 377 RUNBIST execution description , 76 safe bit , 81 scope , 51–57 standard use statement , 61, 63–64, 105,

309, 405, 406 STD_1149_1_2013 standard package , 405 string , 58, 59 structure , 57–60 subset and standard practice of VHDL , 50, 57 system clock requirements attribute , 414 syntax , 505–532 TAP port identifi cation , 67–68, 315 to/from synthesis systems , 57 type CELL_INFO , 86, 89 use as test driver , 52 user defi ned boundary cells , 101–104 user defi ned package , 64, 85, 102, 104, 105 user extensions , 77 user package syntax (2013) , 461 use statements , 58, 63–64, 73, 85, 104–106,

181, 309, 312, 315, 402, 405, 406, 456, 464, 481

verifi cation , 186, 187 verifi cation test , 186, 187 version control , 107 Version 0.0 parser , 107 VHDL package , 58, 63, 85, 181, 304 VHDL package body , 58 writing , 53, 105–107

Boundary-scan description language (BSDL) attribute

BOUNDARY_LENGTH , 72, 73, 80, 84, 86, 314, 409

BOUNDARY_REGISTER , 73, 79, 80, 84, 86, 91, 116, 120, 181, 186, 314, 409

BSDL_EXTENSION , 77, 87, 104, 310, 466 COMPLIANCE_PATTERNS , 68, 87 COMPONENT_CONFORMANCE , 64,

83, 85, 310, 313, 315, 481, 485 DESIGN_WARNING , 78, 87, 106 IDCODE_REGISTER , 71, 86, 184, 314 INSTRUCTION_CAPTURE , 69, 70, 84,

86, 106, 112, 124, 179, 314 INSTRUCTION_LENGTH , 69, 70, 83, 86,

105, 314

INSTRUCTION_OPCODE , 69–71, 83, 86, 105, 314

INSTRUCTION_PRIVATE , 69, 70, 72, 86, 106

INTEST_EXECUTION , 77, 87 PIN_MAP , 65, 83, 85, 313, 407, 481, 485 PORT_GROUPING , 66, 87, 160, 314, 481 REGISTER_ACCESS , 71, 72, 76, 84, 86,

106, 314, 421 RUNBIST_EXECUTION , 76, 87 TAP_SCAN_CLOCK , 67, 83, 86, 314 TAP_SCAN_IN , 67, 83, 86, 314 TAP_SCAN_MODE , 67, 83, 86, 314 TAP_SCAN_OUT , 67, 68, 83, 86, 314 TAP_SCAN_RESET , 67, 86 USERCODE_REGISTER , 71, 84, 86

Boundary-Scan master , 15, 16, 190, 195–197 Buffer. See Boundary-scan description

language (BSDL), logical port Built-in logic block observer (BILBO) , 172 Bus , 9, 10, 39, 42, 48, 62, 63, 135, 136, 138,

139, 151, 162, 188, 189, 196, 200, 208, 227, 234, 237–242, 246, 250, 251, 256, 258, 261, 263, 266, 270–272, 274–276, 351, 383, 461–463, 465, 468, 489

single-ended , 271, 276 Bypass register , 12, 22, 31, 34, 40–42, 52,

112, 125, 162, 186, 199, 234, 252, 336, 407

capture bit , 125

C Capture fl ip-fl op (CAP) , 23, 27, 28, 36, 37, 78,

86, 90, 91, 93, 94, 102, 112, 152, 153, 167, 184, 186, 303, 353, 358, 419

Chains analog busing , 234 broken , 124, 290, 397 chain ordering , 190 confi gurations , 33, 187–190 conjoined , 33, 123, 188, 189 dynamically reconfi gurable , 188 extra shift stages (pad bits) , 197 integrity , 22, 124–126, 143, 173, 201 linked , 123, 188, 197 multidrop system , 198–200 multiple simple , 33, 123 simple , 32, 33, 123, 124, 187, 188,

190–192, 196–198, 236 testing , 123–145

Chip-on-board (COB) , 171, 225 Chip-scale packaging , 225

Index

544

Common mode noise , 66, 257, 273 Comparator , 292, 293, 295, 296, 298–300 Complex programmable logic device (CPLD) ,

118, 164, 201, 334 Compliance enable pins , 43, 51, 56, 68, 69,

75, 105, 117, 194, 195 Compliance limit

current , 206, 207 voltage , 206, 207

Concurrent programming , 322, 338–340 Confounding , 131–134 Counting sequence , 127, 131, 133, 134, 142 CPLD. See Complex programmable logic

device (CPLD) Crosstalk , 263, 295

D Data register

boundary register , 22 bypass , 22, 34 capture data , 20, 90, 91, 437, 450 device identifi cation , 22 dynamic data register , 385, 397–401 ECID , 23 halt shifting , 15 Init_data , 384, 392, 394–395, 397, 400,

415, 416, 424–427, 432, 433, 441, 452, 453, 456–458, 469, 471, 473, 478, 481, 486, 488, 489

init_status busy/done bit , 395 pass/fail bit , 123

mode of operation , 12 parallel hold latches , 20 reset selection

reset-control bit , 396 reset-enable bit , 396 reset-hold bit , 396, 397

segmented data register , 400 shift portion , 17, 112 shift ripple , 18 target register , 112, 113 TMP_status

bypass-escape bit , 386, 392, 395, 396 TMP-status bit , 392, 395, 396, 417

toggle_control , 354, 358, 366 user-defi ned , 22, 42, 72, 106, 429

DBM. See Digital boundary module (DBM) DC pins , 281–283, 287, 312, 350 DC test mode , 282 Defects

detectable with 1149.6 , 290 masking , 421

missing capacitor , 290, 291 model , 110, 148, 288–291 open circuit , 292 open solder joint , 291 shorted capacitor , 319, 458–459 shorted driver , 132, 133, 291 shorted receiver , 459

Designated driver , 130–132, 134–136, 139 Design for testability (DFT)

board level , 187–198, 263, 319, 375 built-in logic block observer , 172 device programming , 14, 31, 335, 341 integrated circuit level , 173–187, 263, 318,

374 LSSD , 172 system level , 173, 186, 189, 198–200

Device identifi cation register , 12, 13, 20, 22, 34–36, 52, 70

capture pattern , 106, 178, 179, 184, 186 Device under test (DUT) , 5, 7, 144, 207,

343–345, 348, 366 DFT. See Design for testability (DFT) Differential

AC coupled , 269, 277 current balancing , 273 driver , 66, 159, 161, 178, 257, 258, 273,

274, 282, 291, 316, 354–356, 360, 361, 363, 364, 408, 435, 469–471

receiver , 161, 257, 258, 273, 282, 288, 292, 295, 296, 312, 408, 435, 460, 472

signals , 66, 105, 159–161, 256–258, 266, 273, 277, 278, 281, 282, 287, 288, 297, 318, 319, 348, 353–356, 375, 383, 384

testing , 256, 367 transmission , 269, 271 unbalancing , 354–356

Differential signaling EXTEST paradox , 258 noise rejection , 257, 258

Digital boundary module (DBM) , 31, 231, 233, 247–248

DRAM. See Dynamic random access memory (DRAM)

Drive confl icts board level , 136 duration , 129

Driver asymmetrical , 40, 75, 78, 81 clear the throat , 303 damage resistant , 179–180 disabling , 78, 471 ECL open emitter , 40, 75 “Keepers” , 75

Index

545

single-ended , 161, 272, 275 TTL open collector , 40, 75

Dual-slope integrator , 213–216 DUT. See Device under test (DUT) Dynamic random access memory (DRAM) ,

344, 365, 375

E Electronic design automation , 47, 172 Electrostatic discharge (ESD) , 109, 125, 207,

247, 263 Emulation , 9, 42, 163, 232, 266 Entity pin behavior description , 463–464 ESD. See Electrostatic discharge (ESD) Extended interconnect , 229–232, 242, 244,

249, 257, 267 EXTEST paradox , 258

F Fault

detected , 408 dictionary , 120 failure mechanism , 5 model , 5

Field-programmable gate array (FPGA) , 26, 118, 164, 189, 201, 334, 390, 391, 394, 458

Field-programmable IC blank page , 31 in chains , 189 cook time , 165 hard-wired , 31, 32 input/output blocks (IOBs) , 31 parallel programming , 32 programming , 31, 32, 43, 189

Fine-pitch , 7 Fixed system pins , 323 FLASH RAM , 165–167, 321

programming , 166–167 FPGA. See Field-programmable gate array

(FPGA) Framescan , 343

G Gallium arsenide , 180 Garbage In, Garbage Out , 3, 267 3GIO , 272 Grandfathering , 64, 65 Ground-bounce , 174, 175, 178, 295 Guardband , 205 Guarding

analog , 209, 218, 226 digital , 41 errors , 209–212

H Hardware description language

verilog , 56 VHDL , 50, 401

Hardware fault insertion , 167–168 High-pass fi lter , 292–294, 296, 299–301, 463 Homing sequence , 157 Hyper-text markup language (HTML) , 185 Hysteresis

delay , 299, 301 voltage , 295, 298

Hysteretic comparator , 298 Hysteretic memory , 296, 300, 302–304, 459

initializing and capturing , 302–304

I ICT. See In-circuit test (ICT) IEEE/ANSI standard 1149.1-1990

supplement A , 4 supplement B , 4

IEEE standard 1076 , 50 IEEE standard 1149 , 25, 48, 58, 63, 64, 73, 83,

85–89, 103, 104, 106, 305, 309–313, 315, 322, 405, 406, 424, 440, 441, 455, 457, 460, 466, 471, 474, 478, 479, 482, 485, 486

IEEE standard 1149.1 architecture summary , 19 automation , 46, 49, 382, 388, 389, 422 basic architecture , 10–33 benefi ts , 43–48 conformance and documentation

requirements , 49 costs , 43–48 critical mission , 38 ensuring compliance , 53 extensibility , 85 gate overhead , 44 increased design time , 45 inserted delay , 44, 45 lack of discipline , 45 lack of hierarchy , 162 non-invasive mode , 9, 151, 183 pad overhead , 44 pin-permission mode , 9, 10, 183 private instructions , 69 public instructions , 42 reuse of tests , 46

Index

546

IEEE standard 1149.1 (cont.) standardized access , 39 subordination , 43 trends , 47–48, 381 user-defi ned instructions , 42 yield loss , 44

IEEE standard 1149.4 analog boundary modules , 231, 242–247 analog test access port , 233, 236–237 contrasted with 1149.6 , 271 digital boundary modules , 233 general architecture , 233–248 TBIC , 234, 237–242

IEEE standard 1149.5 , 9, 48, 189, 199, 200 IEEE standard 1149.6

AC pins , 281–288, 463, 464, 466 compatibility with 1149.1 , 280 DC pins , 281, 282, 287, 312 testing differential I/O , 256

IEEE standard 1149.8.1 , 343, 350–352 IEEE Standard 1532 , 4, 14, 31, 165, 286,

321–342, 376–378 IEEE 1149 testability bus standards , 48 in bit. See Boundary-scan description language

(BSDL), logical port in bit_vector. See Boundary-scan description

language (BSDL), logical port In-circuit test (ICT)

analog , 203–217 bed-of-nails , 203, 217, 344 fi xturing , 375 multiplexed resources , 120 overdrive damage , 40

Inout. See Boundary-scan description language (BSDL), logical port

In-situ confi guration. See In-system confi guration (ISC)

Institute of Electrical and Electronics Engineers (IEEE) , 3, 49, 117, 161, 172, 203, 227, 269, 321, 343, 381, 455

Instruction mode , 9, 12, 93–95, 97–98, 100–102, 240

Instruction register capture pattern , 69, 106, 175, 178, 186 halt shifting , 15 length , 315 opcodes , 69 parallel hold rank , 18–20 sample cell design , 21 shifting , 340 shift rank , 18 shift ripple , 18, 94

In-system confi guration (ISC) , 149, 164–166, 321–342

Intel 8008 , 6

Intel 80486DX , 187 Intellectual property (IP) , 1, 382, 455, 456, 461 Interconnect

adjacent nodes , 143 counting sequence , 134 differential , 229 extended , 229–232, 242, 244, 249,

257, 267 interaction test , 140–144 logical , 229 opens , 365 physical , 229 pin-level diagnostic (shorts) , 144 shorting radius , 143 shorts , 129–130, 135, 136, 138, 142, 182 testing , 127, 132, 140, 141, 158, 187, 191,

228, 232, 257, 279, 441 test length , 129 undetected opens , 130, 136 walking-bit sequence , 131

I/O Pads , 270, 384 ISC. See In-system confi guration (ISC) ISC instruction

ISC_DISABLE , 165, 325, 326, 328, 338–340

ISC_ENABLE , 165, 325–330, 333, 334, 338, 339, 377

ISC_NOOP , 339, 340 ISC_PROGRAM , 165, 336–340 ISC_PROGRAM_SECURITY , 339 ISC_READ , 336–339

ISC signals ISC_Disable_Completing , 326 ISC_Done , 326–328, 337 ISC_Enabled , 165, 325–330, 333, 334,

338, 339, 377 ISC system pins , 323–324

J Joint electron device engineering council

(JEDEC) , 35 Joint test action group (JTAG) , 3, 117

K Kelvin measurement , 211

L Large scale integration (LSI) , 6 Level-sensitive scan design (LSSD) , 68, 172 LFSR. See Linear feedback shift register

(LFSR) Linear feedback shift register (LFSR) , 42, 144

Index

547

Linkage. See Boundary-scan description language (BSDL), logical port

Lobotomy problem , 9, 37, 183, 386 Logic simulator , 5 Low-pass fi lter , 281, 293, 298, 301, 317 LSSD. See Level-sensitive scan design

(LSSD)

M Manufacturing faults

dead component , 172 missing component , 172 open solder , 291 solder shorts , 143 wrong component , 172, 229

Matsushita electric industries , 47 MCM. See Multi-chip module (MCM) Measurement errors , 212 Measuring impedance

imaginary waveform , 215–217 reactive devices , 216 real waveform , 217 6-wire measurement , 212

Measuring operational amplifi er (MOA) , 212 Mixed logic families , 191–193 Mixed-signal , 158, 159, 195, 223–226,

228–231, 267 Modes of operation

extensible , 10 non-invasive , 9, 10 pin-permission , 9, 10

Monte carlo simulations , 219 Moore’s law , 48, 270, 272, 274, 275, 334, 359,

381–382, 384 Motorola 68040 , 44 Multi-chip module (MCM) , 47, 161–162, 171,

201 Multidrop systems , 198–200 Multiple IDCODEs , 71

N Node voltage analysis , 218–219, 221, 252

limited access , 217–223 Noise

common mode , 66, 257 crosstalk , 295 ground-bounce , 295 immunity , 66, 266, 277 I/O , 273 radiated interference , 273 rejection , 257, 258, 295 small signal , 297, 299

Normal system pins , 350

O On-chip coupling and bypassing , 459 Opens express , 343 Operational amplifi er , 212–214 Out bit. See Boundary-scan description

language (BSDL), logical port

P P1149.2 , 48 P1149.3 , 48 Package port link description , 464 Packaging hierarchy , 162, 200, 422, 423, 436,

442, 445, 488 Parallel test vector (PTV) , 115, 116, 130 Parasitic devices , 204, 205, 239, 241, 246,

253, 258, 263, 264 PCI express , 272 PDL commands (Level-0)

iApply , 437–439, 442–451, 473, 488, 489 iCall , 440, 445, 447, 482 iClock , 442, 445 iCLockOverride , 442, 445 ifEnd, 446 ifFalse , 446 ifTrue , 446 iLoop , 446 iMerge , 446–448 iNote , 448 iPDLLevel , 441 iPrefi x , 442, 448 iProc , 441, 442, 445–449, 467, 482 iProcGroup , 442 iRead , 437, 438, 442, 443, 446, 448, 450,

468, 469 iRelease , 448 iRunLoop , 445, 448, 449 iScan , 442, 443, 446, 448 iSetFail , 448, 450 iSetInstruction , 442 iSource , 441 iTake , 448 iTMSidle , 446, 449 iTMSreset , 446, 449 iTRST , 446, 449 iUntil , 446 iWrite , 437, 439, 442–444, 448, 450, 468,

469, 473 PDL commands (Level-1)

iGet , 449–452 iGetStatus , 449–451

PDL_CONTEXT_PATH , 473 PDL use model

data fl ow (iApply) , 437 PDL scan frame , 437, 438

Index

548

Performance tests , 204 PLD. See Programmable logic device (PLD) Power

applying , 9, 127, 133, 139 cycling (reset) , 34, 38 distribution , 169, 174, 178, 193, 195, 271, 273 removal (safety) , 130, 180, 438, 471 separate analog and digital , 195

Powered capacitive opens testing , 343, 344, 346–350

Power/ground distribution , 174–178 Private instructions , 42, 69, 70, 186, 256, 435 Procedural description language (PDL)

level-0 PDL , 436, 438–440, 449 level-1 PDL , 436, 444, 449 PDL procedures , 440–442, 448, 449, 467,

482 TCL , 436, 440, 468

Programmable feature description , 462, 463, 467 Programmable logic device (PLD)

complex programmable logic device , 118, 164, 334

FPGA , 26, 118, 164, 189, 201, 390, 391, 394, 458

non-volatile , 31, 165, 190, 321, 326, 328, 334–336, 340

volatile , 31, 189, 326, 334, 335 PTV. See Parallel test vector (PTV)

R Receiver , 5, 109, 161, 182, 257, 273, 361,

390, 458 differential , 66, 161, 257, 258, 273, 282, 288,

292, 295, 296, 312, 408, 432, 460, 472 Reed relay

area , 29, 44, 99, 129, 151, 221, 224, 226, 228, 235, 244, 263, 264, 283, 305, 357, 375, 386, 399, 408, 418

off-resistance , 235 on-resistance , 235 switching time , 235

Reference voltages G , 208, 234 V H , 234, 237, 242–245, 249, 257, 262, 264 V L , 234, 237, 242–245, 249, 252, 257, 262,

264 V TH , 237, 242, 264

S Scan-path linker , 196, 197 Segmented data register , 394

Selective toggle system pins (“ST” system pins ) , 349

Self-monitoring output , 38, 101, 181, 182, 239, 308, 357

Self-referenced comparison , 293, 298 Sentinel bits , 125, 126 Sequential response vector (SRV) , 116, 129 Sequential test vector (STV) , 116, 129, 130,

132, 296, 303, 319 SERDES , 45, 275–277, 320, 377, 414 SERialize/DESerialize. See SERDES Serial vector format (SVF) , 147 Shorted capacitor testing , 290, 291, 319, 458,

459 Shorting radius , 143 Silicon switches

area , 235 bipolar , 235, 262 conceptual , 242, 244 crummy , 236 leakage , 263, 264 off-resistance , 235 on-resistance , 235 parasitic coupling , 264 switching time , 208, 235, 290 symbols , 235, 236 “T” switch , 263, 264

Simple interconnect , 129, 228, 229, 257 Single-ended , 161, 271, 272, 274–276, 280,

281, 288, 291, 298, 303, 316, 317, 356, 358–360, 362, 363, 366, 368

Single Stuck-at fault model , 5 SMT. See Surface-mount technology (SMT) SOC. See System-on-chip (SOC) Source

current , 141, 206, 207, 218, 250, 252, 355 voltage , 206–208, 210, 216, 217, 243, 299

SRV. See Sequential response vector (SRV) 1149.6 Standard PDL procedures

programmable “GetALL” iProcs , 467 programmable “Get” iProcs , 467 programmable “Set” iProcs , 467

STD_1149_1_1990 , 58, 64 STD_1149_1_1993 , 64 STD_1149_1_1994 , 58, 59 STD_1149_1_2001 , 63, 64, 73, 85–89, 305 STD_1149_6_2003 , 305, 309–311, 466

defi ned , 466 STV. See Sequential test vector (STV) Surface-mount technology (SMT) , 7, 46, 171 Synchronizing sequence , 12, 111, 449 System logic , 9, 30, 32, 34, 36–39, 41, 43, 48,

50, 53, 56, 78, 79, 81, 82, 91,

Index

549

120–122, 151, 178–180, 183, 186, 198, 325, 366, 386, 393, 398, 419

System modal state ISC accessed , 325, 328–330, 338 ISC complete , 325, 326, 328, 330, 340 operational , 326, 327, 330, 340 unprogrammed , 326, 330, 337

System-on-chip (SOC) , 45, 161, 171, 377

T TAP. See Test access port (TAP) TAP controller

asynchronous reset , 10 data column states , 12, 13, 113, 144, 199 fi nite state machine , 11, 12 instruction column states , 12, 13, 175 power-up reset , 420 state diagram , 12, 20, 33, 48, 52, 56, 110,

111, 113, 123, 167, 174, 179, 186, 223, 283, 385, 444, 449

state transitions , 12, 13 synchronizing sequence , 12, 111, 449 temporary state , 14–17

TAP controller state capture-DR , 14, 16–18, 22, 34–40, 52, 70,

72, 90, 112, 122, 142, 143, 152, 154, 155, 181, 186, 279, 297, 303, 305, 354, 394, 419, 420, 436

capture-IR , 14, 17–20, 53, 70, 106, 112, 124, 175, 178, 179

Exit1-DR , 16–18, 112, 300 Exit2-DR , 16, 17, 300, 444 Exit1-IR , 14, 15, 17, 18, 20, 112, 179 Exit2-IR , 15, 20 pause-DR , 16, 17, 188, 444, 445 pause-IR , 15, 20, 188 run-test/idle , 13–14, 16, 17, 40, 76, 113,

122, 125, 144, 283–285, 291, 300, 303, 317, 318, 325–328, 336–340, 351–353, 357, 358, 444, 445, 449

select-DR-scan , 13, 14, 16, 17, 152, 174, 175, 283, 351, 445

select-IR-scan , 14, 113, 175 shift-DR , 16, 17, 38, 112, 125, 144, 354,

391, 420, 444 shift-IR , 14, 15, 17, 18, 20, 111, 112 test-logic-reset , 12–14, 20, 33, 35, 37, 57,

74, 90, 111, 116, 122, 123, 125, 165, 168, 183, 186, 199, 326, 328, 338–340, 366, 386, 387, 394, 397, 420, 445, 449, 453

update-DR , 16–18, 28, 37–39, 112, 113, 129, 155, 167, 168, 174, 175, 278, 279, 283, 296, 297, 300, 330, 353, 387, 393, 396, 420, 421, 436, 445

update-IR , 15–20, 28, 37, 40, 41, 71, 112–114, 116, 120, 122, 174, 179, 186, 303, 324, 328, 352, 386, 394

Tape automated bonding (TAB) , 171 TAP instruction

BYPASS , 13, 20, 22, 34, 35, 37, 38, 57, 70, 72, 90, 93–95, 97, 98, 100–102, 107, 110, 112, 125, 144, 155, 162, 165, 167, 179, 186, 190, 192, 198, 199, 240, 241, 246, 249, 252, 261, 282, 326, 328, 340, 386, 387, 392

CLAMP , 41, 57, 93–95, 97, 98, 100–102, 110, 155, 165, 186, 240, 252–254, 282, 306, 329, 330, 342, 387, 391–393, 442

CLAMP_HOLD , 386, 387, 392, 395, 396 CLAMP_RELEASE , 386, 387, 392, 395,

396 ECID_CODE , 389–390, 394, 421, 441,

452 EXTEST , 28, 38, 39, 41, 57, 70, 72, 90,

93–95, 97–103, 107, 110, 112–115, 121, 151, 155, 157, 166, 167, 175, 179–181, 183, 184, 186, 190, 191, 240, 241, 246, 248–252, 258, 261, 283, 284, 286, 287, 290, 291, 295–297, 301, 306, 319, 329, 330, 342, 347, 352, 353, 358, 366, 369, 370, 373, 375–377, 386, 387, 390, 395, 435, 442, 458, 459, 461, 463, 487, 490

EXTEST_PULSE ( see AC EXTEST Instruction)

EXTEST_TRAIN ( see AC EXTEST Instruction)

HIGHZ , 40, 57, 76, 98, 99, 151, 155, 165, 186, 240, 241, 245, 246, 249, 252–254, 261, 282, 306, 329–334, 342

IC_RESET , 393, 396, 397 IDCODE , 12, 20, 22, 34–37, 70–72, 90,

94, 95, 97, 98, 100–102, 107, 110, 112, 125, 184, 186, 199, 240, 249, 282, 315, 326, 387, 389, 452

INIT_CLAMP , 390–392, 394 INITIALIZE , 366, 379 INIT_RUN , 390–393, 395, 414, 441, 457,

471, 473, 488, 489

Index

550

TAP instruction (cont.) INIT_SETUP , 390–392, 394, 441, 457,

488, 489 INTEST , 38–42, 44, 53, 57, 70, 74–77, 81,

90, 92–102, 106, 110, 120–122, 165, 179, 240, 244, 248, 249, 254–256, 258, 264, 266, 282, 288, 303, 306, 308, 316, 329, 460

ISC_DISABLE , 165, 325, 326, 328, 338–340

ISC_ENABLE , 165, 325–328, 330, 338, 339, 377

ISC_PROGRAM , 165, 336–340 PRELOAD , 28, 36, 37, 40, 41, 57, 70, 76,

93–95, 97, 98, 100–102, 110, 114, 116, 122, 165, 168, 189, 240, 249, 282, 303, 306, 330, 352, 353, 358, 366, 387, 391, 392, 442

PROBE , 240, 241, 244, 246, 248, 253, 256, 261, 264

RUNBIST , 14, 39–42, 76, 77, 93–95, 97–102, 106, 122–123, 172, 181, 183, 186, 187, 240, 248, 253–254, 306, 326, 329, 435

SAMPLE , 36, 151, 249, 460 SELECTIVE_TOGGLE , 352, 353, 355,

358–360, 366 SHUTDOWN , 378 TMP_STATUS , 387, 392, 395 TOGGLE_SETUP , 352, 354 USERCODE , 22, 36, 70, 93–95, 97, 98,

100–102, 186, 240, 249, 282 user-defi ned , 12, 42, 71, 72, 106, 144, 185

TAP state capture-DR , 14, 16–18, 22, 34–40, 52, 70,

72, 90, 112, 122, 142, 143, 152, 154, 155, 181, 186, 279, 297, 303, 305, 354, 394, 419, 420, 436

run-test/idle , 13–14, 16, 17, 40, 76, 113, 122, 125, 144, 283–285, 291, 300, 303, 317, 318, 325–328, 336–340, 351–353, 357, 358, 444, 445, 449

update-DR , 16–18, 28, 37–39, 112, 113, 129, 155, 167, 168, 174, 175, 278, 279, 283, 296, 297, 300, 330, 353, 387, 393, 396, 420, 421, 436, 445

Target register , 17, 21, 34, 39, 40, 57, 76, 112, 175, 336, 337, 435, 436

TBIC. See Test Bus Interface Circuit (TBIC) Test access port (TAP)

compatibility with 1149.4 , 48 TCK , 10 TDI , 10

TDO , 10 TMS , 10 TRST , 10

Test bus interface circuit (TBIC) , 234, 235, 237–242, 245, 247, 250–253, 256, 259–262

Test clock (TCK) buffered , 190–192 cycles in Run-Test/Idle , 326, 336, 337 falling edge , 12, 13, 16–18, 30, 112, 174,

284, 296–300, 303, 317, 324, 328, 330, 351, 353, 393

ground bounce , 174, 175, 178, 271–273, 295

level translation , 191 maximum clock frequency , 317 rising edge , 12–18, 152, 186, 297, 303,

305 stop state , 68

Test data in (TDI) pin placement , 173–174 shorted to TDO , 124, 126

Test data out (TDO) actively driving , 63, 81 disabled , 15 shifting data , 20

Testing Ad-Hoc , 3 analog in-circuit , 203–217 background system diagnostics , 168 basic BIST test algorithm , 122–123 basic test algorithm , 115–116, 120, 122,

129, 130, 353 BIST , 9, 22, 39, 42, 109, 118, 122, 123,

144–145, 162, 198, 393, 431, 434, 441, 447

board-level self-test , 42 boundary-scan chains , 32–33, 53, 99,

123–145, 165, 187, 192, 197, 198, 365, 488

chain integrity , 22, 124–126, 143, 173 CMOS IDDQ , 10 concurrent monitoring , 154–155 connection , 126, 139–140 control of critical nodes , 194–195 customized , 230 DC parametric (IC) , 149–151 differential pins , 367 edge connector functional , 4–6, 171 emulation functions , 9 fault dictionary , 120 hardware development support , 163 high frequency , 227

Index

551

hot mock-ups , 4, 5 hybrid digital/analog , 42 IC , 7, 19, 39, 53, 120–122, 159, 354, 382 IC BIST , 122–123 In-Circuit , 6–8, 31, 40, 41, 47, 116–120,

129, 146–148, 164, 171, 179, 203–218, 226, 280, 344, 347

in-circuit boundary-scan , 118–120, 139 interaction , 140–144, 147 interconnect , 65, 126–141, 144, 148, 158,

187, 191, 194, 198, 228, 230, 232, 237, 239–246, 249, 250, 257, 266, 267, 279, 356, 366, 441

interconnect opens , 134–139 interconnect shorts , 129–130, 135, 136,

138, 142, 182 limited access , 217–223 limited access node voltage , 221–223 logic analyzer , 36, 151 mixed digital/analog , 109, 158–161 module , 48, 200 multi-chip modules , 161–162 node voltage , 220–223 noise rejection , 257, 258, 295 non-digital devices , 158 non-scan ICs , 155–157 parallel impedances , 209 performance , 162, 204 personal tester , 117–118 personal tester within ATE , 117–118 printed circuit board , 3, 7, 32, 224, 272, 343 pseudo-random patterns , 42, 144 RAM arrays , 23 sample mode , 149, 151–154 self-test , 14, 22, 39, 40, 42, 144, 172, 265 signature analysis , 42, 144, 171 simulator-based functional , 6 stop-on-fi rst-fail , 116, 436 system level , 148, 189, 198, 266 undetectable shorts , 157 unpowered analog , 209 unpowered shorts testing , 119, 126, 139 X-ray laminography , 133, 375

TestJet , 343 Test mode persistence (TMP) , 10, 12, 38, 198,

324, 385–387, 392, 394–397, 420, 453

Test mode select (TMS) buffered , 190, 192 level translation , 191

Test receiver AC-coupled response , 294–295 AC Response , 298–301

cell mapping , 304 data capture , 154 DC-coupled response , 294 DC response , 295–298 defect detection , 288 documented in BSDL , 66, 68 edge detection , 301 edge sensitive , 287 guaranteed AC-coupling , 301 initial state , 296, 297 integrated AC/DC , 302 low-pass time constant , 300 memory , 296, 297, 300, 303 noise rejection , 257, 258, 295 output , 288, 299, 300 self-referenced , 280, 288, 293, 298 silicon overhead , 320 single-ended , 287 transparent , 287

Test reset (TRST) , 10–13, 20, 33, 44, 57, 67, 105, 111, 123, 187, 194, 195, 233, 326, 328, 386, 390, 393, 396, 407, 420, 440, 449

assertion , 12, 18, 33, 123, 326 Texas instruments 74ABT8996 , 200 Texas instruments 74ACT8990 , 195 Texas instruments 74ACT8997 , 189, 196, 197,

200 Texas instruments 74ACT8999 , 189, 196, 200 Texas instruments 74BCT8244 , 42, 44 Texas instruments 74BCT8373 , 178 Texas instruments 74BCT8374 , 58, 61, 78, 82,

178 Through-hole pin , 7 Time constant

decay , 278, 279, 295, 301 high-pass , 293, 300, 301, 317 low-pass , 293, 300, 301, 317

TMP operational modes persistence off , 392, 420 persistence on , 393, 396, 420

Toggle control register , 351–354, 358, 366 Tolerance

of component values , 205 distribution , 205 nominal values , 205

Transition defi ned , 293 detecting , 283 edge speed , 285, 286 generating , 283 invalid , 294, 295, 300 noise , 272, 299

Index

552

Transition (cont.) use of mission driver , 285 valid , 295, 298–300, 303, 319

U Unpowered capacitive opens detection , 343

sense plate , 344–347 Update fl ip-fl op (UPD) , 23, 27, 28, 37–39, 41,

74, 91, 96, 112, 167, 180, 181, 283, 303, 353, 358, 387, 389, 398

UUT. See Device Under Test

V Very large-scan integration (VLSI) , 44, 119,

171, 174 VHDL identifi ers. See Boundary-scan

description language (BSDL), identifi er

VHSIC hardware description language (VHDL) , 50, 51, 56–58, 61–63, 65, 68, 85, 90, 105, 181, 304, 401–403, 405, 419, 440

Vias , 7, 8, 171, 224, 225 blind , 171

Voltage programmability , 458 Voltage scaling , 458 Voltage variations , 458

W Walking-bit sequence , 131, 133

X Xilinx 4005 , 31, 32 Xilinx XC9500 , 31 X-ray laminography , 133, 375 X-Y coordinate location data , 8

Index