Texas InstrumentsSemiconductors
SearchTech SupportCommentsSite MapTI&MEHome
ProductsDevelopment ToolsApplications
Engineering Design CenterDSP SolutionsSC in the newsSC Product InformationSC Applications & TechnologiesSC Service & Support

JTAG
Blue Band

Data Formats

Several data formats have emerged to make IEEE 1149.1 successful and well-supported by tools. This section discusses the most widely accepted data formats that support IEEE 1149.1 -- BSDL, HSDL, and SVF.

BSDL (Boundary-Scan Description Language)

HSDL (Hierarchical Scan Description Language)

SVF (Serial Vector format)


What Is BSDL?

Several data formats have emerged to make IEEE 1149.1 successful and well-supported by tools. This section discusses the most popular data format for describing how IEEE 1149.1 was implemented in a device -- BSDL, or Boundary-Scan Description Language.

Boundary-Scan Description Language (BSDL)

In 1990, the IEEE 1149.1 standard was approved and implementation of the standard accelerated. As more people became aware of and used the standard, the need for a standard method for describing IEEE 1149.1-compatible devices was recognized. The IEEE 1149.1 working group established a subcommittee to develop a device description language to address this need.

The subcommittee has since developed and approved an industry standard language called Boundary-Scan Description Language (BSDL). BSDL is a subset of VHDL (VHSIC Hardware Description Language) that describes how IEEE 1149.1 is implemented in a device and how it operates. BSDL captures the essential features of any IEEE 1149.1 implementation. BSDL was approved in 1994 as IEEE Std. 1149.1b.

The IEEE 1149.1 is a structured design-for-test approach well suited for tools and automation. Tools developed to support the standard can control the TAP (Test Access Port) if they know how the boundary-scan architecture was implemented in the device. Tools can also control the I/O pins of the device. BSDL provides a standard machine and human-readable data format for describing how IEEE 1149.1 is implemented in a device.

How BSDL is Used

Many IEEE 1149.1 tools already on the market support BSDL as a data input format. These tools offer different capabilities to customers implementing IEEE 1149.1 into their designs including board interconnect Automatic Test Pattern Generation (ATPG) and Automatic Test Equipment (ATE).

When you use tools that support BSDL you can often obtain BSDL from your semiconductor vendor. This can result in significant time and cost savings.

Teradyne estimates that to create in-circuit test patterns for a leading microprocessor normally may require as much as seven weeks time:

  • One week to study the device
  • Four weeks to develop in-circuit test patterns
  • Two weeks to verify the patterns on ATE

The development cost estimate for this approach is $14,000.

If the microprocessor supports IEEE 1149.1, and the BSDL is supplied by the vendor, the time to develop in-circuit test patterns is less than two hours (less than $100) using today's tools.

Elements of BSDL

A BSDL description for a device consists of the following elements:

  • Entity descriptions
  • Generic parameter
  • Logical Port description
  • Use statements
  • Pin Mapping(s)
  • Scan Port identification
  • Instruction Register description
  • Register Access description
  • Boundary Register description

Entity Descriptions -- The entity statement names the entity, such as the device name (e.g., SN74ABT8245). An entity description begins with an entity statement and terminates with an end statement.

    entity XYZ is 

      {statements to describe the entity go here}

    end XYZ 

Generic Parameter -- A generic parameter is a parameter that may come from outside the entity, or it may be defaulted, such as a package type (e.g., "DW").

    generic (PHYSICAL_PIN_MAP : string := "DW");

Logical Port Description -- The port description gives logical names to the I/O pins (system and TAP pins), and denotes their nature such as input, output, bidirectional, and so on.

    port (OE:in bit;

      Y:out bit_vector(1 to 3);

      A:in bit_vector(1 to 3);

      GND, VCC, NC:linkage bit;

      TDO:out bit;

      TMS, TDI, TCK:in bit);

Use Statements -- The use statement refers to external definitions found in packages and package bodies.

    use STD_1149_1_1994.all;

