System for flexible embedded Boundary Scan testing

FIELD OF INVENTION

0001The present invention is related to electronic printed circuit board and system assembly testing and more specifically to provide a flexible method for implementing tests for embedded Boundary Scan testing.

BACKGROUND OF THE RELATED ART

0002As integrated circuit packaging technology has decreased in size, the ability to determine functionality and continuity of electronic assemblies has become increasingly more difficult. Integrated circuit boundary scan features are well known in the art and is typically used in Personal-Computer (PC) based tests and in Automatic Test Equipment (ATE) testing used in manufacturing. An example of Boundary-Scan testing is disclosed in U.S. Pat. No. 6,594,802, entitled “Method and Apparatus for Providing Optimized Access to Circuits for Debug, Programming and Test, issued Jul. 15, 2003 to Ricchetti, et al.

0003An advantage of Boundary Scan testing is that it is structural in nature and is amenable to explicit coverage metrics. Boundary Scan features for testing have also been expanded to both the board and the system level. In the embedded environment, board-level tests are typically functional tests that target specific board operations, while system level testing allows for functional testing of particular hardware modules and/or their interaction. An example of board and system level Boundary Scan testing is disclosed in USPPA No. U.S. 2003/0009715 A1, entitled “Method and Apparatus for Optimized Parallel Testing and Access of Electronic Circuits,” filed on Apr. 9, 2002, by Ricchetti, et al.

0004Current methods of embedded Boundary Scan testing may use microprocessor-based or specialized co-processor-based programs to take advantage of programmable technology. However, current methods are limited in that the tests are specific to the connectivity of the existing board level integrated circuit configuration. Thus, when a new board configuration is used, the microprocessor-based Boundary Scan programs must be altered to accommodate the new configuration. As has been found, altering such programs is a time- and labor-intensive process as the new functions must be tested to insure they work properly and existing functions must be re-tested to establish that their operation was not altered by the new changes. USPPA No. 2003/0106004, entitled “Method and Apparatus for Embedded Built-In Self-Test (BIST) of Electronic Circuits and Systems,” filed May 10, 2002, by Ricchetti, et al., discloses a method for downloading externally based test programs and data into embedded systems to avoid duplication of effort in developing test programs that may be used both from an external computer or an internal controller. However, this method is limited as once a start address is determined the testing continues until the end of the scan vectors for the selected scan block vector suite is reached. Hence, the order of the tests is fixed by the data downloaded into the memory and the memory must be reloaded to provide for a different order or the addition of new tests.

0005Furthermore, the prior art only provides for rudimentary conditional flow control in the order of jumps and if-then conditionals. Thus the embedded BIST approach does not lend itself well to reliability testing, such as Environmental Stress Test (EST), where a sequence of operations must be performed repetitively for a specific period of time or when an error condition is detected. The prior art is also limited in scope in what test functions can be performed as, typically, there is a single static vector test format available to perform Boundary Scan operations. Furthermore, the prior art fails to provide adequate support for product testing over the entire product life cycle as part of a Built-In test strategy. Further still, as new industry standards and features are introduced to solve specific test problems, support for these new features must be available in the embedded test system. One such feature is the ability to support dynamic vector creation and analysis to reduce the time it takes to program logic devices, which is not available in the art.

0006Thus, there is a need in the industry for a method that allows for a more flexible means for providing Boundary Scan test and programming support to accommodate new standards, configurations and flexibility in the order of test execution without incurring time-intensive re-programming and re-testing of the BIST software.

SUMMARY OF INVENTION

0007A flexible Boundary Scan test system is disclosed. The system includes an interpreter module operable to execute a program element selected from a plurality of program elements that include at least one instruction type having an interface to identify and execute selected functions wherein each of the selected functions is associated with at least one data information item. In one aspect of the invention, selected ones of the functions are composed of a plurality of second functions. In another aspect of the invention, the instruction includes parameters and adornments for determining the selected function execution.

BRIEF DESCRIPTION OF THE FIGURES

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a conventional Boundary Scan test system configuration;

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a Boundary Scan test architecture in accordance with the principles of the present invention;

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a block diagram of Boundary Scan services module;

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary block diagram of a TFCL Interpreter module in accordance with the principles of the invention;

<figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary flow chart of the polymorphic APPLY function in accordance with the principles of the invention;

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flow chart for creating a test step in accordance with the principles of the invention;

