Xilinx BSDL files represent the Boundary Scan behavior of an unconfigured device. When do I need to modify the BSDL file to reflect post-configuration device behavior? What modifications must be made to the BSDL file, and why?
A configured BSDL file represents a Xilinx device containing my design information. How do I obtain a BSDL file based on the design loaded in the part?
Xilinx provides BSDL files that describe the Boundary Scan behavior of the device prior to configuration. For example, most I/Os are described as bidirectional pins.
In most cases, the BSDL files provided by Xilinx meet all Boundary Scan requirements. Use the following guidelines to help you determine whether or not to modify your BSDL file to reflect post-configuration behavior (a post-configuration BSDL file):
Explanation of 2 and 3 above:
Boundary Scan test patterns are typically derived from one of two places:
On a configured device, the test pattern must have information on whether each I/O on the device is an input, output, or bidirectional pin. In some cases, this information can be derived from the board layout. When the BSDL file is used to determine this, the BSDL file supplied by Xilinx is not sufficient because it reports all I/Os as bidirectional.
Additionally, a post-config BSDL file may be required when differential I/Os are used. In general, Boundary Scan tests on designs that use differential I/Os must be performed after the FPGA is configured.
A Boundary Scan test is performed on a configured XCV100 BG256 and pin A3 is an output in this design.
The Boundary Scan test vectors must not drive pin A3 since this causes contention.
All Xilinx BSDL files are located on the Xilinx support Web site at:
Creating a Post-configuration BSDL File
IMPORTANT NOTE: Please refer to (Xilinx Answer 15346) for the most current information on how to modify BSDL files to reflect post-configuration behavior. There are some discrepancies between the information provided in Answer 15346 and the information provided here. Answer 15346 contains the most current information.
The released BSDL files match JTAG behavior before and after configuration. The BSDL file without any modifications defines all I/Os as 3-state-capable bidirectional pins.
After configuration, most pins are usually configured as input or output, not 3-state-capable bidirectional. If you need a BSDL file that matches the behavior of the chip after your design has been loaded, certain alterations are necessary. Perform the following steps to create such a BSDL file for Virtex (other device families may require more or fewer steps to generate the file).
To create a post-configuration BSDL file (quoted exactly from actual BSDL files):
Explanation of above instructions:
1) Enable USER instructions as appropriate.
If you do not use the user instructions, no modifications are needed. If you use either USER1 or USER2, include appropriate entries in the REGISTER_ACCESS description. For more information, see Supplement (B) to IEEE Std 1149.1
2) Set the disable result of all pads as configured.
The disable result is the value of the signal when it is disabled. It is specified in the BOUNDARY_REGISTER section of the BSDL file.
If pull-up = NO and pull-down = NO, the disable result value is Z.
If pull-up = YES and pull-down = NO, the disable result value is PULL1.
If pull-up = NO and pull-down = YES, the disable result value is PULL0.
Unused pads are PULL0.
The following three BSDL code snippets illustrate the procedure for modifying the BOUNDARY_REGISTER section. For this example, code has been used from Revision: 1.2 of xcv100_pq240.bsd.
The untouched code is as follows:
If pin 57 has been configured as a bidirectional pin, no code modifications are required:
If pin 57 is configured as an input, modify it as such:
If pin 57 is configured as an output, modify it as such:
Repeat these modifications for every configured pin in your design.
3) Set the safe state of boundary cells as necessary.
The safe bit supplies a value that should be loaded when board-level test generation software might otherwise choose a value randomly (it is not forcing).
Example uses of the safe bit are:
It is not necessary to change the control cells (which correspond to the 3-state pin of the pad) that already have the proper value. The output and input values are design-dependent. Knowledge of the your application is necessary to set these. (They cannot be automatically set based solely on the .ncd file.)
4) If necessary, rename the entity to avoid name collisions.
If the entity name used in the BSDL file causes a collision with other BSDL or VHDL files, you must rename the entity.
5) Modify the USERCODE value in the USERCODE_REGISTER declaration.
Fill in the USERCODE value supplied during the BitGen process you are using for this function. A common method of modifying BSDL files to represent a configured device is to create a script that implements these changes.