Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > T&M
?
?
T&M??

Using serial vector format files to program XC9500 devices in-system on automatic test equipment and third party tools

Posted: 03 Nov 1999 ?? ?Print Version ?Bookmark and Share

Keywords:serial vector? format? files? xc9500? automatic test equipment?

/ARTICLES/1999NOV/1999NOV03_ICT_AN.PDF

XAPP067 July, 1997 (Version 1.1) 1-1 1 Summary This application note describes how to program XC9500 devices in-system, using standard Serial Vector Format (SVF) stimulus files. Xilinx Family XC9500 Introduction XC9500 devices use a standard 4-wire Test Access Port (TAP) for both In-System Programming (ISP) and IEEE 1149.1 boundary scan (JTAG) testing. Therefore, manufac- turers can reduce their overall system cost and reduce device damage due to unnecessary handling by using automatic test equipment (ATE) or boundary-scan based tools development to both program and test these devices. The XC9500 Boundary-scan architecture is shown in Figure 1. The Xilinx EZTagTM software helps make this possible by automatically generating a Serial Vector Format (SVF) file describing the programming and test algorithms required by the XC9500 devices. Most ATE platforms and boundary- scan based development tools accept SVF as a test vector input format. This application note describes the steps required to generate an SVF file and how to use this file to program and test a device. SVF Overview The original Serial Vector Format was developed jointly by Texas Instruments and Teradyne in response to a need for the exchange of boundary-scan test vectors between such tools as test generation software and ATE. At that time, usage of the IEEE standard 1149.1 was increasing but no common format or language existed to satisfy the need for a common data exchange. The developers of SVF chose a format that did not use test vectors solely to provide TCK (clock) and TMS (mode con- trol) signals to the IEEE 1149.1 TAP. Instead, the underly- ing models of the SVF format assume that all operations begin and end in stable states. This results in a much sim- pler and more concise description of the stimulus vectors. Figure 1: XC9500 Boundary Scan Architecture Using Serial Vector Format Files to Program XC9500 Devices In-System on Automatic Test Equipment and Third Party Tools XAPP067 July, 1997 (Version 1.1) Application Note ? TMS TCK . XC9500 System Logic TDI Instruction Register Data Registers I/O Pins > State Machine JTAG Boundary Scan Register TCK TDO mux . . . . . . . . . Device Test Access Port Programming and Device Using Serial Vector Format Files to Program XC9500 Devices In-System on Automatic Test Equipment and Third Party Tools 1-2 XAPP067 July, 1997 (Version 1.1) Between mid-1991 and the autumn of 1994 three revisions of SVF were developed, with the goal of creating a format that was independent of the test application vehicle. By late 1994 over 100 companies had developed SVF-based tools and at least ten vendors of CAE tools and ATE were sup- porting SVF. SVF has proven itself to be a useful and reliable format for exchanging data between the boundary-scan TAP and the software that drives it. SVF Specification For the purposes of XC9500 ISP, only three records of the thirteen SVF records that describe the standard are needed. Those three records are discussed in this section. An SVF file contains a set of ASCII statements. The maxi- mum number of characters allowed on a line is 256, how- ever one SVF statement can span more than one line. Each statement consists of a command and its associated parameters, terminated by a semicolon. SVF is not case sensitive and comments are indicated by an exclamation point (!) or a pair of slashes (//) at the beginning of a line, terminated by a carriage return. Scan data within a statement is expressed in hexadecimal and is always enclosed in parenthesis. The scan data can- not specify a data string that is larger than the specified bit length; the Most Significant Bit (MSB) zeros in the hex string are not considered when determining the string length. The bit order for scan data defines the LSB (right- most bit) as the first bit scanned into the device for scan data specified by the TDI and SMASK keywords, and is the first bit scanned out for data specified by the TDO and MASK keywords. The following SVF Commands are supported by the XC9500 EZTag software: ? SDR (Scan Data Register). ? SIR (Scan Instruction Register). ? RUNTEST. In each of the following command descriptions the parame- ters are mandatory. Optional parameters are enclosed in brackets ([ ]). Variables are shown in italics. Parenthesis "( )"are used to indicate hexadecimal values. A scan operation is defined as the execution of an SIR or SDR command and any associated header or trailer com- mands. SDR, SIR SDR length [TDI (tdi)] [TDO (TDO)] [MASK (msk)] [SMASK (smask)][PIO (pio)]; SIR length [TDI (tdi)] [TDO (TDO)] [MASK (msk)] [SMASK (smask)][PIO (pio)]; These commands specify a scan pattern to be applied to the target scan registers. The SDR command (Scan Data Register) specifies a data pattern to be scanned into the target device Data Register. The SIR command (Scan Instruction Register) specifies a data pattern to be scanned into the target device Instruction Register. Parameters: length -- A 32-bit decimal integer specifying the num- ber of bits to be scanned. [TDI (tdi)] -- (optional) This specifies the value to be scanned into the target, expressed as a hex value. If this parameter is not present, the value of TDI to be scanned into the target device will be the TDI value specified in the previous SDR/SIR statement. If a new scan command is specified, which changes the length of the data pattern with respect to a previous scan, the TDI parameter must be specified, otherwise the default TDI pattern is undetermined and is an error. [TDO (tdo)] -- (optional) This specifies the test values to be compared against the actual values scanned out of the target device, expressed as a hex string. If this parameter is not present, no comparison will be per- formed. If no TDO parameter is present, the MASK will not be used. [MASK (mask)] -- (optional) This specifies the mask to be used when comparing TDO values against the actual values scanned out of the target device, expressed as a hex string. A "0" in a specific bit position indicates a "don't care" for that position. If this parame- ter is not present, the mask will equal the previously specified MASK value specified for the SIR/SDR state- ment. If a new scan command is specified which changes the length of the data pattern with respect to a previous scan, the MASK parameter must be specified, otherwise the default MASK pattern is undefined and is an error. If no TDO parameter is present, the MASK will not be used. [SMASK (smask)] -- (optional) This specifies which TDI data is "don't care", expressed as a hex string. A "0" in a specific bit position indicates that the TDI data in that bit position is a "don't care". If this parameter is not present, the mask will equal the previously specified SMASK value specified for the SDR/SIR statement. If a new scan command is specified which changes the length of the data pattern with respect to a previous scan, the SMASK parameter must be specified, other- wise the default SMASK pattern used is undefined and is an error. The SMASK will be used even if the TDI parameter is not present. Example: SDR 24 TDI (000010) SMASK (0) TDO (818181) MASK (FFFFFF); SIR 16 TDO (ABCD); XAPP067 July, 1997 (Version 1.1) 1-3 1 RUNTEST RUNTEST run_count TCK; This command forces the target IEEE 1149.1 bus to the Run- Test/Idle state for a specific number of TCK clock periods. This can be used to specify latency periods when operating the TAP. Parameters: run_count -- The number of TCK clock periods that the 1149.1 bus will remain in the Run Test/Idle state, expressed as a 32 bit unsigned number. Example: RUNTEST 1000 TCK; A Sample XVF File is shown as follows: Using EZTag to generate an SVF file This procedure shows how to create an SVF file; it assumes that the Xilinx XACT version 6.0.0 software, or newer, which includes the XC9500 fitter and the EZTag software, is being used. 1. Create the design using XABEL-CPLD or any compati- ble third-party design entry tool. 2. Fit the design and save it to a JEDEC output file. 3. Invoke the EZTag software from the XACT command line using the following command: eztag -svf The following message appears: Xilinx (R) EZTAG XC9500-CPLD-6.0.0 - JTAG Boundary-Scan Download Copyright (C) Xilinx Inc. 1991-1995. All Rights Reserved. ---------------------------------------- SVF GENERATION MODE. EZTAG? 4. At the EZTAG? Prompt type the following command: part deviceType1:designName1 deviceType2:designName2 deviceTypeN:designNameN where designName is the name of the design to trans- late into SVF. Multiple deviceType:designName pairs are separated by spaces. This command defines the JTAG device chain, from one to any number of devices. The parts specified in the part command should be arranged in order beginning with the first device to receive TDI and ending with the last device to output TDO. Note: For any non-XC9500 part in the JTAG chain make certain that the BSDL file for the specified part is available along the XACT path and is called device- Type.bsd (e.g., 4003pc84.bsd for a XC4003 in the PC84 package). 5. Enter any one of the following commands: erase designName -- generates an SVF file that spec- ifies the bit sequence to erase the specified part. verify designName [-j jedecFileName] -- generates an SVF file that specifies the bit sequence to read back the device contents and compares it against the con- tents of the specified JEDEC file. program [-b] designName [-j jedecFileName] -- gen- erates an SVF file that specifies the bit sequence to program the specified part from a JEDEC file named designName.jed (or alternately, the JEDEC file name specified after the "-j"). The program command options add the following functionality: -b -- When using new devices shipped from the factory, this switch skips the erasure process that usually pre- cedes programming. Erasure is not necessary for a device that has not been previously programmed. 6. Exit EZTag by entering the following command: quit NOTE: The SVF file will be named designName.svf, and will be created in the current working directory (the directory in which EZTAG is being run). Consecutive operations on the same designName file will overwrite the SVF file each time. The SVF file contains all data and commands necessary to perform the specified function. SVF Interpretation The simplicity of SVF is also one of its major weaknesses. Much of the behavior of SVF, while running, is left unspecified by the standard. In order to optimize SVF stimulus for an application, the interpretations of some operations must be defined more precisely. RUNTEST TCK Many ATE boundary-scan tool manufacturers prefer not to generate bursts of TCK activity because this results in sig- nificantly increased test vector file sizes. This increases the overall test cost and can cause the vector set to run ineffi- ciently. Because the RUNTEST record is used to wait for something to happen, the TCK burst specified is generally interpreted as a time value. The favored interpretation is ! Begin Test Program TRST OFF; !disable test reset line ENDIR IDLE; !End IR scan in IDLE SIR 8 TDI (FE) MASK (FF) SDR 14 TDI (3afe) MASK (3ff) TDO (0003) SMASK (3ff) RUNTEST 100 TCK !End test program Using Serial Vector Format Files to Program XC9500 Devices In-System on Automatic Test Equipment and Third Party Tools 1-4 XAPP067 July, 1997 (Version 1.1) that the number represents a wait time in microseconds. This is how the EZTag-generated SVF files should be inter- preted. SDR predicted TDO values The SVF specification describes a method for specifying predicted TDO values. It does not, however, specify actions to be taken when the predicted TDO value does not equal the expected values. When using Xilinx XC9500 parts, the TDO values predicted reflect the status of the just completed operation (which could be an erase or a program operation). If the status is not the success status (which is the value predicted as the TDO value in the generated SVF file) then the following 1149.1 TAP controller state transition sequence should be followed (assuming the TDO validation failure is detected in the EXIT1-DR state): 1. EXIT1-DR 2. PAUSE-DR 3. EXIT2-DR 4. SHIFT-DR 5. EXIT1-DR 6. UPDATE-DR 7. RUN-TEST/IDLE The above state transition sequence is illustrated in the 1149.1 TAP state diagram in Figure 2. The net effect of the state transition sequence is to nullify the just-shifted-in programming or erase data and re-apply the previous program or erase data. Note that the applica- tion interpreting the SVF must acknowledge this by not advancing beyond the current SVF record. Figure 2: Test Access Port State Diagram Select-DR-Scan Capture-DR Shift-DR Exit1-DR Pause-DR Exit2-DR Update-DR Select-IR-Scan Capture-IR Shift-IR Exit1-IR Pause-IR Exit2-IR Update-IR Test-Logic-Reset Run-Test/Idle 1 0 1 0 1 0 1 1 1 0 0 1 0 1 0 1 0 1 1 1 0 0 0 1 0 0 0 0 1 0 1 1 Exception Handling Loop XAPP067 July, 1997 (Version 1.1) 1-5 1 Figure 3: SVF File Fragment Illustrating ATE Flow Using the SVF file as an example, as shown in Figure 3, the required operation should then be as follows: 1. When reading an SDR instruction with a TDO specified (like the second one in Figure 3), the predicted TDO value must match the value output from the device on the tester. If it does not match, then the failure recovery loop is executed. In the RUN-TEST/IDLE state a pause is inserted for the amount of time specified in the previ- ously applied RUNTEST instruction. 2. On exit from the RUNTEST instruction, re-apply that same SDR record (in this case the second one in the file) and test the TDO value again. 3. If the TDO matches the expected value, the TAP state machine is transitioned back to RUN-TEST/IDLE the normal way (via EXIT1-DR and UPDATE-DR) and is applied to the next SDR record. 4. This "recovery loop" is to be attempted no more than 32 times. If the TDO value does not match after 32 times, the part is considered defective and the process should abort with some failure indication supplied to the user. Normally, less than 1% of the addresses fail the TDO check and require the additional erase or program time associ- ated with execution of the failure recovery loop. Pseudo-code Algorithm for SVF-based ISP The following pseudo-code describes the sequence of operations that should be used in interpreting the SVF file on a generic SVF processor (ATE or boundary-scan devel- opment tool). 1. Go to Test-Logic-Reset state 2. Go to Run-Test Idle state 3. Read SVF record 4. if SIR record then go to Shift-IR state Scan in 5. else if SDR record then set to 0 store as store as 6. go to Shift-DR state scan in if is specified then if does not equal then if > 32 then LOG ERROR go to Run-Test Idle state go to Step 3 end if go to Pause-DR go to Exit2-DR go to Shift-DR go to Exit1-DR go to Update-DR go to Run-Test/Idle increment by 1 pause microseconds go to Step 6) end if else go to Run-Test Idle state go to Step 3 endif 7. else if RUNTEST record then pause tester for microseconds store as end if // First SDR record SDR 27 TDI (000003fe) SMASK (07ffffff); // Just apply the value - no test for TDO RUNTEST 160000 TCK; // Wait for 160 msec. // Second SDR record SDR 27 TDI (008003fe) SMASK (07ffffff) TDO (00000003) MASK (00000003); // Apply value to TDI read TDO test for concurrence // if not as expected do "failure recovery loop" - hold // at this SDR instruction. RUNTEST 160000 TCK; // Wait for 160 msec // Third SDR record SDR 27 TDI (010003fe) SMASK (07ffffff) TDO (00000003) MASK (00000003); RUNTEST 160000 TCK; // Wait for 160 msec // Fourth SDR record SDR 27 TDI (018003fe) SMASK (07ffffff) TDO (00000003) MASK (00000003); RUNTEST 160000 TCK; // Wait for 160 msec Using Serial Vector Format Files to Program XC9500 Devices In-System on Automatic Test Equipment and Third Party Tools 1-6 XAPP067 July, 1997 (Version 1.1) Conclusion By using the EZTag-generated SVF files it is possible to streamline manufacturing flows by programming XC9500 parts on automatic test equipment and third party bound- ary-scan tools. This allows integration of the program and test steps of the system manufacturing process. This inte- gration will result in higher system yields, better manufac- turability, and simpler part inventory management. References Serial Vector Format Specification, Rev C., Texas Instru- ments. The Boundary-Scan Handbook, Kenneth Parker, Klewer Academic Publishers, 1994. IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Std 1149.1-1990 (including IEEE Std 1149.1a-1993)




Article Comments - Using serial vector format files to ...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top