<figref idref="DRAWINGS">FIG. 7</figref> illustrates a flow chart of the application of a polymorphism function in accordance with the principles of the invention;

<figref idref="DRAWINGS">FIG. 8</figref> illustrates an exemplary structure for a binary TFCL program file.

<figref idref="DRAWINGS">FIG. 9</figref> illustrates an exemplary structure for a Persistent TestStep file;

<figref idref="DRAWINGS">FIG. 10</figref> illustrates an exemplary structure for a Binary SVF file;

<figref idref="DRAWINGS">FIGS. 11</figref><i>a</i>–<b>11</b><i>c </i>illustrate exemplary structures for code sequences used in the Binary SVF file shown in <figref idref="DRAWINGS">FIG. 10</figref>;

<figref idref="DRAWINGS">FIG. 12</figref> illustrates an exemplary structure for a Test Repository Archive; and

<figref idref="DRAWINGS">FIG. 13</figref> illustrates the structural relationship of the data files shown in <figref idref="DRAWINGS">FIGS. 8–12</figref>.

0021It is to be understood that these drawings are solely for purposes of illustrating the concepts of the invention and are not intended as a definition of the limits of the invention. The embodiments shown in figures herein and described in the accompanying detailed description are to be used as illustrative embodiments and should not be construed as the only manner of practicing the invention. Also, the same reference numerals, possibly supplemented with reference characters where appropriate, have been used to identify similar elements.

DETAILED DESCRIPTION

0022<figref idref="DRAWINGS">FIG. 1</figref> illustrates a conventional Boundary Scan test system configuration <b>100</b> including details of both board and integrated circuit tests. More specifically, system <b>100</b> is composed of boards <b>110</b> and <b>150</b> communicating via bus <b>160</b>. Board <b>110</b> includes a plurality of integrated circuits <b>120</b>, <b>130</b>, <b>132</b> and <b>134</b>, which are in communication via interconnection tracks <b>125</b>, for example. Board <b>150</b>, similarly, includes a plurality of integrated circuits <b>152</b>, <b>154</b>, <b>156</b>, and <b>158</b>, in communication via interconnection tracks <b>155</b>. Integrated circuit <b>120</b> illustrates a conventional Boundary Scan configuration wherein core logic <b>124</b> is surrounded on the boundary of integrated circuit <b>120</b> with programmable cells <b>122</b>. Typically, the programmable cells <b>122</b> are “daisy-chained” together to allow data to be passed from one cell to the next. Test Access Port (TAP) controller <b>126</b> provides a control means to route serial input signals, i.e., Test Data In (TDI), for setting and clearing individual cells <b>122</b>. The settings of cells <b>122</b> on integrated circuit <b>120</b> may be applied to interconnection tracks <b>125</b> and then observed at corresponding integrated circuit <b>130</b> cells. Observations are reported serially using Test Data Out (TDO) signals thereby testing the connectivity of interconnection tracks <b>125</b>. The Institute of Electrical and Electronic Engineers (IEEE) standard 1149.1, which is incorporated by reference herein, provides standards regarding test signals for Boundary Scan testing. Operation of IEEE1149.1 standard is disclosed in “Design Consideration in Using 1149.1 as a Backplane Test Bus”, Pete Collins, IEEE/TTTC Board Test Workshop <b>2003</b>, Oct. 3, 2003.

0023For a plurality of boards, IEEE 1149.1 standard typically requires a wired serial communications link between a TDO signal port of a proceeding unit under test (UUT) and a TDI signal port on a subsequent UUT. Gateway modules <b>140</b>, on boards <b>110</b> and <b>150</b>, are used as a common communication access module that bridges the IEEE 1149.1 signals on the backplane to one circuit board at a time. In another aspect, some gateway modules allow for broadcast of information to all boards simultaneously. Gateways <b>140</b> are in communication via a Boundary Scan test bus, <b>170</b>.

0024Central processing units (CPUs) <b>145</b> and test bus controllers <b>147</b> on boards <b>110</b> and <b>150</b> are used to control signals and execute programs that may be used to test communications between individual integrated circuits, e.g., <b>120</b> and <b>130</b>, or among other integrated circuits, e.g., <b>132</b> and <b>134</b>, or between boards, e.g., integrated circuits <b>134</b> and <b>156</b>. Although boards <b>110</b> and <b>150</b> are depicted containing CPUs, it would be recognized by those skilled in the art that only a single board is required to include a CPU that may be used to perform system level tests. CPU <b>145</b> typically contains executable program code and test data, e.g., test patterns, used to test particular integrated circuits and the connections therebetween.

