阅读说明：本技术 集成电路测试设备和方法 (Integrated circuit testing apparatus and method ) 是由 米凯莱·波尔托拉恩 于 2018-05-17 设计创作，主要内容包括：本发明涉及一种测试设备,包括：测试装置(302),具有用于存储数据处理指令的存储器(304)和一个或多个处理器,所述处理器被设计成当执行数据处理指令时执行测试代码(308),以便对被测装置(102)执行测试操作,所述测试代码(308)定义应用于被测装置的测试仪器的一个或多个测试模式和一个或多个测试算法,所述测试代码具有独立于测试装置(302)和被测装置(102)之间的测试接口(106、08)的第一格式；以及接口控制器(310),被设计成将测试代码执行期间由测试装置生成的通信转换成适合于测试接口的第二格式,并将来自被测装置(102)的通信转换成第一格式。(The invention relates to a test device comprising: a test device (302) having a memory (304) for storing data processing instructions and one or more processors designed to execute test code (308) when executing the data processing instructions so as to perform a test operation on the device under test (102), the test code (308) defining one or more test patterns and one or more test algorithms to be applied to a test apparatus of the device under test, the test code having a first format independent of a test interface (106, 08) between the test device (302) and the device under test (102); and an interface controller (310) designed to convert communications generated by the test device during execution of the test code into a second format suitable for the test interface and to convert communications from the device under test (102) into the first format.)

1. A test apparatus for testing a device under test (102), the apparatus comprising:

a test apparatus (302) comprising a memory (304) for storing data processing instructions and one or more processors which, when executing the data processing instructions, are arranged to:

-executing test code (308) to perform a test operation on the device under test (102), the test code (308) defining one or more test patterns and one or more test algorithms to be applied to a test instrument of the device under test, the test code having a first format independent of a test interface (106, 108) between the test device (302) and the device under test (102); and

an interface controller (310) coupled to the device under test (102) and arranged to convert communications generated by the test device during execution of the test code into a second format suitable for the test interface and to convert communications from the device under test (102) into the first format.

