Apparatus and method for generating configuration and test files for programmable logic devices

An apparatus and method for generating configuration and test files for programmable logic devices includes a dynamic configuration and test generation program to specify, in source code, a logic function to be implemented by a programmable logic device. A device test development kernel program has information characterizing physical elements of the programmable logic device and bit patterns for implementing connections between the physical elements of the programmable logic device. The device test development kernel program converts the logic function into a configuration file for use in programming the logic function into the programmable logic device. The dynamic configuration and test generation program also specifies, in source code, a test operation to be executed by the programmable logic device. It operates with the device test development kernel program to produce a vector file for use in testing the programmable logic device.

BRIEF DESCRIPTION OF THE INVENTION 
This invention relates generally to the programming and testing of 
programmable logic devices. More particularly, this invention relates to a 
generalized approach to generating configuration and test programs for a 
variety of programmable logic devices. 
BACKGROUND OF THE INVENTION 
Programmable logic devices are used in a variety of electronic equipment. 
Each programmable logic device is initially a "blank slate" that can be 
programmed to implement specified functions. The advantage of a 
programmable logic device is that it is relatively inexpensive since a 
mass-produced device can be created and subsequently programmed to perform 
a specified function. This approach is less expensive than designing an 
application specific integrated circuit (ASIC) to implement the same 
function. 
The Flex 10K family of programmable logic devices sold by Altera 
Corporation, San Jose, Calif., is widely known in the art. Each Flex 10K 
programmable logic device includes an embedded array and a logic array. 
The embedded array is used to implement general logic in a conventional 
"sea-of-gates" architecture. In addition, the embedded array has dedicated 
die areas for implementing large, specialized programmable functions. In 
particular, the embedded array can be used to implement memory functions, 
such as random access memory (RAM), read only memory (ROM), and 
first-in-first-out (FIFO) functions. In addition, the embedded array can 
be used to implement logic functions, such as multipliers, 
microcontrollers, and state machines. Logic functions are implemented by 
programming the embedded array with a read-only pattern during 
configuration, thereby creating a large look-up table (LUT). In this LUT, 
combinatorial functions are implemented by looking up the results, rather 
than by computing them. This implementation of combinatorial functions is 
faster than using algorithms implemented in general logic. 
The logic array portion of the Flex 10K programmable logic device is also 
used to implement logic functions. That is, it is used to implement 
general logic, such as counters, adders, state machines, and multiplexers. 
The logic array has a larger die area and slower speed compared to the 
embedded array. 
A programmable logic device, such as a Flex 10K programmable logic device, 
is configured to implement specified functions. A configuration file is 
used to implement the specified functions. In other words, an engineer 
generates a configuration file which is used to configure a programmable 
logic device to perfrom a set of specified functions. 
Once a configuration file is established, it is necessary to test the 
operation of the proposed configuration. A test file is used for this 
purpose. 
Thus, in order to implement a programmable logic device, it is necessary to 
establish a configuration file and a test file. These files are generally 
generated through the use of a bit-level static configuration and test 
generation program. FIG. 1 illustrates a bit-level static configuration 
and test generation program 20A in accordance with the prior art. The 
figure also illustrates that the program is used to produce a 
configuration file 22A and a test (or vector) file 24A. These two files 
are then applied to a configurable device (programmable logic device) 26A. 
That is, the configuration file 22A is initially used to configure the 
configurable device 26A. Thereafter, the test file 24A is applied to the 
configurable device 26A to confirm that it is operating as intended. 
FIG. 1 illustrates that configurable device 26A has a corresponding 
bit-level static configuration and test generation program 20A. Similarly, 
other configurable devices, A through N, each have a dedicated bit-level 
static configuration and test generation programs 20A-20N. In other words, 
in the prior art, it is necessary to construct a bit-level static 
configuration and test generation program for each configurable device. 
This approach is obviously problematic because it requires a large number 
of programs. Moreover, this approach is problematic because an operator of 
the program must have a bit-level understanding of the configurable device 
that is being worked with. 
In view of the foregoing, it would be highly desirable to generate a single 
configuration and test generation program that could be used for a variety 
of configurable devices. Preferably, such a program would not require a 
bit-level understanding of the configurable device to be programmed. In 
other words, preferably, a more generalized approach to device programming 
and testing would be afforded. 
SUMMARY OF THE INVENTION 
An apparatus and method for generating configuration and test files for 
programmable logic devices includes a dynamic configuration and test 
generation program to specify, in source code, a logic function to be 
implemented by a programmable logic device. A device test development 
kernel program has information characterizing physical elements of the 
programmable logic device and bit patterns for implementing connections 
between the physical elements of the programmable logic device. The device 
test development kernel program converts the logic function into a 
configuration file for use in programming the logic function into the 
programmable logic device. The dynamic configuration and test generation 
program also specifies, in source code, a test operation to be executed by 
the programmable logic device. It operates with the device test 
development kernel program to produce a vector file for use in testing the 
programmable logic device. 
The invention provides a single configuration and test generation program 
for use with a variety of configurable devices. Further, the invention 
provides a more generalized approach to device configuration and testing, 
as the bit-level details of such operations are automatically performed by 
the device test development kernels.