Pin Mapping(s) -- The pin mapping provides a mapping of logical signals onto the physical pins of a particular device package.

    attribute PIN_MAP of XYZ : entity is 

    PHYSICAL_PIN_MAP;

    constant DW:PIN_MAP_STRING:=

      "OE:1, Y:(2,3,4), A:(5,6,7), GND:8, VCC:9, "&

           "TDO:10, TDI:11, TMS:12, TCK:13, NC:14";

Scan Port Identification -- The scan port identification statements define the device's TAP.

    attribute TAP_SCAN_IN of TDI : signal is TRUE;

    attribute TAP_SCAN_OUT of TDO : signal is TRUE;

    attribute TAP_SCAN_MODE of TMS : signal is TRUE;

    attribute TAP_SCAN_CLOCK of TCK : signal is (50.0e6,

         BOTH);

Instruction Register Description -- The Instruction Register description identifies the device-dependent characteristics of the Instruction Register.

    attribute INSTRUCTION_LENGTH of XYZ : entity is 2;

    attribute INSTRUCTION_OPCODE of XYZ : entity is

      "BYPASS (11), "&

      "EXTEST (00), "&

      "SAMPLE (10) ";

    attribute INSTRUCTION_CAPTURE of XYZ : entity is

         "01";

Register Access Description -- The register access defines which register is placed between TDI and TDO for each instruction.

    attribute REGISTER_ACCESS of XYZ : entity is

      "BOUNDARY (EXTEST, SAMPLE), "&

      "BYPASS (BYPASS) ";

Boundary Register Description -- The Boundary Register description contains a list of boundary-scan cells, along with information regarding the cell type and associated control.

    attribute BOUNDARY_LENGTH of XYZ : entity is 7;

    attribute BOUNDARY_REGISTER of XYZ : entity is

      "0 (BC_1, Y(1), output3, X, 6, 0, Z), "&

      "1 (BC_1, Y(2), output3, X, 6, 0, Z), "&

      "2 (BC_1, Y(3), output3, X, 6, 0, Z), "&

      "3 (BC_1, A(1), input, X), "&

      "4 (BC_1, A(2), input, X), "&

      "5 (BC_1, A(3), input, X), "&

      "6 (BC_1, OE, input, X), "&

      "6 (BC_1, *, control, 0)";

Obtaining BSDL for TI Catalog Devices

Texas Instruments makes catalog device BSDL files available via ftp download. To download a BSDL file, go to TI's IEEE 1149.1 silicon product availability listing and click on "download BSDL now" to start the ftp download process.


What Is HSDL?

Several data formats have emerged to make IEEE 1149.1 successful and well-supported by tools. This section discusses a data format for describing how IEEE 1149.1 was implemented at the board level -- HSDL, or Hierarchical Scan Description Language.

Hierarchical Scan Description Language (HSDL)

Texas Instruments developed the Hierarchical Scan Description Language (HSDL) to complement BSDL, using the same subset of VHDL statements as BSDL. HSDL picks up where BSDL stops to describe additional attributes of IEEE 1149.1 devices and how IEEE 1149.1 devices are connected at the board and system level.

HSDL uses the BSDL entity and package in new ways. Entities in HSDL are used to describe modules as well as devices. A module is any level of architecture above the device level, including boards, multichip modules, backplanes, subsystems, and systems. In addition, HSDL provides two new packages used to indicate that an entity is an HSDL device or module.

BSDL is great for describing how IEEE 1149.1 is implemented in a device, but stops there. HSDL provides a method for describing how IEEE 1149.1 devices are connected at the board, module, and system levels. HSDL serves three needs not addressed by BSDL:

  • Describes the test bus interconnections of IEEE 1149.1 at the board or module level
  • Improves ease-of-use and reduces risk during interactive design debug and verification
  • Allows descriptions of boards with dynamic and reconfigurable architectures

HSDL Module Statements