0025<figref idref="DRAWINGS">FIG. 2</figref> illustrates a software architecture <b>200</b> for Boundary Scan testing in accordance with the principles of the invention. In this exemplary architecture, system services <b>210</b> represents an application software or a function test environment software used in the system. The role of this service is to control when tests are applied to the UUT. Boundary Scan Services <b>220</b> represents the application programming interface for controlling the application of the Boundary Scan Test (BST) to the UUT. Test Flow Control Language (TFCL) Interpreter <b>230</b> is responsible for executing the directives found in the TFCL programs. The purpose of TFCL <b>230</b> is to separate the flow of control in the embedded BST system from the software that is written to support embedded BST. In another aspect, this system may be used externally as a PC based tester. A TFCL program represents one or more tests, i.e., TestStep, that are to be applied to the UUT. For Boundary Scan testing, this may be a single test pattern or may be a set of test patterns. Scan Interface <b>240</b> represents the device driver interface for the Boundary Scan Services. Each specialized interface is responsible for communicating with a specific Boundary Scan hardware TAP. Emulation services <b>250</b> provides necessary support functions for Boundary Scan Services <b>220</b> when these services are not available in the run-time environment libraries. Run-time services <b>260</b> are the services provided by the run-time environment. For example, Run-time services <b>260</b> may represent a host operating system.

0026Test Repository Archive (TRA) Services <b>270</b> represents data files and corresponding access functions associated with specific sets of tests to be applied to the UUT. Test repository archive <b>270</b> data may be stored in a local ROM/Flash memory or downloaded from a host computer or server and linked with the Run-time services <b>260</b>. In one aspect, TRA <b>270</b> is a binary data block of compressed file images. The contents of a TRA <b>270</b> include TFCL program files, persistent Test Step Objects, Boundary Scan Vector (i.e., test pattern) files, Diagnostic Lookup tables and other files necessary to perform a complete test suite on the UUT.

0027<figref idref="DRAWINGS">FIG. 3</figref> illustrates a block diagram of Boundary Scan Services module <b>300</b> composed of test engine <b>310</b> in communication with specialized Test Repository Interface Definitions (TRID) <b>360</b>, TFCL Test Object <b>340</b>, Null Test Object <b>345</b> and Report Formatter <b>350</b>. TRID <b>360</b> defines the interface for each specialized class used by the test engine <b>310</b>. The Composite Test Repository (CTR) <b>320</b> and TFCL Test Repository (TTR) <b>330</b> are specializations of the TRID <b>360</b>. Each of the specialized classes manages data blocks viewed in the Test Repository Archive <b>270</b> (<figref idref="DRAWINGS">FIG. 2</figref>). In one aspect, a specialized class may filter out files presented to the test engine <b>310</b> so only those files of interest to the system services <b>210</b> (<figref idref="DRAWINGS">FIG. 2</figref>) are obtained when the service is queried for tests. TFCL Test Repository <b>330</b> represents a specialization of Test Repository <b>360</b> which is responsible for filtering Test Repository Archive <b>270</b> data so only TFCL programs are visible to system services <b>210</b>. TFCL Test Repository <b>330</b> is also responsible for locating and constructing a TFCL Test Object <b>340</b> to be applied to the UUT. Composite Test Repository <b>320</b> extends the functionality of the Test Repository class <b>360</b>. It provides the means for concatenating multiple Test Repository <b>360</b> objects together to behave as a single Test Repository object. Test Object <b>340</b> defines the interface for specialized test objects. A test object is the smallest unit of test that may be applied to UUT by the Systems services <b>210</b>. TFCL Test Object Class <b>340</b> represents a TFCL program that is to be applied to the UUT by system services <b>210</b>. Null Test Object <b>345</b> defines an object that is used when Test Repository <b>360</b> is unable to locate a requested Test Object.

