Introduction
As miniaturization of PCBs became more desirable, denser (or layered) printed circuit boards began to dominate the market. Testing electrical connectivity between devices posed a huge problem because board density and complex layering prevented the IC pins from being physically probed. The Joint Test Action Group (JTAG) developed a solution: boundary scan.
The Joint Test Action Group originally began with participation from just European electronics companies in the mid-80s. As they sought to devise a specification for boundary scan testing, North American companies joined in the effort and the consortium gained sponsorship from the IEEE.
By 1990, that specification was ready to become the standard for boundary scan test. It was published as IEEE Std. 1149.1 and remains the foundation for boundary scan architecture. In 1994, an addition to the standard was made, which contained the Boundary Scan Description Language, more commonly known as BSD which is a subset of VHDL. The BSDL IEEE supplement to 1149.1 describes the logic content of boundary scan compliant devices.
Texas Instruments was a key player in the original JTAG consortium. While much of the following information has been obtained from TI’s Test Symposiums, the full IEEE 1149.1 standard is available for purchase at http://standards.ieee.org/findstds/standard/1149.1-2001.html
When and How is BSDL Used?
When boundary-scan compliant devices are incorporated into a board design, these devices are organized into “chains.” Scan chains are the foundation for board-level and system-level tests. These tests are used to detect and diagnose structural faults, such as opens and shorts, stuck-at faults, etc.
Automated tools, such as Flynn Systems’ onTAP, are used to generate test programs for the boards. The two most important inputs are the BSDL files for all the boundary scan devices on the board and the board netlist. Where the BSDL file tells how the boundary scan TAP pins, TAP instructions, device pins and boundary register pins and cells are all related, the netlist file describes the interconnects between the devices on the board.
onTAP reads the BSDL file and the board netlist file to automatically generate test programs that will detect and report faults to the pin level. In addition, onTAP provides a BSDL Syntax Check. The onTAP Syntax Check compares syntax of the loaded BSDL file to the syntax rules of the IEEE Std 1149.1 specifications and alerts the user to possible errors.
Why A New Language?
In a word, consistency. Having a standard modeling language, such as BSDL, for development of boundary scan devices provided consistency throughout the electronics industry. Silicon vendors use BSDL to model their boundary scan devices, automation tool vendors then use BSDL to develop their tools and end-users can create boundary scan tests with the use of BSDL.
Additionally, BSDL allows users to provide a description of how boundary scan is implemented in any given device. This is important because chip designers may apply the standard in slightly different ways, but using BSDL assures consistency.
What is the language of BSD?
BSDL is a formal text file representation of how the boundary scan TAP pins, TAP instructions, device pins and boundary register pins and cells are all related. The image below is visual depiction of the BSDL text file.
The BSDL defines how the data is transported, for example how the device captures, shifts and updates the data. This information can then be used to define the test capability.
What’s in a BSDL File?
Typically, BSDL files contain the following elements:
- Entity descriptions—identifies the device or a section of its functionality.
- Generic Parameter—specifies package type
- Logical Port Description—lists connections on the device and describes its attributes (e.g. input, output, bi-directional, linkage, etc. )
- Use Statements—refers to the IEEE 1149.1 standard package external definitions found in packages and package bodies.
- Component Conformance Statement– indicates the latest issue of the IEEE Std 1149.1 to which the device conforms.
- Pin Mappings—maps logical signals onto the physical pins in a particular device package
- Scan Port Identification—defines the pins in the device’s Test Access Port (TAP) that are used for boundary scan implementation. These pins include TDI, TDO, TMS, and TRST, if used.
- Instruction Register Description—identifies signals used for accessing JTAG device modes. OR identifies device-dependent characteristics of the Instruction Register
- Optional Register Description—identifies the values captured in the device identification register for the optional IDCODE and USERCODE instructions, if supported.
- Register Access Description—defines which register is placed between TDI and TDO for each JTAG instruction
- Boundary Register Description—is a list of boundary-scan cells with information on cell type and associated control
Sample BSDL Instructions
Entity Descriptions—a statement that begins with naming the entity (in this example device XC5VLX50_FF76) and terminates with an end statement:
entity XC5VLX50_FF676 is {statements to describe entity go here}
end XC5VLX50_FF676;
Generic Parameter—a value such as a package type or can be a parameter that can come from outside the current entity:
generic (PHYSICAL_PIN_MAP : string := “FF676” );
Logical Port Description—gives logical names to the I/O pins (system and TAP) and denotes their nature, such as input, output, bi-directional, linkage, etc.
port (
PROG_B: in bit;
RDWR_B_P18: in bit;
R_FUSE_T18: linkage bit;
TCK: in bit;
TDI: in bit;
TDN_R13: linkage bit;
TDO: out bit;
TDP_R14: linkage bit;
TMS: in bit;
Use Statements—refers to the IEEE 1149.1 standard package external definitions found in packages and package bodies:
use STD_1149_1_2001.all;
Component Conformance Statement—indicates the latest issue of IEEE Std 1149.1 to which the device conforms:
attribute COMPONENT_CONFORMANCE of XC5VLX50_FF676 : entity is
“STD_1149_1_2001”
Pin Mapping—maps logical signals onto the physical pins in a particular device package:
attribute PIN_MAP of XC5VLX50_FF676 : entity is PHYSICAL_PIN_MAP;
constant FF676: PIN_MAP_STRING:=
“AVDD_M14:M14,” &
“AVSS_M13:M13,” &
“CCLK_J10:J10,” &
“CS_B_N18:N18,” &
“DONE_K10:K10,” &
“DOUT_BUSY_W11:W11,” &
“D_IN_K11:K11,” &
“GND:(A1,A6,A11,A16,A21,A26,B3,B8,B13,B18,” &
Scan Port Identification— defines the pins in the device’s Test Access Port (TAP) that are used for boundary scan implementation. These pins include TDI, TDO, TMS, and TRST, if used.
attribute TAP_SCAN_IN of TDI : signal is true;
attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;
attribute TAP_SCAN_CLOCK of TCK : signal is (33.0e6, BOTH);
Instruction Register Description—identifies the device dependent characteristics of the instruction register.
attribute INSTRUCTION_LENGTH of XC5VLX50_FF676 : entity is 10;
attribute INSTRUCTION_OPCODE of XC5VLX50_FF676 : entity is
“EXTEST (1111000000),” &
“RESERVED1 (1111111100),” &
“RESERVED2 (1111111101),” &
“SAMPLE (1111000001),” &
Optional Register Description—identifies the values captured in the device identification register for the optional IDCODE and USERCODE instructions, if supported.
attribute IDCODE_REGISTER of XC5VLX50_FF676 : entity is
“XXXX” & — version
“0010100” & — family
“010010110” & — array size
“00001001001” & — manufacturer
“1”; — required by 1149.1
Register Access Description—defines which register is placed between TDI and TDO for each JTAG instruction.
attribute REGISTER_ACCESS of XC5VLX50_FF676 : entity is
— “<reg_name>[<length>] (USER1),” &
— “<reg_name>[<length>] (USER2),” &
— “<reg_name>[<length>] (USER3),” &
— “<reg_name>[<length>] (USER4),” &
“BYPASS (HIGHZ,BYPASS),” &
“DEVICE_ID (USERCODE,IDCODE),” &
“BOUNDARY (SAMPLE,PRELOAD,EXTEST)”;
Boundary Register Description—is a list of boundary-scan cells with information on cell type and associated control.
attribute BOUNDARY_LENGTH of XC5VLX50_FF676 : entity is 1722;
attribute BOUNDARY_REGISTER of XC5VLX50_FF676 : entity is
— cellnum (type, port, function, safe[, ccell, disval, disrslt])
” 0 (BC_1, *, internal, X),” &
” 1 (BC_1, *, internal, X),” &
” 2 (BC_1, *, internal, X),” &
” 3 (BC_1, *, internal, X),” &
” 4 (BC_1, *, internal, X),” &
” 5 (BC_1, *, internal, X),” &
” 6 (BC_1, *, internal, X),” &
” 7 (BC_1, *, internal, X),” &
” 8 (BC_1, *, internal, X),” &
” 9 (BC_2, *, internal, 1),” & — PAD560.T
” 10 (BC_2, *, internal, X),” & — PAD560.O
How to Get BSDL Files
Most BSDL files are available from the manufacturer’s web site. We have provided links to some of the manufacturers’ sites. The links in light blue will point to the list of BSDL files. The links in dark blue will point to the company’s home page where search is available; use the term BSDL or BSDL Files.
Over the years, many companies have either sold divisions or merged with other companies. We have provided the latest information as was available to us.
When selecting your dog note BSDL file, we encourage you to make certain that you have the latest version.
Altera
Analog Devices
AMD
Atmel
Broadcom
Avago—LSI—PLX—
Cypress Semiconductor
Infineon
Intel
Lattice Semiconductor
Macom
Formerly Mindspeed
Maxim Integrated
Micron
Microsemi
Actel
NXP
Freescale
Motorola
Phillips
PMC Sierra
Renesas
Silicon Labs
Texas Instruments
National Semi
Xilinx
Technical Support
Should you have any questions about the BSDL files and how onTAP uses the, do not hesitate to contact Flynn System’s Technical Support team.
Technical Support is available by telephone or by email, 8:30 a.m. – 5:00 p.m., EST. Contact Support by:
Telephone: +1 (603) 598-4444
Email: support@flynnsystems.com
0 Comments