jedec2.txt

JEDEC Standard Number 3A

This section defines a format for the transfer of information between a data 
preparation system and a logic device programmer. JEDEC format provides for, 
but is not limited to, the transfer of fuse, test, identification, and comment 
information in an ASCII representation, and defines the "intermediate code" 
between device programmers and data preparation systems. It does not define 
device architecture nor does it define programming algorithms or the device 
specific information for accessing the fuses or cells. 

Note: This section represents a Data I/O-specific implementation 
      of JEDEC Standard No. 3A. 

The standard includes a transmission protocol based on traditional PROM 
formats that allow a device programmer to share a computer serial port with a 
terminal.  The protocol is not a complete communications protocol and does not 
do retries or error correction.  This protocol is not required if the device 
programmer has local storage, such as a floppy disk. 

Field programmable logic devices may require more testing than programmable 
memories, so the standard defines a functional testing format. This test 
vector format is not a general purpose parametric test language. The following 
figure shows an example of a PLD Data File. 

<STX> File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 
QP20* QF448* QV8* 
F0* X0* 
L001111101111111111111111111111*
L281011111111111111111111111111*
L561110111111111111111111111111*
L120101011101111011111111111111*
L240101011110111011111111111111*
L360101011101110111111111111111*
V0001000000XXXNXXXHHHLXXN*
V0002010000XXXNXXXHHHLXXN*
V0003100000XXXNXXXHHHLXXN*
V0004110000XXXNXXXHHHLXXN*
V0005111000XXXNXXXHLHHXXN*
V0006111010XXXNXXXHHHHXXN*
V0007111100XXXNXXXHHLHXXN*
V0008111110XXXNXXXLHHHXXN*
C124E*<<ETX>>8A76

SUMMARY OF PROGRAMMING AND TESTING FIELDS

The programming and testing information is contained in various fields. To 
comply with the standard, the device programmer, tester, and development 
system must provide and recognize certain fields. The following table lists 
the field identifiers and descriptions. 

Identifier	Description

(n/a)    Design specification
N        Note
QF       Number of fuses in device
QP       Number of pins in test vectors ***
QV       Maximum number of test vectors ***

F        Default fuse state *
L        Fuse list *
C        Fuse checksum

X        Default test condition **
V        Test vectors **
P        Pin sequence **

D        Device (obsolete)
G        Security fuse
R,S,T    Signature analysis
A        Access time

*        Programmer must recognize
**       Tester must recognize
***      Development system must provide

SPECIAL NOTATIONS AND DEFINITIONS

Notation Conventions

In addition to the descriptions and examples, this appendix uses the Backus-
Naur Form (BNF) to define the syntax of the data transfer format. BNF is a 
shorthand notation that follows these rules: 

     "::=" means "is defined as".

     Characters enclosed by single quotes are literals (required).

     Angle brackets enclose identifiers.

     Square brackets enclose optional items.

     Braces (curly brackets) enclose a repeated item. The item 
     may appear zero or more times.

     Vertical bars indicate a choice between items.

     Repeat counts are given by a :n suffix. For example, a six-digit 
     number would be defined as "<number>" ::= <digit>:6."

For example, in words, the definition of a person's name reads:

The full name consists of an optional title followed by a first name, a middle 
name, and a last name. The person may not have a middle name or may have 
several middle names. The titles consist of: Mr., Mrs., Ms., Miss, and Dr. 

BNF syntax:

     full name>>::=[<<title>>] <<f.name>> {<<m.name>>} <<l.name>>

     <title> ::= 'Mr.' | 'Mrs.' | 'Ms.' | 'Miss' | 'Dr.'<R>

Examples:

     Miss Mary Ann Smith
     Mr. John Jacob Joseph Jones
     Tom Anderson

BNF Rules and Definitions

The following standard definitions are used throughout the rest of 
this appendix:

     <digit> ::=		| '0' | '1' | '2' | '3' | '4'
                  | '5' | '6' | '7' | '8' | '9'

     <hex-digit> ::= <digit> | 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
     <binary-digit> ::=  '0' | '1'

     <number> :: = <digit> {<digit>}