0028<figref idref="DRAWINGS">FIG. 4</figref> illustrates a block diagram <b>400</b> of the elements of TFCL Interpreter module <b>410</b>. TFCL Interpreter module <b>410</b> provides the interface to load and run test programs as well as manage errors that are detected during execution of a selected test program. As shown, TFCL Interpreter module <b>410</b> is in communication with modules or classes, TFCLapi <b>420</b>, Singleton <b>430</b>, Agenda <b>440</b>, Flow <b>450</b> and Statement <b>460</b>. Agenda <b>440</b> maintains the order that statements are to be applied in a test program. TFCL Interpreter module <b>410</b> initially includes statements that are ordered in Flow object <b>450</b> by a TFCL program file. TFCLapi <b>420</b> represents the interface defined by TFCL Interpreter module <b>410</b> to populate the appropriate objects within the interpreter module. This class is used as a base class for all parsers interfacing with TFCL Interpreter module <b>410</b>. Singleton <b>430</b> is responsible for ensuring only one copy of key TFCL objects exist in a single run-time execution. Flow object <b>450</b> represents a procedural block in a TFCL program. It orders all statements contained within the program block. Statement <b>460</b> represents an interface class defining the base structure for all statement objects in TFCL Interpreter module <b>410</b>.

0029Conditional Statement <b>462</b> is representative of common statement behavior that relies on known conditions to execute. Statements such as LOOP <b>463</b>, REPEAT <b>464</b>, WHILE <b>465</b>, Compound statements (IF or IF/THEN/ELSE) <b>466</b> are conditional statements known in the art. More specifically, LOOP statement <b>463</b> allows a block of code to be executed in a loop until an event, either internal or external, is applied or a desired number of iterations or loops are achieved. REPEAT <b>464</b> represents a statement that is applied to a block of code and conditionally repeats the block after the first execution of the code. WHILE statement <b>465</b> is responsible for testing if the condition is true prior to executing any of the contained statements. If the condition is true, the object places its contained statements at the head of the Agenda object <b>440</b> for execution. Compound statement <b>466</b> is composed of IF and IF/THEN/ELSE statements. IF defines a condition to be tested when that line of code is reached. If the condition evaluates to a “true”, the block of code defined by the “then” clause is executed. If the condition evaluates to a “false”, the block of code defined by the “else” clause is executed, but only if an “else” block is specified.

0030APPLY statement <b>468</b> provides for many different behavioral options to the execution of this statement. APPLY <b>468</b> is responsible for identifying a Test Step <b>469</b>, i.e., function, to be applied and ensures the appropriate Test Step handler is in place, dynamically, to support the action desired.

0031APPLY statement <b>468</b> is used to access the test step extension to the TFCL language. The APPLY statement further provides instruction to the designated test step that is the intent of the desired execution. For example, <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0032">APPLY identifier DIAGNOSE;</li><li id="ul0002-0002" num="0033">represents the execution of a test step instruction, having a parameter referred to as “identifier,” that is applied to the UUT and an optional parameter DIAGNOSE that determines the diagnostic to be performed on failing results. Identifier represents the named instances of specialized test step operations that are to be applied at that point of the sequence flow. These identifiers represent persistent copies of the TestStep object state that are defined in the Test Repository Archive <b>270</b> as TestStep files. The name of the identifier parameter may be determined by a user's preferences or desires.</li></ul></li></ul>

0034<figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary flow chart <b>500</b> of the APPLY statement <b>468</b> process flow and follows the ability of virtual functions in the C++ language as described in “The Annotated C++ Reference Manual,” Ellis, et al., Addison-Wesley Publishing, 1990, pp. 208–209. In this illustrated process flow, a search for a TestStep object in a memory resident cache reserve is made. At block <b>520</b> a determination is made whether the requested TestStep object is available. If the answer is negative, then at block <b>530</b> a process is initiated to create the requested TestStep object. At block <b>540</b> a determination is made whether the requested TestStep object was successfully created. If the answer is negative, then an error is indicated at block <b>545</b>.

0035If, however, the answer at block <b>540</b> is in the affirmative, then the newly created TestStep object is added to the cache reserve. Processing proceeds to block <b>560</b> where the requested TestStep object is obtained from the cache reserve. At block <b>570</b> the requested TestStep is then executed.