2. A test apparatus according to claim 1, comprising a plurality of interface controllers (310, 310') implemented by the one or more processors of the test device or another device, wherein the test device is arranged to select one of the plurality of interface controllers to perform the conversion.

3. A test apparatus according to claim 1 or 2, wherein the one or more processors of the test device, or one or more other processors of a test generation tool, are arranged to generate the test code before the test device executes the test code.

4. The test apparatus of any of claims 1 to 3, further comprising the test interface (106, 108) coupling the interface controller (310) to the device under test (102).

5. A test device according to any one of claims 1 to 4, wherein the test means (302) is arranged to execute a first test algorithm applied to a first test instrument and a second test algorithm applied to a second test instrument in parallel.

6. The test apparatus of any one of claims 1 to 5, wherein the one or more processors of the test device (302) are further arranged to access an external library (602) defining one or more other test algorithms for testing sub-circuits of the device under test.

7. A test apparatus according to claim 6, wherein the one or more processors of the test device (302) are arranged to generate the test code by including the external library (602) into the test code, and/or by including function calls to the one or more other test algorithms into the test code.

8. A test apparatus according to claim 6 or 7, wherein the sub-circuits implement data or signal processing functionality, and wherein the one or more further test algorithms are arranged to verify the expected behaviour of the data or signal processing functionality.

9. Test apparatus according to claim 6 or 7, wherein the sub-circuit implements an encryption function, and wherein the one or more further test algorithms are arranged to provide encryption and/or decryption operations so as to allow a test generation tool (302) to verify the behaviour of the encryption function.

10. A test system, comprising:

the test device of any one of claims 1 to 9; and

a device under test (102) coupled to the test equipment, the device under test comprising a test access port (104) and a plurality of test instruments (202-216), each of the test instruments comprising one or more analysis registers.

11. A method for testing a device under test (102), the method comprising:

executing, by a test device (302), test code (308) to perform a test operation on the device under test (102), the test code (308) defining one or more test patterns and one or more test algorithms to be applied to a test instrument of the device under test (102), the test code having a first format independent of a test interface (106, 108) between a test generation tool (302) and the device under test (102); and is

In the testing stage:

-converting communications generated by the execution of the test code and intended for the device under test (102) into a second format suitable for the test interface; and is

-converting a communication from the device under test (102) into the first format.

12. The method of claim 11, further comprising generating, by the testing device (302) or one or more other processors of a test generation tool, the test code (308) prior to execution of the test code.

13. The method of claim 11 or 12, further comprising selecting, by the test device (302), one from a plurality of interface controllers (310, 310') to perform the conversion.

14. The method of any of claims 11 to 13, further comprising executing, by the testing device (302), in parallel, a first testing algorithm applied to a first testing instrument and a second testing algorithm applied to a second testing instrument.

Technical Field

This description relates to the field of testing integrated circuits, and in particular to automated digital testing.

Background

In the field of automated digital testing, for many years, the standard IEEE 1149.1, commonly referred to as the JTAG standard (joint test action group), has defined a test interface for testing integrated circuits. However, as circuit technologies change over the past few years, e.g., SoC (system on chip) and 3D integration technologies, increased capabilities are needed to allow for proper testing.

In an effort to make progress in testing capabilities, a new Standard IEEE 1687-2014, commonly known as IJTAG (internal JTAG), was developed and issued in 2014 in the United states by IEEE entitled "IEEE Standard for Access and control of Instrumentation Embedded with a Semiconductor Device". This new standard introduces two significant changes with respect to the standard IEEE 1149.1:

analyzing the character string by the dynamic length; and

instrumentation is used through the JTAG string.

While experts have noted the potential areas that dynamic length analysis strings may bring, relatively little work has focused on the likelihood of instrument access. In fact, actual functional access to the instrument is not compatible with current test flows based on Automatic Test Pattern Generation (ATPG).

Therefore, there is a need in the art for a solution to generate and apply tests to integrated circuits that includes access to the instrument through a JTAG string.

Another difficulty in the field of automated testing is that as the density of circuits increases with the continued miniaturization of circuit elements, the test strings included in integrated circuits become more complex. This may result in an increase in the time required to perform the automatic test. Furthermore, the effective access interface of the circuit is usually determined at the last moment, which forces the conventional ATPG to perform complex switching operations. Therefore, there is also a need to provide a test apparatus and method that allows for fast execution of automatic test sequences.

Disclosure of Invention

It is an aim of embodiments of the present specification to at least partially address one or more problems of the prior art.

According to one aspect, there is provided a test apparatus for testing a device under test, the apparatus comprising: a test apparatus comprising a memory for storing data processing instructions and one or more processors arranged, when executing the data processing instructions, to: executing test code to perform test operations on a device under test, the test code defining one or more test patterns and one or more test algorithms to be applied to a test instrument of the device under test, the test code having a first format independent of a test interface between the test device and the device under test; and an interface controller coupled to the device under test and configured to convert communications generated by the test device during execution of the test code into a second format suitable for the test interface and to convert communications from the device under test into the first format.

According to one embodiment, the test apparatus comprises a plurality of interface controllers implemented by one or more processors of the test device or another device, the test device being arranged to select one of the plurality of interface controllers to perform the conversion.

According to one embodiment, the one or more processors of the test apparatus, or the one or more other processors of the test generation tool, are arranged to generate the test code before the test apparatus executes the test code.

According to one embodiment, the test equipment further includes a test interface coupling the interface controller to the device under test.

According to one embodiment, the test apparatus is arranged to execute in parallel a first test algorithm applied to a first test instrument and a second test algorithm applied to a second test instrument.

According to one embodiment, the one or more processors of the test device are further arranged to access an external library, the external library defining one or more further test algorithms for testing sub-circuits of the device under test.

According to one embodiment, the one or more processors of the test apparatus are arranged to generate the test code by including an external library into the test code, and/or by including function calls to one or more other test algorithms into the test code.

According to one embodiment, the sub-circuits implement data or signal processing functions, and one or more other test algorithms are arranged to verify the expected behaviour of the data or signal processing functions.

According to one embodiment, the sub-circuit implements an encryption function, and the one or more other test algorithms are arranged to provide encryption and/or decryption operations so as to allow the test generation tool to verify the behaviour of the encryption function.

According to another aspect, there is provided a test system comprising: the above test apparatus; and a device under test coupled to the test equipment, the device under test including a test access port and a plurality of test instruments, each test instrument including one or more analysis registers.

According to another aspect, there is provided a method for testing a device under test, the method comprising: executing, by the test device, test code to perform a test operation on the device under test, the test code defining one or more test patterns and one or more test algorithms to be applied to a test instrument of the device under test, the test code having a first format independent of a test interface between the test generation tool and the device under test; and in the testing phase: converting communications generated by execution of the test code and intended for the device under test into a second format suitable for the test interface; and converting communications from the device under test to the first format.

According to one embodiment, the method further comprises generating the test code by one or more other processors of the test apparatus or the test generation tool prior to executing the test code.

According to one embodiment, the method further comprises selecting, by the test device, one of the plurality of interface controllers to perform the conversion.

According to one embodiment, the method further comprises executing, by the testing device, a first testing algorithm applied to the first testing instrument and a second testing algorithm applied to the second testing instrument in parallel.

Drawings

These and other objects, features and advantages will be disclosed in detail in the following description of a specific embodiment, given for informational purposes, and in non-limiting fashion in conjunction with the accompanying drawings, wherein:

FIG. 1 schematically illustrates a typical ATPG;

FIG. 2 schematically illustrates the integrated circuit of FIG. 1 including a device under test in more detail;

FIGS. 3A and 3B schematically illustrate a test apparatus according to embodiments of the present description;

FIG. 4 is a flow chart showing steps in a method of applying automatic testing to an integrated circuit;

5A-5D schematically illustrate different applications of the test apparatus of FIGS. 3A and 3B according to embodiments of the present description;

FIG. 6 schematically illustrates a test generation tool according to another embodiment;

FIG. 7A schematically illustrates a portion of the test equipment of FIG. 3B adapted to test an FFT function (fast Fourier transform) according to an embodiment of the present description; and

FIG. 7B schematically illustrates a portion of the test equipment of FIG. 3B suitable for testing cryptographic functionality according to embodiments of the present description.

Detailed Description

Fig. 1 schematically shows a test apparatus 100 proposed based on standard IJTAG.

The integrated circuit 101 includes a Device Under Test (DUT)102 that is accessed, for example, by way of a Test Access Port (TAP)104 intermediary. In the example of FIG. 1, the TAP 104 is integrated into the same chip as the DUT102, but in an alternative embodiment, this may be a separate chip.

The TAP 104 communicates with a test controller 106, for example, through a test interface 108 intermediary. The test controller 106 executes test sequences in the DUT102 based on a test pattern (input pattern)110, which is intermediately loaded into the DUT102 by the TAP 104. For example, the test pattern is a bit sequence that is loaded into a test instrument included in the DUT102, for example, by using a boundary analysis operation using BDSL (boundary scan description language). This entails loading functional configurations into the DUT102, for example, by programming analysis registers based on a test pattern, and then by allowing the DUT102 to operate for one or more clock cycles before retrieving the modified data bits in the analysis registers. The modified data bits are then provided to the test controller to generate an output test pattern (output pattern)112, which is compared by the test controller 106, for example, to an expected test pattern (expected pattern) 114. If there is agreement between the output test pattern 112 and the expected test pattern 114, this means that the test was successfully performed. Patterns are sometimes referred to in the art as "vectors," and in this specification, these two terms are used as synonyms.

The input test patterns 110 and expected test patterns 114 are generated by a Test Generation Tool (TGT)116 based on various input files. For example, the TGT 116 receives a DfT (design test) file (DfT file) 118, a circuit description file (circuit description)120, and a FAULT MODEL (FAULT MODEL) 122. The DfT file 118 defines, for example, test equipment that is incorporated into the DUT102, which may include analysis registers/switches, BIST (built-in self test), etc. that may be accessed during analysis testing. The circuit description 120 defines circuit components of the DUT102, for example, in the form of a connection list. For example, the fault model indicates potential faults that may occur in the circuit design, so that test patterns may be generated to effectively cover these faults.

In the example of fig. 1, the TGT 116 also has a test interface (interface definition) 124 implemented between the TGT 116 and the DUT 102. In the example of FIG. 1, this interface is the JTAG interface that is mediated by the test controller 106.

Fig. 2 schematically shows an integrated circuit 101 according to an embodiment in more detail. In this example, the integrated circuit 101 includes three circuit blocks 102A, 102B, 102C that constitute the DUT102 in addition to the TAP 104. Circuit block 102A includes test instruments 202 and 204 coupled to TAP 104, e.g., via analysis string 206, circuit block 102B includes test instrument 208 coupled to TAP 104, e.g., via analysis string 210, and circuit block 102C includes test instruments 212, 214, and 216 coupled to TAP 104, e.g., via analysis string 218.

Referring now to fig. 1 and 2, to apply a test to each of the test instruments 202 through 216, for example, the TGT 116 wraps a test vector using PDL (process definition language) and allows the test controller 106 to apply the test vector. The vectors wrapped by the PDL may be scheduled and merged by the TGT 116 in order to minimize the duration of the test.

Standard IJTAG 1687 also allows for a higher level of interaction with test equipment during testing. In particular, standard IJTAG proposes a functional use in which the original instruments can be described and PDL can be defined on the boundary of these instruments. In particular, the PDL language defines the input/output values of the instrument, which are then compiled in order to obtain a higher level vector than the sequence of interface operations. This is commonly referred to in the art as "redirection". The simplest level 0 PDL language describes, for example, input/output (I/O) vector operations, while the level 1 PDL language introduces a raw data interface that can be used to interface the instrument with, for example, algorithms written in the dynamic programming language Tcl.

However, in the example of fig. 1, the TGT 116 is arranged to generate the input test pattern 110 and the expected test pattern 114 in a single step. Once the expected test patterns have been generated, the TGT 116 is no longer involved in the test process and the test controller implements the test by applying the test patterns to the DUT via the test controller 106 intermediary based on the PDL files. Thus, the test flow moves in a single direction from the TGT 116 to the DUT and there is no path back to the TGT 116 that allows execution of algorithms that change based on signals returned from the DUT.

Indeed, in the example of fig. 1, the generation of the test and the application of the test are two distinct steps in the product development, typically performed by different teams at different locations and at different times. Thus, the TGT 116 may not even be available when the test controller 106 applies the input pattern 110.

Furthermore, Tcl is continuous in nature, so ensuring that tests of different instruments are performed simultaneously is difficult and computationally burdensome, making it difficult to perform test algorithms in parallel in each instrument.

Another difficulty is that even if the TGT 116 is authorized to receive data patterns back from the DUT102 and execute algorithms to dynamically modify the input test patterns 110 during the test phase of the DUT102, such a test process will be slow and complex, as the TGT 116 should interpret output patterns based on the particular interface used between the TGT 116 and the DUT102, and the definition of the interface 124 should be considered during the determination of the manner in which to modify the test patterns. Furthermore, the simultaneous execution of multiple test algorithms by the TGT 116 will be slow because the TGT 116 often waits for a test to terminate before being able to execute another algorithm for another instrument.

Fig. 3A and 3B schematically illustrate a test apparatus according to one embodiment that addresses at least some of the difficulties described above with respect to the test apparatus 100 of fig. 1. Certain elements of fig. 3A and 3B are similar to those of the test apparatus 100 of fig. 1, and these elements have the same reference numerals and are not described in detail again.

FIG. 3A schematically illustrates modules for generating and executing test code 300A for a test device. This module 300A includes a Test Generation Tool (TGT)302 that differs from the TGT 116 of fig. 1 in several respects, as will be described in more detail below.

Like TGT 116 of FIG. 1, TGT302 receives, for example, DFT file 118, circuit description 120, and fault model 122, which will not be described in detail.

The TGT302 includes, for example, one or more processors that execute data processing instructions stored in an instruction memory (INSTR MEM) 304. For example, execution of these instructions causes the one or more processors of the TGT302 to be configured to generate and execute TEST CODE (TEST CODE)308 in order to TEST a DUT (not shown in fig. 3A). The test code includes, for example, one or more test patterns and one or more test algorithms applied to the instruments of the DUT. In one example, the test mode is defined by using a level 0 POL and the test algorithm is defined by using a level 1 POL and includes code written in a high level language such as Tcl. However, the term "test code" as used herein refers not only to code that includes test patterns and test algorithms, but also to executable code for implementing tests, as will be described in more detail below.

The test code, for example, has a format that is independent of the interface between the TGT302 and the DUT. For example, the TGT302 includes a memory that stores data defining an abstract interface (abstract interface)306, particularly an abstract format for testing code.

Fig. 3B schematically shows a portion 300B of test equipment, for example, connecting the TGT302 to the DUT 102. In this example, it is assumed that the test code is executed by the TGT302, in other words, the same device generates and executes the test code. However, in alternative embodiments, a separate device may be used to generate and execute test code, with execution being accomplished by any test device.

As shown in FIG. 3B, communications to the DUT102 generated by the execution of the test code 308 are provided to an interface controller (interface driver) 310, for example, by an abstract API (application Programming interface) intermediary. As known to those skilled in the art, an API in an application program provides an interface between a program written in a high-level language and a routine or function that performs a desired operation. These routines may be implemented in the same language or different languages and may be contained in a pre-compiled package of modules in the form of executable code or object code.

The interface controller 310 converts, for example, communications from the abstract format used by the test code to a format suitable for the interface between the TGT302 and the DUT 102. Similarly, the interface controller 310 converts communications, for example, from the DUT102 into the abstract format used by the TGT 302. The interface controller 310 is implemented, for example, by a separate circuit associated with the TGT302, although in alternative embodiments the functions of the interface controller may be implemented by code executed by one or more processors of the TGT 302.

The interface controller 310 is coupled to the test controller 106 through a proprietary API interface intermediary, such as a JTAG interface in the example of fig. 3B. Test controller 106 is intermediately coupled to integrated circuit 101 through interface 108. As shown in FIG. 1, the integrated circuit 101 includes, for example, a TAP 104 to interface with the DUT102, but in alternative embodiments the TAP 104 may be a separate chip from the DUT 102.

Execution of the test code 308 by the TGT302 causes the application of test patterns and test algorithms to the DUT102, e.g., via the interface controller 310 and the test controller 106, and data returned by the DUT102 is supplied back to the TGT302, e.g., so that it can be interpreted. In particular, execution of the test code results in the implementation of a test algorithm, and may result in the generation of output data (test output) 312.

In some embodiments, configuration information (configuration)314 is provided to the means executing the test code 308 and indicates, for example, the type of interface so that the appropriate interface controller to use during the test phase may be selected. For example, the test apparatus includes one or more other interface controllers 310 'for controlling different types of interfaces, and the test apparatus selects the appropriate interface controller 310, 310' based on the configuration information 314.

An advantage of providing the test code in an abstract format independent of the interface between the TGT302 and the DUT102 is that the test code is relatively fast to execute since the TGT302 does not need to consider the specific interface format. Furthermore, communication with the DUT102 is managed by the interface controller 310, which allows for parallel operation between the TGT302 and the interface controller 310. This means that the TGT302 does not need to wait for the DUT102 to receive and process communications with a given instrument of the DUT102 before continuing to execute test code for other instruments of the DUT 102.

A test method of a DUT using the test apparatus of fig. 3A and 3B will now be described in more detail with reference to fig. 4.

FIG. 4 is a flow chart illustrating steps in a DUT testing method according to an embodiment.

The method is implemented, for example, by the TGT302 and interface controller 310 of the test equipment of fig. 3A and 3B.

In step 401, the TGT302 generates test code in an abstract format that is independent of the interface connecting the TGT302 to the DUT 102. The abstract format is, for example, an intermediate format between the format used by the TGT302 and the format used by the interface with the DUT 302. The test code includes, for example, one or more test patterns and one or more test algorithms applied to the instruments of the DUT. The test code is generated, for example, based on one or several elements of the DFT file 118, the circuit description 120, and the fault model 122.

In step 402, test code is executed. For example, the test code includes test patterns and test algorithms packaged in code that can be executed by the processor of the TGT302, or more generally by the processor of any test device used to execute the test code. In some embodiments, execution of the test code requires application of multiple test algorithms in parallel to a corresponding plurality of test instruments of the DUT 102.

Execution of the test code also requires, for example, building a test instrument test model of the DUT102 that defines the position of the instrument in the analysis string and the instrument state. The instrument state includes, for example, the state of dynamic elements in the DUT, including Segment Insertion Bits (SIBs) and an analysis multiplexer. Thus, the test code itself does not include a system model, e.g., generated only during execution of the test code.

In step 403, during execution of the test code, the interface controller 310 converts the communication from the TGT302 to the DUT102 into a format suitable for the particular interface between the TGT302 and the DUT 102. These communications include, for example, one or more test patterns to be applied to the instrumentation of the DUT102 and one or more test algorithms to be applied to the instrumentation of the DUT 102.

In step 404, the interface controller 310 converts communications from the DUT102 to the TGT302 into an intermediate format so that they can be processed by the TGT 302. These communications include, for example, output test patterns of the DUT 102. These communications are used, for example, to update the state of the test instruments in the system model, which can then be used to generate other test patterns.

An example of a particular interface between the TGT302 and the DUT102 will now be described in more detail with reference to fig. 5A-5D.

Fig. 5A schematically illustrates a portion 300B in which the interface between the TGT302 and the DUT102 is provided by an FTDI chip (Future Technology Devices International Ltd) 502 that converts, for example, a USB (universal serial bus) interface to a JTAG interface (JTAG)504, according to an embodiment. In this embodiment, the interface controller 310 includes, for example, a LibFTDI driver (LIB FTDI driver), which is, for example, a low-level code for controlling the FTDI chip 502, and the configuration information 314 identifies, for example, the LibFTDI driver so that the driver can be selected for translation.

Fig. 5B schematically illustrates a portion 300B of a test equipment according to an alternative embodiment with respect to fig. 5A, in which the DUT102 is accessed through an Automated Test Equipment (ATE)508 intermediary, e.g., a device typically used in manufacturing. In this case, the interface between the TGT302 and the DUT102 is implemented, for example, by a high-speed interface 510, such as a fiber optic interface, controlled by the interface controller 310, the interface controller 310 including an ATE specific framework (atespecfic frame) that communicates with line cards (line cards)512 that are responsible for the physical interface with the DUT 102.

Fig. 5C schematically shows a portion 300B of a test apparatus according to an alternative embodiment with respect to fig. 5A and 5B, in which a DUT is simulated. In this case, the DUT102 is implemented, for example, by using a hardware description language, such as VHDL language (VHSIC (very high speed integrated circuit) hardware design language) or Verilog, and the simulation is controlled by the high-level test bench SVVERILOG 516. In this example, the testbench is implemented by using HDL SystemVerilog (SV). The interface between the TGT302 and the DUT102 is done by a DPI (direct programming interface) intermediary and DPI calls 518 implementing the interface controller 310 and the DUT102 is accessed by using a DPI-enabled simulator (DPI-enabled simulator)520 including a test bench SV (SV testbench) 516.

Fig. 5D schematically shows a portion 300B of the test apparatus according to an embodiment similar to fig. 5C, wherein the DPI-enabled simulator 520 further comprises a pattern snooper (pattern snooper) 524. Mode snooper 524 enables, for example, static patterns 526 to be extracted from DUT102 and deposited in a known format. The advantage of this embodiment is that the operation is similar to that of a conventional ATPG (automatic test pattern generation) system, so that the test setup of fig. 5D is backward compatible. Instead of using a simulator 520 supporting DPI, this embodiment can be implemented by using a simulation without a simulator, in order to provide a pattern without time elements with a low computational effort.

An advantage of the test apparatus described herein is that a relatively complex test algorithm can be applied to test a particular circuit of the DUT102 by using the TGT 302. For example, in the past, circuit testing implemented complex functions such as Fast Fourier Transform (FFT) or encryption functions, which required the use of a dedicated BIST (built-in self test), consuming valuable space on the chip. For example, the TGT302 can generate test code that includes code implementing such complex test algorithms, or that includes function calls to libraries storing code to execute such complex test algorithms, e.g., as will now be described with reference to fig. 6, 7A, and 7B.

FIG. 6 shows a module for generating and executing test code 300A according to another embodiment similar to FIG. 3A, but wherein an external library 602 is also included, coupled to the TGT 302. This external library 602 stores complex test algorithms that may be applied to instruments of the DUT, for example.

Fig. 7A schematically illustrates an example in which the DUT102 includes FFT circuitry (not shown) that implements FFT functionality, and includes instrumentation that provides a test interface for the FFT circuitry. The external bank 602 of fig. 6 comprises, for example, an FFT bank defining test sequences for testing FFT functions and verifying the response of the output. A dedicated algorithm (custom algorithm)704 is incorporated into the test code 302, for example, to implement a complex test algorithm for the FFT. Further, the FFT library 706 is incorporated into the test code, for example, so as to be accessible during the test phase. As shown, the output of raw data from the FFT circuitry of the DUT102 may provide a complex waveform 708, which in this example indicates the amplitude of the output signal as a function of the frequency of the input signal, and the dedicated algorithm 704 and library 706 may allow the TGT302 to verify such a waveform.

Fig. 7B schematically illustrates another example, in which the DUT102 includes an encryption circuit (not shown) that implements encryption functionality, and includes instrumentation that provides a test interface for the encryption circuit. In this case, the external library 602 of fig. 6 includes, for example, an encrypted library. In addition to the dedicated algorithm 704, the test code 302 of FIG. 7B also includes a function call 710, for example, to an encryption library 712 to allow encryption functions to be performed and, by doing so, to make it possible to verify the proper operation of the encryption circuit. In particular, the encryption vault receives, for example, simple text via function call 710 and returns the encoded data to function call 710. Instead of this or in addition, the encryption library 712 may perform a decryption operation and may receive encrypted data from the function call 710 and return simple text to the function call 710.

While at least one exemplary embodiment has been described, various alterations, modifications, and improvements will readily occur to those skilled in the art. For example, it will be apparent to those skilled in the art that although embodiments of TGT have been described in which test code is generated and executed, in other embodiments, the execution of the test code may be performed by a device separate from the TGT.

Furthermore, it will be apparent to those skilled in the art that although some examples of complex test algorithms for testing FFT circuits have been described, the same principles may be applied to other types of circuits under test, for example any data or signal processing algorithm, or any analog circuit (e.g. an analog-to-digital converter).