<del> ::= <space> | <carriage return>

<delimiter> ::= <del> {<del>}

<printable character> ::= <ASCII 20 hex ... 7E hex>

<control character> ::= <ASCII 00 hex ... 1F hex>
                    |   <ASCII 7F hex>

<STX>               ::= <ASCII 02 hex>

<ETX>               ::= <<ASCII 03 hex>

<carriage return>   ::= <ASCII 0D hex>

<line feed>         ::= <ASCII 0A hex>

<space>             ::= <ASCII 20 hex> | ' '

<valid character>   ::= <printable character>
                    |   <carriage return> | <line feed>

<field character>   ::= <ASCII 20 hex ... 29 hex>
                    |   <ASCII 2B hex ... 7E hex>
                    |   <carriage return> | <line feed>

TRANSMISSION PROTOCOL

Protocol Syntax

This STX-ETX protocol is based on traditional PROM formats that allow a device 
programmer to share a serial computer port with a terminal. The transmission 
consists of a start-of-text (STX) character, various fields, and end-of-text 
(ETX) character, and a transmission checksum. The character set consists of 
the printable ASCII characters and four control characters (STX, ETX, CR, LF). 
Other control characters should not be used because they can produce 
undesirable side-effects in the receiving equipment. 

Syntax of the transmission protocol:

<format> ::= <STX> {<field>} <ETX> <xmit checksum>

Computing the Transmission Checksum

The transmission checksum is the 16 bit sum (that is, modulo 65,535) of all 
ASCII characters transmitted between and including the STX and ETX.  The 
parity bit is excluded in the calculation. 

Syntax of the transmission checksum:

<xmit checksum> ::= <hex-digit>:4  

   random text <return><line feed>                             = 0000
   <STX>TEST*<return><line feed>       02+54+45+53+54+2A+0D+0A = 0183
   QF0384*<return><line feed>       51+46+30+33+38+34+2A+0D+0A = 01A7
   F0* <return><line feed>                46+30+2A+20+20+0D+0A = 00F7
   L10 101*<return><line feed>   4C+31+30+20+31+30+31+2A+0D+0A = 01A0
   <ETX>05C4 <return> random text                           03 = 0003
                                                                 ----
                                                                 05C4

Disabling the Transmission Checksum

Some computer operating systems do not allow the user to control what 
characters are sent, especially at the end of a line. The receiving equipment 
should always accept a dummy value of "0000" as a valid checksum. This dummy 
checksum is a method of disabling the transmission checksum. 

DATA FIELDS

General Field Syntax

In general, each field in the format starts with an identifier, followed by 
the information, and terminated with an asterisk. For example, "C1234*" 
specifies that the checksum of the fuse data is 1234. The design specification 
header does not have an identifier and must be the first field in the 
transmission, immediately followed by the STX character. 

Syntax of fields:

<field>                ::= [<delimiter>] <field identifier>
                           {<field character>} '*'

<field identifier>     ::= | 'A' | 'C' | 'D' | 'F' | 'G'
                           | 'L' | 'N' | 'P' | 'Q' | 'R'
                           | 'S' | 'T' | 'V' | 'X'

<reserved identifier>  ::= | 'B' | 'E' | 'H' | 'I' | 'J'
                           | 'K' | 'M' | 'O' | 'U' | 'W'
                           | 'Y' | 'Z'

Field Identifiers

Each field begins with a single character identifier that identifies the field 
type. Multiple character identifiers can be used to create subfields (that is, 
"A1", "A$", or "AB3"). The field is terminated with an asterisk. Therefore, 
asterisks cannot be embedded within the field. While not required, carriage 
returns and line feeds should be used to improve the readability of the 
format. Reserved identifiers currently have no function and are reserved for 
future use. Receiving equipment should ignore fields starting with reserved 
identifiers. The meanings of the field identifiers are given in the following 
table. 