Like reference numerals refer to corresponding parts throughout the several 
views of the drawings. 
DETAILED DESCRIPTION OF THE INVENTION 
FIG. 2 illustrates a high-level dynamic configuration and test generation 
program 30 in accordance with an embodiment of the invention. As its name 
implies, the program 30 does not operate at a bit-level, but at a more 
general level, to produce a configuration file 34 and a test file 36. FIG. 
2 also illustrates that the program 30 is used to configure a set of 
configurable devices 38A-38N. Each configurable device 38A-38N has a 
common internal architecture, but that architecture is scaled to a 
different size. Thus, the configurable devices 38A-38N have different 
sizes and internal resources. 
The high-level dynamic configuration and test generation program 30 
interacts with a set of device test development kernel programs 32A-32N. 
Each device test development kernel program 32 includes bit-level 
information for a corresponding configurable device 38. Thus, generalized 
configuration and test information is supplied at the high-level dynamic 
test generation program 30. The program 30 then calls a specified device 
test development kernel program 32. The device test development kernel 
program 32 converts the generally specified information from the 
high-level dynamic configuration and test generation program 30 into bit 
level information that is used to generate a configuration file 34 and a 
test file 36. 
For example, in one embodiment of the invention, the high-level dynamic 
configuration and test generation program 30 is implemented to support a 
procedure "ConnectResourceAtoResourceB", which has software parameters 
representing resource A and resource B. Thus, the user of program 30 
simply calls the procedure and specifies a resource A and a resource B in 
order to make a connection between the two resources. This information is 
then processed by a device test development kernel program 32 to generate 
the bit-level commands that are necessary to implement this operation. 
That is, the device test development kernel program 32 generates a 
sequence of bit-level commands for application to different resources of 
the configurable device so that the generally characterized connect 
resource A to resource B operation is specifically implemented in the 
configurable device. This specific implementation is performed 
automatically and transparently to the user. 
FIG. 3 generally corresponds to FIG. 2, but also illustrates a kernel 
generator program 40. The kernel generator program 40 is used to construct 
each device test development kernel program 32. In particular, the kernel 
generator program 40 accesses a device design file, say device A design 
file 42A, to generate a device test development kernel program, say device 
A test development kernel program 32A. Each design file 42 may be in the 
form of a text file that specifies all of the device resources and the 
connections between those resources. The kernel generator program 40 uses 
this device information to generate an appropriate device test development 
kernel program, as discussed below. 
FIG. 4 illustrates an apparatus 50 constructed in accordance with an 
embodiment of the invention. The apparatus 50 includes a central 
processing unit 52 connected to a system bus 54, which is connected to 
user input/output devices 56, such as a keyboard, mouse, monitor, and 
printer. The system bus 54 is also connected to configurable device 
interfaces 58. The configurable device interfaces 58 include known devices 
that are used to download a configuration file into a configurable device 
60. The configurable device interfaces 58 also include interfaces to apply 
test data to the configurable device 60 and to gather test output vectors 
from the configurable device 60. 
The system bus 54 is also connected to a memory 62. The interaction between 
elements 52 and 62 is known in the art. The invention is directed toward 
the executable programs stored in the memory 62. One executable program 
stored in memory 62 is the previously described high-level dynamic 
configuration and test generation program 30. The memory 62 also stores 
the previously described kernel generator program 40, design files 42, and 
test development kernel programs 32. The foregoing programs produce 
configuration files 34 and test files 36. The memory 62 also stores device 
interaction programs 64 that are used to interact with the configurable 
device interfaces 58. Finally, the memory 62 stores test analysis programs 
66 which are used to confirm that the results of the test operations are 
correct. 
FIG. 5 illustrates processing steps that are executed in accordance with an 
embodiment of the invention. In particular, the figure illustrates 
processing steps 70-80 on the left-hand side of the figure and the 
corresponding elements to perform those operations on the right-hand side 
of the figure. 
The first processing step is to specify high-level routines or logic 
functions (step 70). For example, as described above, the high-level logic 
function or routine may be the procedure "ConnectResourceAtoResourceB". 
This routine may be used to configure a device and to test a device. This 
routine is specified to the high-level dynamic configuration and test 
generation program 30. 
The next step is to process the routine in reference to a designated device 
(step 72). In other words, the specified high-level routine describes a 
designated device and a routine to be performed in reference to that 
device. The device test development kernel program 32 for the specified 
device is used, for example, to convert the general instruction to connect 
resources into a specific set of commands that are used to establish the 
connection between the resources. Those commands are placed in a 
configuration file. In other words, a configuration file is generated 
(step 74) through the processing of the routines. Similarly, a test file 
is produced (step 76) through the processing of the routines. In other 
words, routines are selected for configuration purposes and test purposes. 
The device test development kernel program 32 transforms this information 
into a configuration file and a test file. 
The next processing step is to download the configuration to the 
configurable device (step 78). This operation can be performed through the 
use of the device interaction programs 64 and the configurable device 
interfaces 58. The final processing step is to test the device (step 80). 
This processing step uses the test files 36, the device interaction 
programs 64, and the test analysis programs 66. 
The invention has now been fully described. The invention has been 
described in reference to known elements such as a CPU 52, user 
input/output devices 56, configurable device interfaces 58, device 
interaction programs 64, and test analysis programs 66. The invention is 
directed toward the combination of these known elements with the following 
novel elements of the invention: the high-level dynamic configuration and 
test generation program 30, the device development kernel programs 32, the 
kernel generator program 40, and the related configuration files 34, test 
files 36, and device design files 42. Attention presently turns to a more 
detailed discussion of an example of a high-level dynamic configuration 
and test generation program 30, in accordance with an embodiment of the 
invention. The discussion of this element will more fully demonstrate the 
operation of the invention. 
The example high-level dynamic configuration and test generation program 30 
provided below operates to program a device of the type shown in FIG. 6. 
FIG. 6 illustrates a programmable logic device (PLD) 90, from the Flex 10K 
family of logic devices sold by Altera Corporation, San Jose, Calif. The 
PLD 90 includes a set of input/output elements 92, which are connected to 
input/output pins (not shown) ofthe PLD 90. The input/output elements 92 
are used to route signals to and from the PLD 90. The device 90 also 
includes row interconnection circuitry 94 and column interconnection 
circuitry 96. Embedded array blocks 98 and logic array blocks 100 are 
positioned between the row interconnection circuitry 94 and the column 
interconnection circuitry 96. 
FIG. 7 is a more detailed view of a logic array block 100. As shown, the 
logic array block 100 is connected to row interconnect circuitry 94 and 
column interconnect circuitry 96. Local interconnect circuitry 102 is used 
to route signals within the logic array block 100. A set of logic array 
elements 104 is used to store look-up tables, which specify a logical 
function. In other words, each look-up table receives a set of input 
signals, which are mapped to a value in the look-up table; that value is 
then used as the output signal. The output signal is routed out of the PLD 
90 using the row interconnection circuitry 94 and the column 
interconnection circuitry 96. 
FIGS. 6 and 7 illustrate the complexity of programming a PLD 90. For 
example, if a bit is to be set in a certain logic element 104, then that 
signal, and its accompanying control signals, must be routed through an 
input/output element 92, through row interconnection circuitry 94 and/or 
column interconnection circuitry 96, and into a specified location in a 
specified logic element 104. Then, to test whether the bit was set 
correctly, another set of signals must be routed through an input/output 
element 92, through row interconnection circuitry 94 and/or column 
interconnection circuitry 96, and to a specified logic element 104. As 
previously indicated, in the prior art, the instructions to perform these 
operations are generated through a custom program. To create the custom 
program, the programmer must be aware of how to program the PLD 90. In 
particular, the programmer must have a bit-level understanding of the 
device to be programmed so that bit-level instructions can be written to 
route a signal through the PLD 90. This becomes particularly complex when 
a programmer is forced to have knowledge of a number of PLD devices. For 
example, the Flex 10K family of logic devices sold by Altera Corporation, 
San Jose, Calif., has seven different types of PLDs, ranging from 7,000 to 
158,000 usable gates. Thus, applying prior art techniques to these devices 
would result in seven separate programs for the seven different types of 
PLDs. 
The present invention exploits the fact that certain families of PLDs have 
different numbers of gates, but they share a common architecture. For 
example, the Flex 10K family of logic devices sold by Altera Corporation, 
San Jose, Calif., has a single architecture, but different sized devices 
(with different numbers of gates) implement that architecture. For 
example, two devices may have the same overall architecture, as shown in 
FIG. 6, but one device may have row interconnection circuitry 94 (FIG. 6) 
with 8 signal lines, while another device may have row interconnection 
circuitry 94 with 16 signal lines. 
The high-level dynamic configuration and test generation program 30 is 
written to implement a function that is to be performed by a PLD 90 with a 
specified architecture. The program is written in such a way that it is 
easily adapted to apply to different PLDs with the same architecture, but 
with different sizes implementing the architecture. 
As its name indicates, the program 30 is written at a high-level, so that 
detailed understanding of the bit-level operation of the PLD is not 
necessary. Instead, general functions are specified, then the program 30 
calls a specific device test development kernel program 32 to implement 
the detailed, bit-level operations for the corresponding PLD. 
The following code is an example of a high-level dynamic configuration and 
test generation program that has been used to program the Flex 10K family 
of logic devices sold by Altera Corporation, San Jose, Calif. The 
operation of the code is documented, however, by way of overview, the code 
illustrates the implementation of a simple operation of toggling the 
output of a specified input/output element 92. More particularly, the code 
is used to route a signal from a specified input/output element 92, 
through a global horizontal routing line (of the row interconnection 
circuitry 94), to another input/output element 92. 
The high-level dynamic configuration and test generation program 30 in this 
example is a procedure called 
"TIOGeneratorObject.CreateGHToOEControlTest". The title indicates that the 
program Toggles an Input-Output (TIO) element. The title also indicates 
that to do this one creates a global horizontal (GH) to output enable (OE) 
control test. The term "global horizontal" refers to row interconnection 
circuitry 94. Thus, in this example, the high-level dynamic configuration 
and test generation program 30 is used to implement a toggle function of 
an input-output element 92. Naturally, other operations can be implemented 
in accordance with the invention. 
Procedure TIOGeneratorObject.CreateGHToOEControlTest; type 
The following code defines some of the data structures used in the program 
30. The record "TFastPathRec" keeps track of the resources used to route 
the signal input on a FAST pin to a global horizontal line. That global 
horizontal line will, in turn, control the output enable controls of an 
input-output element 92. A FAST pin is a package pin that has a dedicated 
connection (the connection is not multiplexed) to an internal resource of 
a PLD. 
______________________________________ 
TFastPathRec = record 
ll : tLL.sub.-- Enum; 
column : TCol.sub.-- Enum; 
gh : TGH.sub.-- HH.sub.-- Enum; 
lm : TLM.sub.-- Enum; 
end; 
______________________________________ 
The following code defines some variables, including an array 
"TfastPathArray". Each input-output cell has it's output enable controlled 
by a different global horizontal line. TfastPathArray keeps track of the 
connections made to each of the input-output cells in a single row. 
______________________________________ 
TFastPathArray = Array [ TRLIO.sub.-- Enum ] of TFastPathRec; 
var 
tbio TTBIO.sub.-- Enum; 
fastToOE : TFastPathArray; 
connectionFound 
: boolean; 
col : TCol.sub.-- Enum; 
ok : TConnect.sub.-- Result.sub.-- Enum; 
inputNumber : integer; 
rlio TRLIO.sub.-- Enum; 
gvHiLo : TLowHighEnum; 
gv TGV.sub.-- Enum; 
gh : TGH.sub.-- HH.sub.-- Enum; 
row : TRow.sub.-- Enum; 
lmIn : TLMInEnum; 
______________________________________ 
The following code begins the process of establishing the path between the 
signal from the FAST pin to the global horizontal lines. The connection 
information is provided in the device test development kernel program 32. 
As previously indicated, the kernel generator program 40 is preferably used 
to produce the development kernel program 32. Also indicated above is the 
fact that the kernel generator program 40 relies upon a device design file 
42 to create a device test development kernel program 32. The device 
design file 42 includes information defining the connected elements of a 
PLD and the bit patterns required to program the connected elements. 
The device test development kernel program 32 essentially embodies the 
information from the device design file 42. This information is 
incorporated into data structures within the development kernel program 
32. Those skilled in the art can readily implement a kernel generator 
program 40 to read a design file 42 and construct a device test 
development kernel program 32 which stores a set design parameters from 
the design file 42 in data structures of the device test development 
kernel program 32. 
The configuration program 30 can retrieve the information from the 
development kernel program 32, as shown below. Thus, the development 
kernel program 32 provides information to the configuration program 30, in 
addition, the development kernel program 32 generates the bit map or 
sequence of bit patterns for the configuration file 34, which is used to 
program the PLD 90. 
The code below illustrates how the program 30 passes parameters to the 
development kernel 32 corresponding to the PLD to be programmed. The 
immediately following code simply defines some variables for future use. 
______________________________________ 
Procedure SetupFastToGH; 
var 
ll : TLL.sub.-- Enum; 
muxBit : TMuxBit.sub.-- Enum; 
localCol : TCol.sub.-- Enum; 
localLM 
: TLM.sub.-- Enum; 
begin 
______________________________________ 
The following code is used to query the device test development kernel 
program 30 on how to make a connection between specified physical elements 
of the PLD. In particular, the code is used to identify a LAB (logic array 
block) line (ll) that will provide connection to the FAST input-output 
element. The information is subsequently used to make the connection, as 
described below. 
______________________________________ 
forll := MIN.sub.-- LL to MAX.sub.-- LL do 
begin 
for muxbit := MUXBIT.sub.-- 0 to MAX.sub.-- GHIN.sub.-- MUX do 
begin 
if GHIN.sub.-- DESCRAMBLE [ ll, Ord ( muxBit) ] = FAST.sub.-- 0 then 
begin 
fastToOE [ rlio ].ll := ll; 
end; 
end; 
end; 
______________________________________ 
The following code is used to find the logic element 104 that can drive the 
global horizontal line (of the row interconnect circuitry 94) that will 
toggle the input-output element 92. 
__________________________________________________________________________ 
for localCol := MIN.sub.-- COL to TCol.sub.-- Enum ( Ord ( MAX.sub.-- COL 
) div 2 ) do 
begin 
for locaILM := LM.sub.-- 0 to LM.sub.-- 7 do 
begin 
ifGV2GH.sub.-- GHDRIVEN [ Ord ( localCol ), localLm ] = 
fastToOE [ rlio ].gh then 
begin 
fastToOE [ rlio ].column := localCol; 
fastToOE [ rlio ].lm := localLM; 
end; 
end; 
end; 
if fastToOE [ rlio ].column = COL.sub.-- URAM then 
begin 
Writeln ( `Unable to route FAST to GH` ); 
Halt; 
end; 
end; 
begin 
mapMaker.map2img.ClearTheImage; 
__________________________________________________________________________ 
The following code is part of the main procedure body. The device 
connection information obtained from the foregoing code is passed back to 
the development kernel program 34 to allow the development kernel to 
generate a bit map configuration file 34, which is used to program the 
PLD. The first three lines in the loop are for initialization. The fourth 
line is a link into a data structure of the development kernel program 
32A. This instruction returns information describing the global horizontal 
line which controls the output enable of the input-output element. 
______________________________________ 
for rlio := MIN.sub.-- RLIO to MAX.sub.-- RLIO do 
begin 
fastToOE [ rlio ].ll := LL.sub.-- NO.sub.-- CON; 
fastToOE [ rlio ].lm := LM.sub.-- NC; 
fastToOE [ rlio ].column := COL.sub.-- URAM; 
fastToOE [ rlio ].gh := GH.sub.-- TO.sub.-- OE [ rlio ]; 
SetupFastToGH; 
end; 
______________________________________ 
The following code sets up the architecture bits and inversion bits of the 
bit map, as more fully specified below. The next several lines of code are 
used to loop through the different rows of the PLD. 
______________________________________ 
for row := MIN.sub.-- ROW to MAX.sub.-- ROW do 
begin 
for rlio := MIN.sub.-- RLIO to MAX.sub.-- RLIO do 
begin 
______________________________________ 
The next lines of code are used to set the input-output cell architecture 
bits. More particularly, the next line of code instructs the development 
kernel 32 to generate a bit pattern to set a value "$0084" for a target 
cell "rlio" of the specified "row". The next line of code can be 
considered an implementation instruction specifying a physical element 
("rlio") of the programmable logic device, its location (specified by 
"row"), and an operation the physical element is to perform (set a value 
of "$0084"). The development kernel program 32 merely maps the parameters 
(row, rlio, $0084) and function "mapMaker.SetRLIOArch" passed to it to a 
stored set of bit patterns that will implement the specified operation. 
This conversion operation is mechanical in nature. Thus, the programming 
of the development kernel 32 is not critical. The important aspect of the 
development kernel program 32 is that it stores the required information 
(bit pattern) for the specified PLD, so that the programmer does not have 
to know the bit pattern, but instead can specify a functional operation in 
the source code of the configuration program 30 so that the bit pattern is 
generated by the development kernel 32. 
ok:=mapMaker.SetRLIOArch (row, rlio, $0084), 
ok:=mapMaker.SetRLIORPI (row, rlio, TRUE); 
The following code specifies that the output enable should be set so that 
it is controlled by a global horizontal line. Observe once again that a 
functional source code statement of the configuration program 30 is used 
to force the development kernel 32 to generate a bit pattern to implement 
the function, without requiring the programmer to have detailed 
information regarding the internal architecture of the PLD. Instead, this 
detailed information is available in the development kernel 32. 
______________________________________ 
ok := mapMaker.SetRLIOSS (row, rlio IOSS.sub.-- OE, G.sub.-- GH ); 
if ok &lt;&gt; CONNECT.sub.-- OK then 
begin 
Writeln ( `Error setting RLIO SS.` ); 
Halt ( 1 ); 
end; 
______________________________________ 
The following code is used to instruct the development kernel 32 to connect 
a specified logic array block 100 to a specified global horizontal line. 
__________________________________________________________________________ 
ok := mapMaker.SetLABGHIn ( row, fastToOE [ rlio ].column, FAST.sub.-- 
0, 
fastToOE [ rlio ].ll ); 
if not ( ok in [ CONNECT.sub.-- OK, SAME.sub.-- BIT.sub.-- SET.sub.-- 
ALREADY ] ) then 
begin 
Writeln ( `Error setting FAST TO OE GHIN.` ); 
Halt ( 1 ); 
end; 
__________________________________________________________________________ 
The following code is used to instruct the development kernel 32 to connect 
a specified logic element 104 input line to a specified routing line. 
______________________________________ 
lmIn := TLMInEnum ( Ord ( fastToOE [ rlio ].lm ) * 4 ); 
ok := mapMaker.SetLABLLToLMIn ( row, 
fastToOE [ rlio ].column, 
fastToOE [ rlio ].ll; 
lmIn ); 
if not ( ok in [ CONNECT.sub.-- OK ] ) then 
begin 
Writeln ( `Error setting FAST TO OE LL to LMIn,` ); 
Halt ( 1 ) 
end; 
______________________________________ 
The following code is used to instruct the development kernel 32 to set the 
bits in the specified logic element 104. 
______________________________________ 
mapMaker.SetLUT ( row, 
fastToOE [ rlio ].column, 
fastToOE [ rlio ].lm, 
$8000 ); 
______________________________________ 
The following code is used to instruct the development kernel 32 to set up 
the logic module architecture bits to allow the control signal to be 
driven from the specified logic element 104. 
______________________________________ 
mapMaker.SetLMArch ( row, 
fastToOE [ rlio ].column, 
fastToOE [ rlio ].lm, 
[ SC ] ); 
______________________________________ 
The following code is used to instruct the development kernel 32 to set up 
the driver signals to drive the control signal out of the specified logic 
array block 100. 
______________________________________ 
ok := mapMaker.SetLMToGH ( row, 
fastToOE [ rlio ].column, 
fastToOE [ rlio ].lm ); 
if not ( ok in [ CONNECT.sub.-- OK ] ) then 
begin 
Writeln ( `Error setting FAST TO OE GH driver.` ); 
Halt ( 1 ), 
end; 
end; 
end; 
______________________________________ 
The foregoing code constructs the bit map defining the configuration file 
34. The following code is used to generate the test or vector file 36. The 
test generation program 30 is used to functionally describe the tests to 
be performed. The development kernel 34A, in this embodiment, merely 
operates to map a package pin with a known functionality (e.g., a 
specified FAST pin) to a specific physical pin of the PLD package. This 
information is then written to the test file 36. In general, the following 
code operates to specify a test operation and the results that should be 
generated from that operation. The following code sets non-input/output 
bits and provides header information for the test file 36. 
______________________________________ 
Procedure MakeVector; 
Procedure SetNONIO; 
begin 
p2vGen.SetVectorData ( `MSEL0` ); 
p2vGen.SetVectorData ( `MSEL1` ); 
p2vGen.SetVectorData ( `NSTATUS` ); 
p2vGen.SetVectorData ( `CONDONE` ); 
p2vGen.SetVectorData ( `NCONFIG` ); 
end; 
begin 
OpenVector ( 18 ); 
Comment ( `This vector tests the RLIO mux which routes a gh line to 
the register OE control` ); 
Comment ( `Fast0 drives all OE controls` ); 
Gap; 
DumpVectorHeader; 
Gap; 
p2VGen.SetAllVectorData; 
p2vGen.ClearVectorData ( `NCEO` ); 
p2vGen.PrintVectorData ( ` IO `, `;`, vectorFile ); 
______________________________________ 
The following code generates a test file 36 to drive test signals through 
the FAST pin and to read the resultant output signals from a specified 
pin. Drive and compare commands (DRCMIP) are used to insure that the 
output signal matches the expected output signal. 
__________________________________________________________________________ 
p2vGen.ClearAllVectorData; 
IOToggle ( TRUE, [], ALL.sub.-- TBIO.sub.-- SET ); 
p2vGen.PrintVectorData ( ` MASK `, `;`,vectorFile ); 
Gap; 
Comment ( `Drive the OE control high. Make sure that the RLIOs float.` 
); 
Gap; 
p2vGen.ClearAllVectorData; 
SetAllIO; 
IOToggle ( FALSE, ALL.sub.-- RLIO.sub.-- SET, [] ); 
SetNonIO; 
p2vGen.SetVectorData ( `FASTO` ); 
p2vGen.PrintVectorData ( ` DR `, `;`, vectorFile); 
p2VGen.SetAllVectorData; 
p2vGen.ClearVectorData ( `NCEO` ); 
ClearAllIO; 
IOToggle ( TRUE, ALL.sub.-- RLIO.sub.-- SET, [] ); 
p2vGen.PrintVectorData ( `IO `, `;`, vectorFile ); 
p2vGen.ClearAllVectorData; 
IOToggle ( TRUE, [],ALL.sub.-- TBIO.sub.-- SET); 
SetNonIO; 
p2vGen.SetVectorData ( `FASTO` ); 
p2vGen.PrintVectorData ( `DRCMP`, `;`, vectorFile); 
Gap; 
p2VGen.SetAllVectorData; 
p2vGen.ClearVectorData ( `NCEO` ); 
p2vGen.PrintVectorData ( `IO `, `;`,vectorFile); 
p2vGen.ClearAllVectorData; 
SetNonIO; 
p2vGen.SetVectorData ( `FASTO` ); 
p2vGen.PrintVectorData ( `DR `, `;`, vectorFile); 
p2VGen.SetAllVectorData; 
p2vGen.ClearVectorData ( `NCEO` ); 
ClearAllIO; 
IOTOggle (TRUE, ALL.sub.-- RLIO.sub.-- SET, []); 
p2vGen.PrintVectorData ( ` IO `, `;`, vectorFile); 
p2vGen.ClearAllVectorData; 
SetNonIO; 
p2vGen.SetVectorData ( `FASTO` ); 
p2vGen.PrintVectorData ( `DRCMP `, `;`, vectorFile); 
Gap; 
Comment ( `Drive the OE control LOW, enabling the TBIOs, 
driving them to one.` ); 
Gap; 
p2VGen.SetAllVectorData; 
p2vGen.ClearVectorData ( `NCEO` ); 
ClearAllIO; 
IOTOggle (TRUE, ALL.sub.-- RLIO.sub.-- SET, [] ); 
p2vGen.PrintVectorData ( ` IO `, `;`, vectorFile ); 
p2vGen.ClearAllVectorData; 
IOToggle ( TRUE, [], ALL.sub.-- TBIO.sub.-- SET ); 
SetNonIO; 
p2vGen.PrintVectorData ( ` DRCMP `, `;`, vectorFile); 
Gap; 
AppendVectorTail; 
CloseVector; 
end; 
__________________________________________________________________________ 
The following code calls the foregoing procedure. 
MakeVector; 
The foregoing code is a single example of an implementation of the 
invention. Those skilled in the art will recognize that the code includes 
a number of design details and commands that are unique to the particular 
implementation. The invention should not be construed as limited to these 
details. More importantly, the invention should not be obscured by these 
details. The example serves to demonstrate that functional source code 
statements in the configuration program 30 are used to generate a 
configuration file 34. The development kernel 34 operates to map the 
functional source code statement to a bit pattern that implements that 
functionality. The nature of the bit pattern is dependent on the 
particular device that is being programmed, thus, there is a different 
development kernel for each type of device. The test generation program 30 
also operates to construct a test file. The test generation program 30 
specifies the functional operations to be executed. In this context, the 
development kernel 32 only provides device-specific information on package 
pin mapping that allows the functional operations to be performed. 
The foregoing description, for purposes of explanation, used specific 
nomenclature to provide a thorough understanding of the invention. 
However, it will be apparent to one skilled in the art that the specific 
details are not required in order to practice the invention. In other 
instances, well known circuits and devices are shown in block diagram form 
in order to avoid unnecessary distraction from the underlying invention. 
Thus, the foregoing descriptions of specific embodiments of the present 
invention are presented for purposes of illustration and description. They 
are not intended to be exhaustive or to limit the invention to the precise 
forms disclosed, obviously many modifications and variations are possible 
in view of the above teachings. The embodiments were chosen and described 
in order to best explain the principles of the invention and its practical 
applications, to thereby enable others skilled in the art to best utilize 
the invention and various embodiments with various modifications as are 
suited to the particular use contemplated. It is intended that the scope 
of the invention be defined by the following Claims and their equivalents.