0036Examples of APPLY statement <b>468</b> are represented as: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0037">a. APPLY identifier DIAGNOSE CELL; <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0038">which operates to report the device Boundary Scan cell number when a failure is observed</li></ul></li><li id="ul0004-0002" num="0039">b. APPLY identifier DIAGNOSE LINE; <ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0040">which operates to report the TFCL line number and failing vector number for the observed failure</li></ul></li><li id="ul0004-0003" num="0041">c. APPLY identifier DIAGNOSE PIN; which refers to displaying the device pin name where failure was observed:</li><li id="ul0004-0004" num="0042">d. APPLY identifier DIAGNOSE NET; <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0043">which operates to report the UUT net name where the failure is observed</li></ul></li><li id="ul0004-0005" num="0044">e. APPLY identifier DIAGNOSE VECTOR; <ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0045">which operates to report the raw vector data where the observed failure is detected.</li></ul></li><li id="ul0004-0006" num="0046">f. APPLY identifier DIAGNOSE MAXFAIL=#times; <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0047">which operates to abort the TFCL program execution if #times failures occurred during this test.</li></ul></li><li id="ul0004-0007" num="0048">g. APPLY identifier DIAGNOSE LINE PIN NET CELL VECTOR MAXFAIL=1;</li><li id="ul0004-0008" num="0049">which operates to report all the defined diagnostic information specified.</li><li id="ul0004-0009" num="0050">where CELL, LINE, PIN, NET, and VECTOR are adornments for the DIAGNOSE option that indicate the type of failure reporting is requested.</li></ul></li></ul>

0051<figref idref="DRAWINGS">FIG. 6</figref> illustrates an exemplary flow chart <b>600</b> of the TestStep object create block <b>530</b> shown in <figref idref="DRAWINGS">FIG. 5</figref>. In this illustrated flow chart, a search of the requested TestStep object is performed at block <b>610</b>. This search is performed in the Test Repository Archive Service <b>270</b> for the TestStep object's persistent data image file. However, in one aspect, simple TestStep object, such as ASPTestStep, associated with an Addressable Shadow Protocol, may be implemented as built-in TestStep objects that do not need to be persistent in the TRA because there is no state information required for construction. Addressable Shadow Protocol is a known protocol provided by gateway manufacturers to allow to access to their multi-drop port. For example, the Texas Instrument Corporation, Dallas, Tex. provides a known protocol to access their SN74LVT8996 Addressable Scan Port, i.e., gateway <b>140</b>. At block <b>620</b>, a determination is made whether a TestStep object image has been found. If the answer is negative, then an error is indicated at block <b>625</b>. Otherwise, a new specialized TestStep object is created based on the persistent image at block <b>630</b>. In TestStep object creation, the “Type” field of the persistent image file is analyzed and used to select an appropriate construction operation required for the type of TestStep object. The appropriate construction operation is executed to initialize the requested TestStep object using the information found in the TestStep image file referred to by the “identifier” of the APPLY statement.

0052<figref idref="DRAWINGS">FIG. 7</figref> illustrates an exemplary flow chart <b>700</b> depicting dynamic selection of a specialized function executed by the APPLY statement based on a single interface representation to the interpreter. In this case, the APPLY statement provides the ability to call selected ones of a plurality of specialized functions using a virtual function interface, i.e., the same interface. This concept is conventionally referred to as polymorphism by those skilled in the art. More specifically, a selected specialized TestStep object identifier from the interface known by the APPLY statement at block <b>710</b>. In this case, the TFCL APPLY statement identifies associated TestStep objects and is thus not concerned with the specialization of the TestStep objects identified. Hence, when a TestStep is to be applied to the UUT, the APPLY statement flow executes the interface function associated with the TestStep object by calling the TestStep function. At block <b>720</b>, the APPLY statement software performs a table lookup to locate a virtual function identified or associated with the identified TestStep object by the compiler and resident in memory. This creates an indirect reference to the correct function associated with and matches the identified function referred to by the APPLY statement. At block <b>730</b> references associated with the identified function are next obtained. At block <b>740</b> the identified function and references are executed in association with the parameters referred to by the APPLY statement, i.e., parameters and adornments.

0053The use of polymorphism provides the ability to separate the points of software change when a new feature is added or removed from the entire software system to a single point that is changed transparently to the entire software. Thus, adding a new TestStep type to the software only requires adding a new specialized TestStep object to the software. All links to this new feature are automatic through the use of the APPLY statement. The only change required to the existing software is found in the TestStepFactory that needs to create a new instance of the new feature. Furthermore, the use of polymorphism provides a faster execution of the executable code as performing specific conditional tests for each object type and selecting the appropriate specialized function is removed.

0054In environments that fully support static object initialization at run-time, it is possible to automatically register the new specialized TestSteps with the TestStepFactory so no creation code is required to be changed.