A-   Access Time             N   Note
B-   *                       O   *
C-   Checksum                P   Pin sequence
D-   Device type             Q   Value
E-   *                       R   Resulting vector
F-   Default fuse state      S   Starting vector
G-   Security fuse           T   Test cycles
H-   *                       U   *
I    *                       V   Test vector
J-   *                       W   *
K-   *                       X   Default test condition
L-   Fuse list               Y   *
M-   *                       Z   *

     * Reserved for future use

COMMENT AND DEFINITION FIELDS

Design Specification Field

The design specification is the first field in the format. It must be included 
and it does not have an identifier to signal its start. An asterisk terminates 
the field. The contents of the design specification are not defined but should 
consist of: 

     User's name and company

     Date, part number, and revision

     Manufacturer's device number

     Other information

Syntax of the Design Specification:

<design specification> ::= {<field character>} '*'

For example,

File for PLD 12S8 
Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001
Joe Engineer Advance Logic Corp *

If none of the above information is required, a blank field consisting of the 
terminating asterisk is a valid design specification. 

Note Field (N)

The note field is used to place notes and comments in the data file. The note 
field(s) may appear anywhere in the file and the receiving equipment may 
ignore this field. 

Syntax of the Note Field:

<note> ::= 'N' <field characters> '*'

For example,

N Following vectors were modified for ACME 123 tester*

Device Definition Field (D) (Obsolete)

This field is now obsolete. It has been eliminated to ensure 
that the format is device and technology independent.

Value Field 
(QF, QP, QV)

The Q field expresses values or limits which must be provided to the receiving 
equipment. The following three subfields are defined: 

     The F subfield for the number of fuses

     The P subfield for the number of pins or test conditions in the test 
     vector 

     The V subfield for the maximum number of test vectors

These values enable the receiving device to efficiently allocate memory and 
perform certain calculations. The QF field tells the receiving equipment how 
much memory to reserve for fuse data, the number of fuses to set to the 
default condition, and the number of fuses to include in the fuse checksum. 

The value fields must occur before any device programming or testing fields in 
the data file. Files with only testing fields do not require the QF field and 
files with only programming fields do not require the QP and QV fields. 

Syntax for Value Fields:

   <fuse limit>       := 'QF' <number> '*'

   <number of pins>   ::='QP' <number> '*'

   <vector limit>     ::='QV' <number> '*'

For example,

   QF1024*    (Indicates device has 1024 fuses)
   QP24*      (Indicates device has 24 pins)
   QV250*     (Indicates a maximum of 250 test vectors)

DEVICE PROGRAMMING FIELDS

Syntax and Overview

Each fuse or cell of a device is assigned a decimal number and has two 
possible states: a zero, specifying a low resistance link (a logical 
connection between two points); or a one, specifying a high resistance link 
(no logical connection between two points). The fuse numbers start at zero and 
are consecutive to the maximum fuse number. For example, a device with 2048 
fuses would have fuse numbers between 0 and 2047. Fuse information describing 
the state of each fuse in the device is given by three fields. All user 
programmable fuses or cells may be specified with an L field. There are no 
separate fields for control terms or architecture fuses. 

