UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 6664

JTAG BSDL - Does Xilinx provide configured BSDL files for configured devices?

Description

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?

解决方案


 

NOTES: 

  1. For additional information, please refer to (Xilinx Answer 15346). This Answer describes BSDLAnno, which is the primary solution for post-configured BSDL files. 
  2. The information below is applicable to all Xilinx devices. 

 

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): 

 

  1. If you perform Boundary Scan testing on an unconfigured device, a post-configuration BSDL file is not necessary; the BSDL file supplied by Xilinx suffices. 
  2. If you must perform Boundary Scan testing on a configured device, and the Boundary Scan test pattern is not derived from the BSDL file, a post-configuration BSDL file may not be necessary.  
  3. If you must perform Boundary Scan testing on a configured device, and the Boundary Scan test pattern is derived from the BSDL file, a post-configuration BSDL file is necessary.  

 

Explanation of 2 and 3 above

 

Boundary Scan test patterns are typically derived from one of two places: 

 

  • Board layout and design database 
  • Device BSDL files 

 

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. 

 

For example: 

A Boundary Scan test is performed on a configured XCV100 BG256 and pin A3 is an output in this design. 

 

Issue: 

The Boundary Scan test vectors must not drive pin A3 since this causes contention. 

 

Solution: 

  1. If the Boundary Scan test vectors are derived from board/design information, the Xilinx-supplied xcv100_bg256.bsd file works for this Boundary Scan test. This BSDL file defines pin A3 as bidirectional, but the test vectors treat the pin as an output, so no modifications to the BSDL file are necessary. 
  2. If the Boundary Scan test vectors are derived from the Boundary Scan file, the xcv100_bg256.bsd file does not work because it defines pin A3 as bidirectional. This permits the Boundary Scan test to drive pin A3 and causes contention. You must create a post-configuration BSDL file based on your design information. 

 

All Xilinx BSDL files are located on the Xilinx support Web site at: 

http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/device-models.html


 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): 

  1. Enable USER instructions as appropriate (see below). 
  2. Set the disable result of all pads as configured. 
  3. Set the safe state of boundary cells as necessary. 
  4. If necessary, rename the entity to avoid name collisions. 
  5. Modify the USERCODE value in the USERCODE_REGISTER declaration. 

 

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: 

attribute BOUNDARY_REGISTER of XCV100_PQ240 : entity is 

-- cellnum (type, port, function, safe[, ccell, disval, disrslt]) 

" 0 (BC_1, *, controlr, 1)," & 

" 1 (BC_1, PAD60, output3, X, 0, 1, PULL0)," & 

" 2 (BC_1, PAD60, input, X)," & 

" 3 (BC_1, *, controlr, 1)," & 

" 4 (BC_1, PAD59, output3, X, 3, 1, PULL0)," & 

" 5 (BC_1, PAD59, input, X)," & 

" 6 (BC_1, *, internal, X)," & 

" 7 (BC_1, *, internal, X)," & 

" 8 (BC_1, *, internal, X)," & 

" 9 (BC_1, *, controlr, 1)," & 

" 10 (BC_1, PAD57, output3, X, 9, 1, PULL0)," & 

" 11 (BC_1, PAD57, input, X)," & 

" 12 (BC_1, *, controlr, 1)," & 

 

If pin 57 has been configured as a bidirectional pin, no code modifications are required: 

-- UNCONFIGURED OR BIDIRECTIONAL PIN: 

" 9 (BC_1, *, controlr, 1)," & 

" 10 (BC_1, PAD57, output3, X, 9, 1, PULL0)," & 

" 11 (BC_1, PAD57, input, X)," & 

 

If pin 57 is configured as an input, modify it as such: 

-- PIN CONFIGURED AS AN INPUT 

" 9 (BC_1, *, internal, 1)," & 

" 10 (BC_1, *, internal, X)," & 

" 11 (BC_1, PAD57, input, X)," & 

 

If pin 57 is configured as an output, modify it as such: 

-- PIN CONFIGURED AS AN OUTPUT 

" 9 (BC_1, *, internal, 1)," & 

" 10 (BC_1, PAD57, output2, X)," & 

" 11 (BC_0, PAD57, observe_only, X)," & 

 

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: 

  1. The value in a control cell that turns off its associated drivers. 
  2. The value that an output should have during INTEST that minimizes driver current. 
  3. A preferred value to present to on-chip logic at a component input during EXTEST. 

 

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.

 

AR# 6664
创建日期 06/01/1999
Last Updated 04/06/2016
状态 Active
Type 综合文章
器件
  • FPGA Device Families
Tools
  • ISE Design Suite