HSDL module statements use much of the same syntax as BSDL. New statements have been added to describe the members and scan paths of the module and to simplify interactive use.

  • Entity descriptions
  • Generic parameter
  • Logical Port description
  • Use statements
  • [Optional Module descriptions]
  • [Optional Port description(s)]
  • Pin Mapping(s)
  • Scan Port identification
  • [Optional Member description(s)]
  • [Optional Bus description(s)]
  • Path description
  • [Optional Member Connections]
  • [Optional Constraint Description(s)]
  • [Optional Design Warning]

Entity Descriptions -- The entity statement names the entity, such as the module name (e.g., BOARD). An entity description begins with an entity statement and terminates with an end statement.

    entity BOARD is 

      {statements to describe the entity go here}

    end BOARD;

Generic Parameter -- A generic parameter may come from outside the entity or it may be defaulted, such as a package type (e.g., "UNDEFINED").

    generic (PHYSICAL_PIN_MAP : string := ("UNDEFINED")

Logical Port Description -- The port description gives logical names to the I/O pins (system and TAP pins), and denotes their nature such as input, output, bidirectional, and so on.

    port (TDI:in bit;

      TDO:out bit;

      TMS:in bit;

      TCK:in bit);

Use Statements -- The use statement refers to external definitions found in packages and package bodies.

    use STD_1149_1_1994.all;

    use HSDL_module.all;

Pin Mapping(s) -- The pin mapping provides a mapping of logical signals onto the physical pins of a particular entity.

    attribute PIN_MAP of BOARD : entity is

    PHYSICAL_PIN_MAP;

      constant PINOUT1 : PIN_MAP_STRING :=

      "TDI:1, TDO:2, TMS:3, TCK:4, GND:5";

Scan port Identification -- The scan port identification statements define the entity's TAP.

    attribute TAP_SCAN_IN of TDI : signal is TRUE;

    attribute TAP_SCAN_OUT of TDO : signal is TRUE;

    attribute TAP_SCAN_MODE of TMS : signal is TRUE;

    attribute TAP_SCAN_CLOCK of TCK : signal is (5.0e6,

               LOW);

Members Description (Optional) -- Members represent devices or other modules that are on the module. Usually members represent components, but some boards may contain scannable daughtercards, card slots, etc. that require modules to describe them.

    attribute MEMBERS of BOARD : entity is

      "U1 (XYZ1, DW),"&

      "U2 (XYZ2, DW), ";

Bus Composition (Optional) -- Buses in an HSDL module can be built of module buses, member module buses, member device buses, and member device test registers.

    attribute BUS_COMPOSITION of BOARD : entity is

      "bus1[4] (U1.Boundary[3,0]), "&

      "bus2[4] (U2.Boundary[3,0]), ";

Path Description -- Module paths are intended to describe the netlist of TAP signals (scan paths) on the board.

     constant boardpath1 : STATIC_PATH :=

       "U1, U2";

     end BOARD;


What Is SVF?

Serial Vector format, commonly referred to as SVF, was jointly developed by Texas Instruments and Teradyne in 1991. SVF is a standard ASCII format for expressing test patterns that represent the stimulus, expected response, and mask data for IEEE 1149.1-based tests. The need for SVF arose from the desire to have vendor-independent IEEE 1149.1 test patterns that are transportable across a wide selection of simulation software and test equipment -- from design verification through field diagnostics.

Boundary-scan test execution is controlled by the sequencing of TAP signals on the pins of the devices. Each device's behavior is determined solely by the states of its TAP pins. Boundary-scan tools must maintain knowledge of the sequences required to exert certain behaviors within a device and where that device is located down the serial scan path.

SVF controls the IEEE 1149.1 test bus using commands that transition the TAP from one steady state to another. Rather than describe the explicit state of the IEEE 1149.1 bus on every TCK cycle, SVF describes it in terms of transactions conducted between stable states. for instance, the process of scanning in an instruction is described merely in terms of the data involved and the desired stable state to enter after the scan has been completed. The Capture, Update, Pause, etc. states are inferred rather than explicitly represented. the data to be scanned in, expected data out, and compare mask are all grouped in an easily understandable manner. A command is provided to support deterministic navigation of TAP states where required.

In addition to supporting higher level depictions of scan operations, SVF also supports combined serial and parallel operations. This allows SVF to accommodate ATE environments where some stimulus/response is handled via parallel I/O, and serial signals are accessed via an IEEE 1149.1-control environment.

SVF also supports the concept of scan offsets. Offsets allow a test to be applied to a component or cluster of logic embedded in the middle of a scan path. For example, assume a device exists in multiple instances on a board. Serially applied tests were generated by the designer that are available in SVF format. to reuse this test, it is necessary to put all other devices on the scan path into the bypass mode. The IEEE 1149.1 test controller must therefore comprehend the number of Instruction Register bits before and after the target device. Once in bypass, the devices introduce Data Register bits before and after the target device.

SVF allows a header and trailer to be defined once which maintains the Instruction Register and Data Registers of the non-targeted devices in the desired bypass state. No modifications are required to the SVF for the device. If the same test were targeted towards another device downstream in the scan path, this would be accommodated merely by changing the headers and trailers.

The offset approach is capable of installing any Instruction and Data Register stimulus, provided these values are constant for the entire process of applying the SVF device sequence.

SVF Structure

The SVF file is defined as an ASCII file that consists of a set of SVF statements. Statements are terminated by a semicolon (;) and may continue for more than one line. The maximum number of ASCII characters per line is 256. SVF is not case sensitive, and comments can be inserted into an SVF file after an exclamation point (!) or a pair of slashes (//).

Each statement consists of a command and parameters associated with that specific command. Commands can be grouped into three types: state commands, offset commands, and parallel commands.

State commands

State commands are used to specify how the test sequences will traverse the IEEE 1149.1 TAP state machine. The following state commands are supported:

SDR -- Scan Data Register

SIR -- Scan Instruction Register

ENDDR -- Define end state of DR scan

ENDIR -- Define end state of IR scan

RUNTEST -- Enter Run-Test/Idle state

STATE -- Go to specified stable state

TRST -- Drive the TRST line to the designated level

SDR performs an IEEE 1149.1 Data Register scan. SIR performs an IEEE 1149.1 Instruction Register scan. ENDDR and ENDIR establish a default state for the bus following any Data Register scan or Instruction Register scan, respectively. RUNTEST goes to Run-test/Idle state for a specific number of TCKs. for each of the above commands, a default path through the state machine is used. Each of these commands also terminates in a stable, nonscannable state.

STATE places the bus in a designated IEEE 1149.1 stable state. TRST activates or deactivates the optional test reset signal of the IEEE 1149.1 bus.

Offset Commands

Offset commands allow a series of SVF commands to be targeted towards a contiguous series of points in the scan path. Examples would be a sequence for executing self-test on a device, or a cluster test where al devices involved in the cluster test are grouped together. The following offset commands are supported:

HDR -- Header data for data bits

HIR -- Header data for instruction bits

TDR -- Trailer data for data bits

TIR -- Trailer data for instruction bits

HDR specifies a particular pattern of data bits to be padded onto the front of every data scan. HIR specifies the same for the front of every Instruction Register scan. These patterns need only be specified once and are included on each scan unless changed by a subsequent HDR, HIR, TDR or TIR command.

Parallel Commands

Parallel commands are used to map and apply the following commands:

PIO -- Specifies a parallel test pattern

PIOMAP -- Designates the mapping of bits in the PIO command to logical pin names

Parallel commands allow SVF to combine serial and parallel sequences. PIOMAP commands are used by parallel I/O controllers to map data bits in the command into parallel I/O channels using the ASCII logical pin name as a reference. The PIO command specifies the execution of a parallel pattern application/sample. SVF does not specify any other properties of parallel I/O such as drive, levels, or skew.

Default State Transitions

SVF uses names for the TAP states that are similar to the IEEE 1149.1 TAP state names. Below is a list of SVF equivalent names for the TAP states:

IEEE 1149.1 TAP State Name [SVF TAP State Name]

  • Test-logic-Reset [RESET]
  • Run-Test/Idle [IDLE]
  • Select-DR-Scan [DRSELECT]
  • Capture-DR [DRCAPTURE]
  • Shift-DR [DRSHIFT]
  • Pause-DR [DRPAUSE]
  • Exit1-DR [DREXIT1]
  • Exit2-DR [DREXIT2]
  • Update-DR [DRUPDATE]
  • Select-IR-Scan [IRSELECT]
  • Capture-IR [IRCAPTURE]
  • Shift-IR [IRSHIFT]
  • Pause-IR [IRPAUSE]
  • Exit1-IR [IREXIT1]
  • Exit2-IR [IREXIT2]
  • Update-IR [IRUPDATE]

Below is a listing to identify sample default paths taken when transitioning from one state to a specified new state. For example, if the current state is RESET and you select DRPAUSE as the end state, the TAP moves from RESET through IDLE, DRSELECT, DRCAPTURE, DREXIT1 to DRPAUSE. You only have to specify the current and end states and not each intermediate step.

Stable State Path Examples

    Current State    End State        State Path

    _____________________________________________

    RESET            RESET            RESET

    _____________________________________________

    RESET            IDLE             RESET

                                      IDLE

    _____________________________________________

    RESET            DRPAUSE          RESET

                                      IDLE 

                                      DRSELECT 

                                      DRCAPTURE

                                      DREXIT1

                                      DRPAUSE

    _____________________________________________

    RESET            IRPAUSE          RESET

                                      IDLE 

                                      DRSELECT

                                      IRSELECT

                                      IRCAPTURE

                                      IREXIT1

                                      IRPAUSE

    _____________________________________________

SVF Example

The following is an example SVF file:

    !   Begin Test Program

    !   Disable Test Reset line

         TRST OFF;

    !   Initialize UUT

         STATE RESET;

    !   End IR scans in DRPAUSE

         ENDIR DRPAUSE;

    !   24 bit IR header

         HIR 24 TDI (FFFFFF);

    !   3 bit DR header

         HDR 3 TDI (7) TDO (7) MASK (0);

    !   16 bit IR trailer

         TIR 16 TDI (FFFF);

    !   2 bit DR trailer

         TDR 2 TDI (3);

    !   8 bit IR scan, load BIST seed

         SDR 16 TDI (ABCD);

    !   RUNBIST for 95 TCK Clocks

         RUNTEST 95 TCK ENDSTATE IRPAUSE

    !   16 bit DR scan, check BIST status

         SDR 16 TDI (0000) TDO (1234) MASK (FFFF);

    !   Enter Test-Logic-Reset

         STATE RESET;

    ! End Test Program

The test begins by deasserting TRST. The DRPAUSE state is established as the default end state for instruction scans and data scans. Twenty four bits of header and sixteen bits of trailer data are specified for Instruction Register scans. No status bits are checked. Three bits of header data and two bits of trailer data are specified for Data Register scans.

In the example above, a single device in the middle of the scan is targeted. Notice from the 24-bit IR header (3x8-bit IR) and the 3-bit DR header (3x1-bit DR) that the targeted device has three devices before it in the scan path. From the 16-bit IR trailer (2x8-bit IR) and the 2-bit DR trailer (2x2-bit DR), the targeted device has 2 devices following it in the scan path. After the header and trailer offsets are established all subsequent scans are the concatenation of the header, scan data, and trailer bits. The targeted device supports BIST, which is initialized by scanning a hex ABCD into the selected Data Register. The BIST in the targeted device is then executed by entering the Run-Test/Idle state for 95 clock cycles. Next, the BIST result is scanned out and the status bits compared against a deterministic value to determine pass/fail.

SearchTech SupportCommentsSite MapTI&MEHome
(c) Copyright 1999 Texas Instruments Incorporated. All rights reserved.
Trademarks, Important Notice! | Privacy Policy