0055<figref idref="DRAWINGS">FIG. 8</figref> illustrates an exemplary TFCL file format <b>800</b>. The original TFCL file is an ASCII text file in the syntax of the TFCL language that gets translated into a binary TFCL file format <b>800</b>. The TFCL File Header <b>810</b> stores specific information regarding the size and version of the binary information. TFCL Token <b>820</b>, <b>840</b>, and <b>860</b> represent the tokenized version of a TFCL statement keyword. The Token Data <b>830</b>, <b>850</b>, and <b>870</b> represents the information relating to the specific TFCL statement as defined in the original ASCII file. This data is specific to each statement and may contain binary representations of the ASCII data found in the original TFCL file. In one aspect, to reduce the overhead associated with parsing an ASCII file in the embedded environment, an off-line process is performed on the ASCII file wherein syntax errors and keywords are converted to tokens and placed in a binary file. The use of a preprocessed ASCII file improves the execution time of the interpreted data.

0056<figref idref="DRAWINGS">FIG. 9</figref> illustrates an exemplary structure of a Persistent TestStep object file <b>900</b>. The persistent TestStep file format is represented as a property list of key and value pairs. The information is stored as an ASCII file with keywords representing specific states of the specialized TestStep object characteristics. Keywords may be selected from the group: Name <b>910</b>, Type <b>920</b>, File <b>930</b>, Catgy <b>940</b>, Resp <b>950</b>, Compressed <b>960</b> and Dlut <b>970</b>. Name <b>910</b> represents the name of the TestStep instance. Type <b>920</b> represents the name of the specialization TestStep object that must be instantiated for this persistent object. File <b>930</b> represents the datafile where supporting test information resides in Test Repository Archive Service <b>270</b> (<figref idref="DRAWINGS">FIG. 2</figref>). In one aspect, Type <b>930</b> may be associated with a Binary SVF file (see <figref idref="DRAWINGS">FIG. 10</figref>), and the file is the file named by the file <b>940</b> value. In this case, “.bsv” extension is implied. The value for Catgy <b>950</b> specifies an optional description of the purpose of the TestStep object to aid in diagnostics. The value of the Resp <b>950</b> key defines the name of a storage area where the resultant diagnostic data is to be preserved for systems that support a file system. The value for the Compressed <b>970</b> key defines whether the data represented by the file <b>940</b> is compressed or not. The value of the “Dlut” <b>980</b> key represents the name of the diagnostic look up table information for TestStep objects that support additional diagnostics.

0057<figref idref="DRAWINGS">FIG. 10</figref> illustrates an exemplary structure <b>1000</b> of a Binary SVF file in accordance with the principles of the invention. In this exemplary structure, header information <b>1010</b> includes information regarding file size and offset information to where the SVF Code Sequences and SVFPacked Vector Data starts. SVF code sequence <b>1020</b>.<b>1</b>–<b>1020</b>.n represents “n” code sequences that may be stored within structure <b>1000</b>. Each code sequence represents a single line of the original SVF vector file. The SVF Packed Vector Data <b>1030</b> block represents the raw data area where vector information is stored in a raw format and aligned on a word boundary. In this raw format, vectors may overlap or be contained as subsets of larger vectors.