Syntax of Fuse Information fields:

   <fuse information>  ::=	[<default state>] <fuse list>
                 {<fuse list>}   [<fuse checksum>]

   <default state> ::=  'F' <binary-digit> '*'

   <fuse list>     ::=  'L' <number> <delimiter>
                 {<binary-digit> [<delimiter>} '*'

   <fuse checksum> ::=  'C' <hex-digit>:4 '*'

For example,

F0*
L0000  01001110  00001000  11110000  11111111  01010001*
C021A*

Fuse Default States Field (F)

The F field defines the states of fuses that are not explicitly defined in the 
L fields. If no F field is specified, all fuse states must be defined after 
the QF field and before the first L field.  For example, 

F0*      (Set default to 0)

Fuse List Field (L)

The L field starts with a decimal fuse number and is followed by a stream of 
fuse states (0 and 1). The fuse number may include leading zeros (that is, L12 
and L0012 are the same). A space and/or a carriage return must separate the 
fuse number from the fuse states. The stream of fuse states can be as long as 
desired (up to the maximum allowable fuse number). 

If the state for a fuse is specified more than once, the last state replaces 
all previous states specified for that fuse. This allows a file to be modified 
or "patched" by appending new fuse states to the file.  Following are three 
examples: 

L0000
111110111111111111111111111
101111111111111111111111111
111011111111111111111111111
000000000000000000000000000*

L0000
11111011111111111111111111110111111111
1111111111111111
11101111111
1111111111111111
00000000000000000000000000*

L00   111110111111111111111111111*
L28   101111111111111111111111111*
L56   111011111111111111111111111*
L84   000000000000000000000000000*

Fuse Checksum Field

The fuse information checksum field is used to detect transmitting and 
receiving errors. The checksum is for the entire device (fuse number 0 to the 
maximum fuse number set by the QF field), not just the fuse states sent. If 
multiple C fields are received only the last is significant. 

The field contains the 16-bit sum (that is, modulo 65,535) of the 8-bit words 
containing the fuse states for the entire device. The 8-bit words are formed 
as shown in this example. 

word  00 |msb|   |   |   |   |   |   |   |
Fuse No    7   6   5   4   3   2   1   0

word  01 |msb|   |   |   |   |   |   |   |
Fuse No.  15   14  13  12  11  10  9   8

         - - - - - - - - - - - - -  - - - -

word  62 |msb|   |   |   |   |   |   |lsb|
Fuse No.   -   -   -   -  499 498 497 496

The computation of the fuse checksum is as shown in the following example.

QF500*
F0* L0000 01001110 00001000 11110000 11111111 01010001*
C021A*

Fuse
Number MSB           LSB 
0000    0 1 1 1 0 0 1 0    72
0008    0 0 0 1 0 0 0 0    10
0016    0 0 0 0 1 1 1 1    0F
0024    1 1 1 1 1 1 1 1    FF
0032    1 0 0 0 1 0 1 0    8A
0040    0 0 0 0 0 0 0 0    00
0048    0 0 0 0 0 0 0 0    00
        - - - - - - - -
0488    0 0 0 0 0 0 0 0    00
0496    - - - - 0 0 0 0    00
                         ____
         Fuse checksum   021A

DEVICE TESTING FIELDS

Syntax and Overview

Functional test information is specified by test vectors containing test 
conditions for each device pin. 

Syntax of Functional Test Information:

<function test>  ::= [<default test condition>]
                     [<pin list>] <test vector>
                     {<test vector>}

<default test condition> ::=  'X' <binary digit> '*'

<pin list> ::= 'P' <pin number>:N '*'

<pin number> ::= <delimiter> <number>

N ::= number of pins on device

<test vector> ::= 'V'  <number> <delimiter> 
                   <test condition>:N '*'

<test condition> ::= <digit>    |'B' |'C' |'F' |'H' |'K' |
                            'L' |'N' |'P' |'X' |'Z'

<reserved condition>> ::=   'A' |'D' |'E' |'G' |'I' |'J' |
                            'M' |'O' |'Q' |'R' |'S' |'T' |
                            'U' |'V' |'W' |'Y' |'Z'

Test Conditions

0-   Drive input low
1-   Drive input high
2-   9-Drive input to super voltage 2-9
B-   Buried register preload
C-   Drive input low, high, low
F-   Float input or output
H-   Test output high
K-   Drive input high, low, high
L-   Test output low
N-   Power pins and outputs not tested
P-   Preload registers
X-   Output not tested, input default level
Z-   Test input or output for high impedance

Default Test Condition Field (X)

The X field defines the input logic level for test vectors not explicitly 
defined for the "don't care" test condition. The X field will set test vectors 
1 through the maximum (set by QV) to the default input test condition. If the 
X field is used, it must be specified after the QV and QP fields and before 
the first test vector.  For example, 

X1*      (Set default test condition to 1)<D>

In the following example vectors 2 and 5 would default to the "don't care" 
value of 0 and no outputs would be tested for vectors 2 and 5.  For example, 

QV5*
QP20*
X0*
V0001 101010000N0ZLLHHZ11N*
V0003 111XXXXXXN0ZHHLLZ11N*
V0004 011XXXXXXN0ZLHLHZ11N*

Test Vectors

Each test vector contains N test conditions where N is the number of pins on 
the device. The Test Conditions Table (shown above) lists the conditions that 
can be specified for device pins. 

The V field starts with a decimal vector number, followed by a space, then by 
a series of test conditions for each pin, and terminated by an asterisk. The 
vector number may include leading zeros.  For example, 

V0001 000000XXXNXXXHHHLXXN*
V0002 010000XXXNXXXHHHLXXN*
V0003 100000XXXNXXXHHHLXXN*
V0004 110000XXXNXXXHHHLXXN*

The vectors are applied in numerical order to the device being tested. The 
highest numbered vector to be applied is defined by the QV field. If a vector 
is not specified during a data transfer, the default value or a vector from a 
previous transfer will be used. If the same numbered vector is specified more 
than once, the data in the last vector replaces any data contained in previous 
vectors with that number. This allows the set of test vectors to be modified 
or "patched" without transferring the entire set. 

Pin Sequence

The conditions contained in test vectors are applied to the device pins in 
numerical order from left to right unless specified otherwise with the P 
field. (The left most condition is applied to pin 1, and the right most 
condition is applied to pin 20 of a 20 pin device, for example. If the timing 
sequence is not defined, a test condition may be applied to pin 5 before or 
after pin 4.) The P field indicates an alternative correspondence between the 
test conditions and the pin numbers.  For example, 

P 1 2 3 4 5 6 14 15 16 17 7 8 9 10 11 12 13 18 19 20*

V0001 111000HLHHNNNNNNNNNN*
V0002 100000HHHLNNNNNNNNNN*

Vector 1 will apply 111000 to pins 1 through 6 and HLHH to pins 14 through 17. 
Pins 7 through 13 and 18 through 20 are not tested (N). 

Test Conditions

The test condition logic levels are defined by the device technology (for 
example TTL, CMOS, ECL). The 0 and 1 test conditions apply a steady state 
logic level to the device pin. The device tester should allow the applied 
input conditions to be overridden by bidirectional (input/output) device pins. 
The X or "don't care" test condition applies the default level defined by the 
X field. The F test condition applies a high impedance to the device pin. 

The sequence that the input conditions are applied to the device is not 
defined, so multiple vectors should be used when the sequence is important. 
The following example ensures that pin 4 transitions to a logic level 1 before 
pin 3. 

V01 XX00XXXXXNXXXXXXXXXN*
V02 XX01XXXXXNXXXXXXXXXN*
V03 XX11XXXXXNXXXXXXXXXN*

The test conditions 2 through 9 apply a non-standard or super voltage to the 
device. This may be used to access special test modes. The levels are defined 
for each device and test vectors utilizing super voltages could damage "second 
source" devices. 

The C test condition applies a logic level 0 until all other inputs are stable 
(and device timing specifications are met) then switches to a logic level 1 
and returns to a logic level 0 before the outputs are tested. The K test 
condition goes from 1 to 0 to 1 in a similar manner. For devices more than one 
clock input, multiple test vectors should be used to ensure the proper 
clocking sequence. The N test condition is used for power pins and other 
outputs not tested. 

After all inputs have stabilized, including clock, the output tests are 
performed. The L test for a logic level 0 and the H test for a logic level 1. 

The Z test condition tests that an output is in a high impedance condition. 

REGISTER PRELOAD

Register Preload means forcing or "jam loading" a register to a known state. 
Three types of register preloading, "in- circuit," "output register," and 
"buried register" are defined. The "in-circuit" preload is accomplished with 
dedicated input pins or internal control logic and uses normal in-circuit 
logic levels. The standard input and clock test conditions may be used to 
preload the registers in these devices. The "output register" and "buried 
register" preload use non-standard levels or "super voltages" to access 
special modes to preload the registers. 

Because super voltages are unique for each device, the following generic 
methods will allow one set of test vectors to work with "second source" 
devices. The device programmer/tester will apply the specific super voltage 
algorithm for each device type. 

The "output register" method is used for devices with registers connected to 
device pins. A P test condition is used to "jam load" registers to a desired 
state. When the P test condition is applied to the clock pin, the logic level 
on the register output pin is loaded into the register according to the logic 
configuration of the device. During preload certain device pins may have to be 
in a defined state, such as an output enable control pin. 

For devices with separate banks of registers, the P test condition is applied 
to the each clock pin. For example, if pin 1 clocks bank A and pin 2 clocks 
bank B, a P on pin 2 would preload bank B. 

The 0 and 1 input conditions should be used instead of the L and H output test 
conditions. If the preload must be verified, use a separate test vector to 
test the outputs. 

For example, (16R4 type programmable array logic device)

V1 PXXXXXXXXN1XX1101XXN*   Preload 
V2 0XXXXXXXXN0XXHHLHXXN*   Test (don't clock)
V3 CXXXXXXXXN0XXHLHLXXN*   Next State

The "buried register" method can be used for devices with internal registers 
not connected to device pins. This may also be used for registers connected to 
device pins. The preload test vector has a B in the first position followed by 
a single digit, then followed by the register states and terminated with an 
asterisk. The preload test vector is the same length as the other test vectors 
and the unused positions are filled with don't cares. The device registers to 
be preloaded are assigned an index number starting at 1. 

<test vector>::='V' <number> <delimiter>
                'B' <digit> <test conditions>:N-2 '*'

In the following example a 20 pin device with 6 buried registers is preloaded 
to "110100." 

V27 B0110100XXXXXXXXXXXX* (preload vector)
V28 010101001N0XXHHLLXXN* (normal vector)

The digit in the second position of the preload test vector is used to allow 
more registers than pins. A 20 pin device with 30 registers would require two 
preload vectors. 

V05 B0110100101010101010* (preload first 18)
V06 B111010010001XXXXXXX* (preload next 12)

The H and L test conditions can be used to verify the state of the buried 
registers. 

PROGRAMMER/TEST OPTIONS

Security Fuse (G)

The security fuse(s) of certain logic devices may be enabled for programming 
by sending a 1 in the G field. The security fuse prevents the reading of the 
fuse states. Syntax for the Security Fuse field: 

<security fuse> ::= 'G' <binary-digit> '*'

For example,

G1*      (Enable security fuse programming)

Signature Analysis Test (S, R, T)

Signature Analysis tests are specified by the S, R, and T fields. The S field 
defines the starting vector for the test. The possible states are 0 and 1. The 
R field contains the resulting vector or test-sum. The T field denotes the 
number of test cycles to be run. 

Syntax for Signature Analysis Test:

   <starting vector> ::= 'S' <test condition>:N '*'
   <resulting vector> ::= 'R' <hex-digit>:8 '*'
   <test cycles> ::= 'T' <number> '*'

   N ::= number of pins on device

For example,

S010001000011100011110110*
R5BCD34A7*
T01*

Access Time (A)

The A field defines the propagation delay for test vectors in one nanosecond 
increments. This field may include optional subfields. 

Syntax for Access Time:

<access time> ::= 'A'{<field characters>} <number> '*'

For example,

A25*
APD25*

EXAMPLES

Data File Examples

Example 1

Minimum file for device programmer as defined Jedec Standard No. 3, October 
1983. 

   <STX>
   *
   L0000
   11111011111111111111111111111011111111111111111111111111
   11101111111111111111111111110000000000000000000000000000
   01010111011110111111111111110000000000000000000000000000
   00000000000000000000000000000000000000000000000000000000
   01010111101110111111111111110000000000000000000000000000
   00000000000000000000000000000000000000000000000000000000
   01010111011101111111111111110000000000000000000000000000
   00000000000000000000000000000000000000000000000000000000*
   <ETX>5718

Example 2

Data file for device programming.

   File for PLD 12S8 Created on 8-Feb-85 3:05PM
   6809 memory decode 123-0017-001
   Joe Engineer    Advanced Logic Corp *
   QF0448*
   F0*
   L00 01111101111111111111111111111*
   L028 1011111111111111111111111111*
   L056 1110111111111111111111111111*
   L112 0101011101111011111111111111*
   L224 0101011110111011111111111111*
   L336 0101011101110111111111111111*
   C124E*

Example 3

Data file for device testing.

   File for PLD 12S8 Created on 8-Feb-85 3:05PM
   6809 memory decode 123-0017-001
   Joe Engineer Advanced Logic Corp *
   QP20* QV8*
   V0001 000000XXXNXXXHHHLXXN*
   V0002 010000XXXNXXXHHHLXXN*
   V0003 100000XXXNXXXHHHLXXN*
   V0004 110000XXXNXXXHHHLXXN*
   V0005 111000XXXNXXXHLHHXXN*
   V0006 111010XXXNXXXHHHHXXN*
   V0007 111100XXXNXXXHHLHXXN*
   V0008 111110XXXNXXXLHHHXXN*

Example 4

Data file for programming and testing with options.

   File for PLD 12S8 Created on 8-Feb-85 3:05PM 
   6809 memory decode 123-0017-001
   Joe Engineer   Advanced Logic Corp * 
   QP20*    N Number of pins* 
   QF0448*  N Number of fuses* 
   QV8*     N Number of vectors* 
   G1*      N Program security fuse* 
   F0*      N Default fuse state* 
   X0*      N Default test condition*

   N Fuse RAM Data* 
   L0000 
   1111101111111111111111111111
   1011111111111111111111111111
   1110111111111111111111111111*
   L0112
   0101011101111011111111111111*
   L0224
   0101011110111011111111111111*
   L0336
   0101011101110111111111111111*
   N Test Vectors*
   V0001 000000XXXNXXXHHHLXXN*
   V0002 010000XXXNXXXHHHLXXN*
   V0003 100000XXXNXXXHHHLXXN*
   V0004 110000XXXNXXXHHHLXXN*
   V0005 111000XXXNXXXHLHHXXN*
   V0006 111010XXXNXXXHHHHXXN*
   V0007 111100XXXNXXXHHLHXXN*
   V0008 111110XXXNXXXLHHHXXN*
   N Fuse RAM checksum* 
   C124E*
   N Signature Analysis test information*
   T01* 
   S00000000000000000000*
   R95E4B822*

Example 5

Data file showing position independence of fields.

   File for PLD 12S8 Created on 8-Feb-85 3:05PM
   6809 memory decode 123-0017-001   
   Joe Engineer  Advanced Logic Corp * 
   QP20* 
   QF448* QV8* F0* 
   V1 000000000N000HHHL00N*
   V2 010000000N000HHHL00N*
   V3 100000000N000HHHL00N*
   V4 110000000N000HHHL00N*
   L0 1111101111111111111111111111*
   L28 1011111111111111111111111111*
   L56 1110111111111111111111111111*
   L84 0000000000000000000000000000*
   L112 0101011101111011111111111111*
   L224 0101011110111011111111111111*
   L336 0101011101110111111111111111*
   L140 1111111111111111111111111111*
   L140 0000000000000000000000000000*
   C124E*
   V8 111111111N111HHHL11N*
   V6 111010000N000HHHH00N*
   V7 111100000N000HHLH00N*
   V5 111000000N000HLHH00N*
   V8 111110000N000LHHH00N*