Hi reader!

What is a BSDL file?

A BSDL (Boundary Scan Description Language) file is a machine-readable description of how a device implements boundary scan. Its syntax is based on VHDL, and every JTAG compliant device must provide one. Boundary scan test systems, such as XJTAG, use BSDL files to determine what tests can be run on a device and how to place it into boundary scan modes (BYPASS, EXTEST, SAMPLE).

These BSDL files are normally available free of charge from the manufacturers’ website. Occasionally you may need to complete a verification step before download.

What’s inside a BSDL file?

A BSDL file typically starts with copyright and manufacturer notes, added as a comment denoted by a pair of hyphens. These are intended for the user, rather than the system and will be ignored by the test system. After these comments, there are a number of elements in an entity description, as shown in figure 1:

• Port groupings and pin mapping: Lists all device connections and maps them to pins. Multiple mappings allow one file to cover different packages. Differential signal grouping information may also be included here.

• TAP definition: Identifies which port names are used for the JTAG interface signals.

• Instruction register length and opcodes: States how long the instruction register is and which opcodes it supports. At minimum, IEEE 1149.1 requires EXTEST, SAMPLE/PRELOAD, and BYPASS (all 1s). Manufacturers may also add custom opcodes.

• IDCODE_REGISTER: A common but optional attribute that holds a 32-bit device ID (version, part number, manufacturer ID, and a required 1 as the least-significant bit).

• Register access: Defines which registers sit between TDI and TDO for each instruction. For example, "BYPASS (HIGHZ, CLAMP)" tells tools that BYPASS is selected when HIGHZ or CLAMP is used.

• Boundary scan register: Describes how individual boundary scan cells are connected, their function, safe values, and relationships.

• Optional sections: This can include compliance pins (states required for boundary scan mode), AIO_Pin_Behaviour (extra information for capacitively coupled digital signals under IEEE 1149.6) and other chip specific features.

More information on BSDL files can be found on the XJTAG website.

Common mistakes within BSDL files

The quickest way to spot potential mistakes is to load your BSDL file into your boundary scan tools. XJDeveloper, for example, will parse the file and flag up errors automatically in the main error helper pane.

If you receive a BSDL file from the chip manufacturer that doesn’t parse, the first step should always be to raise the issue with them. Editing a BSDL file yourself can sometimes help with debugging, but it should be treated as a last resort. A wrongly modified BSDL can cause misleading test results, or in the worst case, risk damage to the device or board and if there’s functionality missing in the silicon, making changes to the BSDL file won’t be able to fix it! Editing the file will only help when the feature is implemented in the device but described incorrectly in the BSDL file. With that in mind, here are some of the issues we’ve seen most often:

Unmasked ID Code Version Bits

The IDCODE_REGISTER identifies the JTAG device, split into 4 sections as shown in figure 2.

The first four digits refer to the version number of the device, with multiple versions supported by using X as a wildcard. If the rest of the code matches, but the version number is wrong, first check whether the manufacturer provides multiple versions of the file; if they don’t then it’s possible that the same BSDL file applies across multiple versions.

In this case, you can edit the version bits to “XXXX” to mask them out. This way the part number and manufacturer ID still confirm the device identity, but you are no longer checking for a specific version of the silicon. If masking the version bits leads to further issues, contact the manufacturer for clarification.

Incorrect or Missing Compliance Pin Definitions

Compliance pins must be in specific states for a device to enter boundary scan mode. Errors in this section are less common, but we have seen manufacturers provide incomplete or incorrect definitions.

If you’re having trouble checking the chain, confirm that the compliance pins on your board match the states listed in the BSDL file. Check the device datasheet or reference manual for the boundary scan section, as well as any errata, to confirm what’s required. Typical compliance pins include power-on reset (POR_B), PROG_B pins on FPGAs, TEST_MODE_EN pins on Ethernet PHYs, and various boot pins.

Missing Differential Pair Groupings

Devices with differential signals need to have the related pins grouped together in the BSDL file. If these are implemented as differential in the silicon, but missing from the port grouping section, boundary scan tools will see the pins as having an inverted short because the hardware drives the two pins in opposite directions.

If you notice a pair of differential pins being picked up as inverted shorts in the interconnectivity test, check the port grouping section of the BSDL file and ensure that the board you are testing is functioning correctly. Faults around termination resistors can often appear very similar to differential faults. If the pin grouping is missing in the BSDL file, you can modify the file to add them, but we recommend reporting the issue to the chip manufacturer too so they can correct it officially.

Mismatched AIO_Pin_Behaviour References

Some BSDL files for 1149.6 devices fail to parse due to inconsistencies in the AIO_Pin_Behaviour section. This section contains information on the ports for AC testing and starts by linking the port name and the relevant cell number, in the first example here, linking PORTA_7p with cell 13.

The problem arises when the cell number given here in the AIO_Pin_Behaviour section doesn’t match the corresponding entry in the boundary scan register details. This mismatch will cause the boundary scan tools to report an error.

According to IEEE1149.6, the input cell only needs to be defined in AIO_Pin_Behaviour when a port has more than one input cell associated with it. We recommend raising this inconsistency with the chip manufacturer so they can advise whether removing the brackets and the number within will resolve the error, or whether the cell number needs to be corrected elsewhere.

Summary

BSDL files are an essential part of boundary scan testing, but they aren’t always error-free, even when they come direct from the manufacturer. In general, you should assume a BSDL file is correct unless you have evidence otherwise. If issues do arise, the first step should be to raise them with your boundary scan tool provider or the chip manufacturer. Manual modification does carry risk and so we recommend checking very carefully with datasheets and warnings in the BSDL file itself and only make updates to the files if you are confident in your changes.

Enjoyed this update? Please forward to a colleague who may find it interesting.