0058<figref idref="DRAWINGS">FIG. 11</figref><i>a </i>illustrates an exemplary format of a single field code sequence that may represent the SVF code sequence <b>1020</b>.<b>1</b>–<b>1020</b>.n (<figref idref="DRAWINGS">FIG. 10</figref>). This sequence represents those SVF statements not containing vector information. For example, a RESET command or a STATE IDLE command would be represented by this class of code sequence. The SVF Line Number <b>1105</b> field represents the line number where the statement resides in the original SVF file. The SVF Operation <b>1110</b> is a tokenized code representing a specific SVF command. The Operation Data <b>1115</b> represents the associated data for that operation and is stored in free form defined by the token represented in <b>1110</b>. <figref idref="DRAWINGS">FIG. 11</figref><i>b </i>illustrates an exemplary format of a double field code sequence that may represent the SVF code sequence <b>1020</b>.<b>1</b>–<b>1020</b>.n shown in <figref idref="DRAWINGS">FIG. 10</figref>. This double field code sequence illustrates SVF statements that require numeric information. For example, the RUNTEST command taking a number of TCK ticks as its argument and is represented by this format. The High Word <b>1120</b> field represents the high order word of the 32-bit number defined by the command. The Low Word <b>1125</b> field represents the low order word of the 32-bit number defined by the command. <figref idref="DRAWINGS">FIG. 11</figref><i>c </i>illustrates an exemplary format of a multi-field code sequence that may represent the SVF code sequence <b>1020</b>.<b>1</b>–<b>1020</b>.n shown in <figref idref="DRAWINGS">FIG. 10</figref>. The field Number of Scan Bits <b>1130</b> represents the number of bits that are required to be scanned from the vector data pointed to by this command. This is not the same thing as the number of bits stored in the vector as, in a preferred embodiment, the vector is aligned to the nearest 16-bit size. The Offset to TDI Vector Data <b>1135</b> represents the offset from the base of the SVF Packed Vector Data <b>1030</b> where the start of the TDI Vector information resides in the raw data format. The Offset to TDO Vector Data <b>1140</b> represents the offset from the base of the SVF Packed Vector Data <b>1030</b> where the start of the TDO Vector information resides in the raw data format. The Offset to SMASK Vector Data <b>1145</b> represents the offset from the base of the SVF Packed Vector Data <b>1030</b> where the start of the SMASK Vector information resides in the raw data format. The Offset MASK Vector Data <b>1150</b> represents the offset from the base of the SVF Packed Vector Data <b>1030</b> where the start of the MASK Vector information resides in the raw data format. Finally, the End State <b>1155</b> represents the state a TAP controller must be in at the conclusion of this command execution. This must be one of the 4 stable states specified by the IEEE 1149.1 standard.

0059<figref idref="DRAWINGS">FIG. 12</figref> illustrates an exemplary structure <b>1200</b> of a Test Repository Archive Service. In this exemplary structure field <b>1210</b> represents a header block that includes information regarding version information, the offset to the base of the Archived Data Blocks (<b>1220</b>.<b>1</b>–<b>1220</b>.n), the offset to the Archived Specification Data Block <b>1230</b>, and the offset to the Archived Directory Data Block <b>1240</b> from the beginning of the image. Fields <b>1210</b>.<b>1</b>–<b>1210</b>.n include information regarding “n” archived data blocks. Each archived data block represents compressed file images stored in the Test Repository Archive Service. Each file is represented by its own Archived Data Block in the repository. The Archived Specification Data Block <b>1230</b> represents information about the Test Repository Archive itself. Some of the information stored here is the time stamp of when the repository was created, the filename used to store the repository during the creation process, the path to the file in which the repository was created. The Archived Directory Data Block <b>1240</b> contains the information about each Archived Data Block and the offset to the beginning of the Archived Data Block in the archive image. Some of the information contained in the directory is the path and name where the file stored in the Archived Data Block was read in from during the creation process, the time stamp of the file that was archived, the compression algorithm used to compress the file into the Archived Data Block, the compressed image size (size of the Archived Data Block), and the uncompress file size of the image stored in the Archived Data Block. The latter is needed to provide for the correct space required to inflate the compressed image prior to its use.

0060An example (entitled BPTEST.TFB) of backplane/cable testing of multiple circuit boards having a multi-drop test bus may be performed using the following TFCL Boundary Scan Test program element:

0061<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ENTITY sys1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>FLOW sys1 IS</entry></row><row><entry /><entry>APPLY ASP FROM 0 TO 0; // comment - Reset all ASPs</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>(i.e., Gateways)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>APPLY ASP FROM 10 TO 10 ALWAYS DIAGNOSE VECTOR;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>// sel. board 1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 1”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY Brd1SVF FROM 1 TO 10 DIAGNOSE;// initialize board 1</entry></row><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“Board 1 failed to scan initialization vectors.”);</entry></row><row><entry /><entry>APPLY ASP FROM 0 TO 0; // Reset all ASPs</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY ASP FROM 20 TO 20 DIAGNOSE VECTOR; // select</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>board 2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 2”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY Brd2SVF FROM 1 TO 15 DIAGNOSE; // Initialize using</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>data from lines //1–15</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“Board 2 failed to scan initialization vectors.”);</entry></row><row><entry /><entry>APPLY ASP FROM 0 TO 0; // Reset all ASPs</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY ASP FROM 10 TO 10; // select board 1</entry></row><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 1”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY Brd1SVF FROM 11 TO 11; // HiZ Outs</entry></row><row><entry /><entry>APPLY ASP FROM 20 TO 20; // Select Board 2</entry></row><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 2”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY Brd2SVF FROM 16 TO 16; //HiZ Outs. Use data from</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>line 16—16</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>APPLY ASP FROM 10 TO 10; // select board 1</entry></row><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 1”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>APPLY Brd1SVF FROM 12 TO 12; // apply Pattern 1</entry></row><row><entry /><entry>APPLY ASP FROM 20 TO 20; // Select Board 2</entry></row><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“failed to connect to Board 2”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>// Observe Pattern 1</entry></row><row><entry /><entry>APPLY Brd2SVF FROM 17 TO 17 DIAGNOSE LINE PIN NET;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>// Use data // from line 17—17 and on failure report line, pin and net</entry></row><row><entry>failure observed.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>IF FAIL THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>PRINT (“Vector 17 failed on Board 2”);</entry></row><row><entry /><entry>STOP;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF;</entry></row><row><entry /><entry>END FLOW;</entry></row><row><entry /><entry>END ENTITY;</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0062With regard to the exemplary backplane/cable process shown, the following information may be stored in the Test Repository Archive <b>270</b>. The example shows the ASCII version of TFCL for a simple test. This ASCII program may be tokenized into a binary TFCL file in the format <b>800</b> shown in <figref idref="DRAWINGS">FIG. 8</figref>. The name of the file in the example may be BPTEST.TFB in the repository. This file would reside in its own Archived Data Block in the TRA <b>270</b>. Supporting information for this file would be the TestStep object files and the associated data files containing information items for each test. For example, information regarding the ASP TestStep object may be implemented as a built-in TestStep type and the TestStep persistent file images required for this example are the images for the Brd1SVF and Brd2SVF objects. The persistent TestStep object images for the BSVF TestStep objects may be stored as files BRD1SVF.TS and BRD2SVF.TS respectively. The contents of the files may be as follows:

0063<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>// BRD1SVF.TS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>NAME = BRD1SVF</entry></row><row><entry /><entry>TYPE = BSVF</entry></row><row><entry /><entry>FILE = BRD1VEC</entry></row><row><entry /><entry>CATGY = BPTEST</entry></row><row><entry /><entry>RESP = BRD1VEC</entry></row><row><entry /><entry>COMPRESSED = NO</entry></row><row><entry /><entry>DLUT = BRD1VEC</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>// BRD2SVF.TS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>NAME = BRD2SVF</entry></row><row><entry /><entry>TYPE = BSVF</entry></row><row><entry /><entry>FILE = BRD2VEC</entry></row><row><entry /><entry>CATGY = BPTEST</entry></row><row><entry /><entry>RESP = BRD2VEC</entry></row><row><entry /><entry>COMPRESSED = NO</entry></row><row><entry /><entry>DLUT = BRD2VEC</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0064The TestStep files reference the BRD1VEC.BSV and BRD2VEC.BSV binary SVF files and associated vector data files for the test step by the FILE property respectively. The format for the vector files follows that shown in <figref idref="DRAWINGS">FIG. 10</figref>. There are also references to the BRD1VEC.DTB and BRD2VEC.DTB diagnostic lookup table support files by the DLUT property respectively. The format for the DLUT is an ASCII tabular file containing the global cell number in the first column, the Device Cell identifier for the second column, the Device Pin identifier for the third column, and the Net identifier for the last column.

0065Furthermore, in the example provided, each call of the APPLY statements referencing identifier Brd1SVF and Brd2SVF may use, as in this illustrated case, the FROM x TO y optional parameters that instruct the TestStep object to apply the designated portions of the functionality to the UUT. The x represents the starting line number in the SVF to apply and the y represents the last line of the SVF to apply to the WUT during that point of execution. As one would skilled in the art would recognized, a line number may refer to a specific SVF function. Thus, there may be initialization code and test vectors in the same SVF file for a board. The APPLY statement defines the way in which the vectors are to be applied through its parameters and adornments.

0066<figref idref="DRAWINGS">FIG. 13</figref> illustrates the relation between the data bases shown in <figref idref="DRAWINGS">FIGS. 8–12</figref> with regard to the example shown above.

0067While there has been shown, described, and pointed out fundamental novel features of the present invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the apparatus described, in the form and details of the devices disclosed, and in their operation, may be made by those skilled in the art without departing from the spirit of the present invention. It is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Substitutions of elements from one described embodiment to another are also fully intended and contemplated.