Apparatus, method and computer program for testing device under test, separating errors within received mode associated with different functional blocks of device under test or associated with different blocks of one or more bits

Abstract

A test arrangement (100; 100 ') for testing a device under test. 200); 300); 500) is configured to receive data from the device under test (102; 202); 302), the pattern comprising information from a plurality of functional blocks of the device under test. The test apparatus is configured to separate errors within receive modes associated with different functional blocks of the device under test during execution of the test program, or the test apparatus is configured to separate errors within receive modes associated with different blocks of one or more bits during execution of the test program. A method and computer program are also described.

Description

[0001] manual Technical Field

[0002] An embodiment according to the present invention relates to a testing apparatus for testing a device under test.

[0003] A further embodiment according to the invention relates to a method for testing a device under test.

[0004] Further embodiments relate to the results for each core processor. Background Art

[0005] Testing is an important step in the production of electronic circuits, such as integrated circuits. However, the increasing complexity of electronic circuits, such as integrated circuits, poses a major challenge.

[0006] Therefore, in order to improve the best utilization of available bandwidth for scan and functional testing, players in the EDA software and test design fields have begun to study methods to interleave test patterns for different cores when sending test patterns to the device under test (DUT) through the test interface, rather than sending pure (e.g., single-core) patterns to the target IP cores one by one (individual cores).

[0007] Here, "core" means a basic unit of logic design (in the context of this application) that should be analyzed separately in testing (e.g., unit of test, granularity of test results). For example, a core can be considered a functional block of a device under test.

[0008] Given this situation, a concept is needed that can provide a good trade-off between complexity, test coverage, and test time when test patterns of different cores are intertwined. Summary of the invention

[0009] According to an embodiment of the present invention, a test device (e.g., a test processor or a channel module of an automatic test device or an automatic test device) for testing a device under test is created. The test device is configured to receive a pattern (e.g., a result pattern; e.g., a response pattern) from the device under test, and the pattern includes (e.g., in a combined form; e.g., in an interleaved form) information (e.g., test results; e.g., test response information; e.g., a bit sequence) from (e.g., related to) multiple functional blocks (e.g., "cores"; e.g., result blocks; e.g., functional blocks that provide substantially independent test results or test responses) of the device under test. The test device is configured to separate (e.g., process or record separately) errors within the received pattern associated with different functional blocks of the device under test (e.g., separate errors of different cores) during the execution of a test program (e.g., in order to obtain test results for each functional block (e.g., each core) of the device under test during the execution of the test program).

[0010] We have recognized that, where test results for multiple functional blocks of a device under test are merged into a common result pattern (e.g., output in a time-multiplexed manner via a single pin of the device under test), separating errors within a received pattern associated with different functional blocks of the device under test during test program execution can efficiently test the device under test while avoiding storage of complete receive patterns that are typically provided at very high data rates.

[0011] For example, separating errors within a received pattern associated with different functional blocks of a device under test may allow very fast understanding of which functional blocks of the device under test include errors, e.g., without the need to store or buffer received test patterns. In some cases, the concept may even allow a rough understanding of which functional blocks of the device under test have "critical" failures (large numbers of errors within the received pattern associated with critically failed functional blocks) during or shortly after the test program execution. For example, knowing a priori the positions (e.g., bit positions) associated with different functional blocks within a received pattern (or test result bits assigned to different functional blocks) may allow very fast separation of errors associated with different functional blocks (within a received pattern), even during the test program execution.

[0012] Thus, during the execution of the test program or shortly after its completion, separate information about the failures of different functional blocks of the device under test can be obtained, and decisions on (further) test flows can be made based on the information about the failures of different functional blocks (indicated by errors in the received pattern at the positions of the bits associated with the functional blocks comprising the failures).

[0013] In summary, separating errors associated with different functional blocks of the device under test within a received pattern during the execution of a test program (which results in information indicating failures of different functional blocks, for example, separately for independent functional blocks) can reduce the complexity of the test, because when separating errors associated with different functional blocks of the test device (within the received pattern) "during runtime" (during execution of the test program), it may not be necessary to store the complete received pattern for subsequent analysis.

[0014] Thus, summary information can be obtained, which indicates, for different functional blocks of the device under test or even for each functional block of the device under test, whether the functional block of the device under test has an error generated within the received pattern. Thus, the above-mentioned test device can effectively identify one or more failed functional blocks of the device under test during the execution of the test program, even if the test results of multiple functional blocks are combined within the received pattern (for example in a combined bit stream), wherein, for example, different positions within the received pattern can be associated with test results in different functional blocks of the device under test, and wherein, for example, the test device can separate test results (for example, comparison results with expected bit values) from different functional blocks of the device under test (or caused by different functional blocks of the device under test) based on the association of the functional blocks of the device under test with the positions of the bits within the received pattern.

[0015] The (separate) detection of faults of different functional blocks of the device under test can be achieved very efficiently, since by separating the errors associated with different functional blocks within the received pattern during the test program execution, there is no need to upload the received pattern to a separate processing unit for post-processing. In particular, by separating the errors within the received pattern during the test program execution (rather than as a post-processing step), there may be no need to save the received pattern for later detection of errors within the received pattern. Thus, very good functionality can be achieved with relatively low complexity, which helps to improve test efficiency and test speed.

[0016] The test fixture thus offers a good trade-off between complexity, functionality provided, and test speed.

[0017] In an embodiment, the test device is configured to separate errors within a received pattern associated with different functional blocks of the device under test in real time (e.g., without buffering or logging the complete received pattern before starting to separate errors associated with different functional blocks of the device under test; e.g., before a continuous stream of test patterns is completely received by the test device; e.g., without recording the received stream).

[0018] By separating errors within a received pattern associated with different functional blocks of the device under test in real time, buffering or recording of the entire received pattern (which would be very resource intensive) can be avoided. Thus, the real-time association of the positions of bits within the received pattern with the different functional blocks of the device under test can be used to distinguish and / or separate error information associated with the different functional blocks of the device under test (e.g., indicating errors within the received pattern). For example, error information associated with different functional blocks of the device under test can be allocated to different error registers or error counters (associated with different functional blocks of the device under test). Thus, by using "on-the-fly" separation of errors within a received pattern (or equivalently, instant routing of error information indicating errors within the received pattern), it helps to reduce or minimize the workload of buffering the received pattern and further avoid delays caused by post-processing performed after the test program is executed.

[0019] In a preferred embodiment, the test apparatus is configured to separate errors within a received pattern associated with different functional blocks of the device under test in real time (e.g., at the same rate as the data rate at which the received pattern is received from the device under test) and / or to separate errors within a received pattern associated with different functional blocks of the device under test in time synchronization with the data rate at which the received pattern is received from the device under test.

[0020] By separating the errors in the received pattern associated with different functional blocks of the device under test in real time, it is not necessary to buffer most of the received pattern or even all of the received pattern. Instead, separating the errors in real time (or equivalently, separating the formation of errors indicating errors in the received pattern) can make error information indicating errors in the received pattern already available during the reception of a continuous pattern. In other words, error information describing errors occurring in the first part of the received pattern can be obtained before the test device receives subsequent parts of the same continuous pattern. Moreover, in some cases, only a very short part of the received pattern required for actual error detection can be buffered, and after the errors are separated (in real time), the received pattern can be discarded. In some implementations, buffering of the received pattern can even be avoided completely. Therefore, we have realized that separating the errors (or more precisely, separating the error information describing errors in the received pattern) helps to improve the efficiency of error handling and enable rapid acquisition of error information.

[0021] However, in some embodiments, the tester hardware detects errors within the received pattern in real time ("precisely"). This means that the so-called "edge comparators" analyze the logic levels at the programmed time and compare them with the expected state. For example, the errors identified in the process are first merged within a so-called test processor period (for example, up to 8 comparators) and then, for example, merged within a so-called comparator word (for example, the 3 comparators mentioned above). In this sense, further processing (fault analysis with respect to the core to which it belongs) is no longer instantaneous, but is (only) delayed for a very short time, for example, a few nanoseconds. However, from the global point of view of data processing (and from the perspective of the present application), this processing is considered to be "real time". In addition, this processing is closely synchronized in time with the data rate at which the received pattern is received from the device under test and is synchronized in time with the data clock at which the received pattern is received from the device under test.

[0022] In a preferred embodiment, the test apparatus includes dedicated hardware (eg, a multiplexer) configured to separate errors within the received pattern associated with different functional blocks of the device under test.

[0023] By using dedicated hardware to separate errors within the received pattern, particularly fast and efficient processing can be achieved. It is particularly important to note that the received pattern typically includes very high data rates, so such dedicated hardware is particularly advantageous, allowing "real time" or "on the fly" processing and separation of errors associated with different functional blocks of the test equipment.

[0024] In particular, the use of dedicated hardware can eliminate the need for storage of received patterns, which in turn significantly reduces the resource requirements of the concept. Furthermore, it has been recognized that dedicated hardware is generally more energy efficient than microprocessor-based (e.g. software-controlled) separation of errors within received patterns. Accordingly, by using dedicated hardware, errors associated with different functional blocks of the device under test within the received pattern can be separated even before the error bits are recorded, and hardware-based error separation can also be used to control the recording of error bits of the received pattern.

[0025] In summary, we have realized that using dedicated hardware to separate errors associated with different functional blocks of the device under test within a received pattern can improve power efficiency and also provide error information indicative of (or describing) the errors associated with the different functional blocks of the device under test very quickly. Therefore, the error information obtained by separating the errors associated with the different functional blocks of the device under test can be used for further processing steps, such as recording the error bits of the received pattern.

[0026] In a preferred embodiment, the test apparatus comprises dedicated hardware (e.g., a multiplexer; e.g., a core mapper) configured to selectively forward an error signal indicating a deviation of a bit value of a bit of a received pattern associated with a certain functional block of the device under test (e.g., at a bit position associated with a certain functional block of the device under test) from an expected bit value defined by an expected pattern to a result unit (e.g., an error flag register, or an error counter) (e.g., among a plurality of result units associated with different functional blocks of the device under test, or among result units associated with different bit positions of a received pattern), the error signal indicating a deviation of a bit value of a bit of a received pattern associated with a certain functional block of the device under test (e.g., at a bit position associated with a certain functional block of the device under test) from an expected bit value defined by an expected pattern, the result unit being associated with a certain functional block of the device under test (or, equivalently, associated with a bit position within the received pattern). For example, the dedicated hardware may determine to which result unit the error signal should be forwarded based on the position of the bit currently under consideration and using an assignment rule that defines an association of a bit position with a functional block of the device under test, or, equivalently, defines an association of a bit position.

[0027] By selectively forwarding an error signal indicating a deviation of a bit value of a received pattern associated with a certain functional block of the device under test from an expected bit value defined by an expected pattern to a result unit associated with a certain functional block of the device under test, errors within a received pattern associated with different functional blocks of the device under test can be separated very quickly and efficiently. For example, the comparison between the bit values ​​of the expected bits defined by the expected pattern and the bits of the received pattern can be performed in hardware in a particularly efficient manner, wherein it should be noted that the current test apparatus includes a powerful and efficient mechanism for providing an electrical signal representative of the expected pattern.

[0028] Thus, for example, the output signal of an extremely fast comparator that compares an electrical signal representation of a received pattern with an electrical signal representation of an expected pattern can provide a result signal (e.g. in the form of an electrical signal), which (comparison) result signal can also be considered as an error signal, which can, for example, be efficiently distributed using a multiplexer (thereby selectively forwarding the error signal to the corresponding result unit).

[0029] It is also recognized that the selective forwarding of the error signal to the corresponding result units (e.g., different result units may be associated with different functional blocks of the device under test) may be controlled by a hardware mechanism that tracks the association of the bits (or positions of bits) of the received pattern with the different functional blocks of the device under test. Accordingly, the selective forwarding of the error signal (e.g., via a multiplexer) to the different result units may be controlled by a functional block (of the test apparatus) that tracks the association of the positions of the bits of the received pattern with the different functional blocks of the device under test.

[0030] Thus, the separation of errors associated with different functional blocks of the device under test can be achieved in a fast, reliable and energy-efficient circuit by dedicated hardware. In addition, different result units that can be associated with different functional blocks of the device under test can respectively record errors associated with different functional blocks of the device under test or count errors associated with different functional blocks of the device under test so as to provide information (e.g., separate information) about the occurrence of one or more errors in different functional blocks of the device under test in the resource unit. Accordingly, the information provided by the result unit can be used to evaluate the device under test and / or for controlling the test process and / or for any other test purpose.

[0031] In a preferred embodiment, the test device includes dedicated hardware configured to selectively prohibit comparison (e.g., performed by a comparator) between one or more bits of a received pattern associated with a functional block of the device under test (e.g., at the position of a bit associated with the functional block of the device under test) and one or more corresponding bits of an expected pattern (e.g., based on the logic block or functional block to which the identified error belongs), and / or selectively prohibit forwarding the results of the comparison (e.g., performed by a comparator) between one or more bits of a received pattern associated with a functional block of the device under test (e.g., at the position of a bit associated with the functional block of the device under test) and one or more corresponding bits of an expected pattern (e.g., based on the logic block or functional block to which the identified error belongs) and / or selectively prohibit processing the results of the comparison (e.g., performed by a comparator) between one or more bits of a received pattern associated with a functional block of the device under test (e.g., at the position of a bit associated with the functional block of the device under test) and one or more corresponding bits of an expected pattern (e.g., based on the logic block or functional block to which the identified error belongs).

[0032] Using this concept, the processing of errors associated with one or more specified functional blocks of the device under test can be selectively shielded. This is particularly useful if it has been recognized that a certain functional block of the device under test will generate a large number of errors that will block further processing units. For example, the mechanism can be used to disable the recording or more detailed analysis of such errors, which may help to maintain (save) sufficient resources to handle errors caused by functional blocks of the device under test that only exhibit a small number of (and properly manageable) errors. Therefore, for example, when a functional block of the device under test is found to cause too many errors in the received mode in a previous run of the test program (or a part of the test program), the test device may not have to handle these large numbers of errors and focus on the testing of other functional blocks of the device under test. Therefore, in some cases, the test efficiency can be significantly improved, thereby also shortening the test time.

[0033] In other words, it is possible to avoid wasting test resources on functional blocks of the device under test that generate excessive errors in the received pattern.

[0034] In a preferred embodiment, the test apparatus includes dedicated hardware configured to identify different blocks of one or more bits of a received pattern associated with different functional blocks of the device under test in order to separate errors within the received pattern associated with different functional blocks of the device under test.

[0035] By using dedicated hardware to identify different blocks of one or more bits of a received pattern associated with different functional blocks of a device under test, the separation of errors within the received pattern associated with different functional blocks of the device under test can be facilitated. For example, the periodicity of the association between different blocks of one or more bits of the received pattern and the functional blocks of the device under test can be utilized to effectively identify different blocks of one or more bits of the received pattern associated with different functional blocks of the device under test. In addition, the dedicated hardware can take advantage of the fact that there may be well-defined association rules between blocks of one or more bits of the received pattern and the functional blocks of the device under test. For example, the association pool can be defined by a repeating sequence, where the block length of one or more bits associated with different functional blocks of the device under test can be known (e.g., can be predetermined, or can be defined in a lookup table or similar table). However, by using dedicated hardware to identify different blocks of one or more bits of a received pattern associated with different functional blocks of the device under test, a fast and low-power solution is provided to separate errors based on the identification of blocks of one or more bits of a received pattern associated with different functional blocks of the device under test.

[0036] We have found that using such a table can effectively and configurably identify different blocks of one or more bits of a received pattern associated with different functional blocks of a device under test. In particular, a table defining the names of blocks of one or more bits of a received pattern associated with different functional blocks of a device under test is found to be an effective and configurable description of typical recurring occurrences of bits within a received pattern associated with different functional blocks of a device under test. Furthermore, we have also realized that such a table can be efficiently evaluated using dedicated hardware, thereby enabling efficient implementation.

[0037] In a preferred embodiment, the test apparatus comprises a reference pattern generator configured to generate a time signal representing an expected pattern, wherein the test apparatus comprises a comparator circuit configured to compare the time signal representing the received pattern with the time signal representing the expected pattern, wherein the comparator is configured to provide error signaling (e.g., by activating an error signal) in response to deviations between bits of the expected pattern and bits of the received pattern (wherein the test apparatus is configured to selectively activate and / or deactivate comparisons performed by the comparator, and / or wherein the test apparatus is configured to selectively forward the error signal to one of a plurality of result units based on the position of a current bit, thereby isolating errors within the received pattern associated with different functional blocks of the device under test).

[0038] We have recognized that this concept can be efficiently implemented using reference pattern generators and comparator circuits, where the reference pattern generator can often be multiplexed for other functions in the test fixture. In addition, the comparator can also be used to test traditional devices under test that do not multiplex the test results of multiple functional blocks in a single signal. Therefore, we have recognized that this implementation is particularly efficient and well suited for integration into a test fixture.

[0039] In a preferred embodiment, the test apparatus is configured to separately track test results (eg error flags, error counts) for different functional blocks of the device under test (wherein the test results may be based on errors within the received pattern, for example).

[0040] Accordingly, the test device can provide separate information indicating whether a function block has generated an error and / or indicating how many errors a function block has generated. Thus, during the execution of the test program, an overview of the error status of different function blocks (whether an error has occurred or how many errors have occurred) is already available, and for example, test flow decisions can be made based on the overview. In addition, basic test results, such as whether a function block of the device under test has generated an error, are available without further post-processing (complete) after the test program has been completed, which makes the test very time-efficient.

[0041] In a preferred embodiment, the test device is configured to separately track test results (e.g. error flags, error counts) of different functional blocks of the device under test, which test results are obtained based on a (e.g. common) received pattern, by test mode (e.g., the test device can read out one or more result units between providing subsequent test modes to the device under test, and / or, wherein the test device can, for example, reset one or more result units between providing subsequent test modes to the device under test) or by test execution (where, for example, the test execution may include providing multiple test modes (to the device under test)).

[0042] Thus, an overview of the integrity of the different functional blocks of the device under test can be effectively obtained on a per test mode basis (if necessary). Alternatively, if sufficient, an overview of the integrity of the different functional blocks can also be obtained on a per test execution basis. In other words, for example, result units that individually record (or count) the test results of the different functional blocks of the device under test can be read out per test mode. This provides the user of the test flow control or the test device with information which test modes lead to the generation of one or more errors in the different functional blocks of the device under test. Thus, the user of the test flow control or the test device can obtain informative test results, wherein during the execution of the test program, the errors related to the different functional blocks of the device under test are separated, and these meaningful test results can be provided very quickly.

[0043] A result unit that tracks the test results of different functional blocks individually may, for example, provide a "hold" function (to temporarily save the test results) and / or a reset function (to perform a reset at a time defined, for example, by the test program). In addition, it should be noted that the test program may also control the reading out of the result unit (to track the test results of different functional blocks of the device under test individually) and / or the resetting of the result unit.

[0044] Therefore, meaningful information can be provided efficiently and with no (or very little) delay.

[0045] In a preferred embodiment, the apparatus comprises a plurality of result units associated with different functional blocks of the device under test. The test apparatus is configured to selectively reset one or more result units (e.g., between providing subsequent test modes to the device under test), and / or the test apparatus is configured to selectively freeze one or more result units (e.g., between providing subsequent test modes to the device under test).

[0046] By selectively resetting one or more result units and / or selectively freezing one or more result units, it is possible (e.g. for a test program or a test flow control) to determine in which time sections results describing errors provided by different functional blocks of the device under test are to be determined. For example, by resetting the result units, the result units can be prepared for the recording of results of an expected part of the test program. Furthermore, by freezing the result units, it is also possible to make the result units immune to errors occurring during a certain part of the test program. Furthermore, by resetting and / or freezing the result units, e.g. under the control of the test program, it can be ensured that reliable and meaningful results are read out of the result units.

[0047] In a preferred embodiment, the test apparatus is configured to compare the received pattern with the expected pattern. In addition, the apparatus is further configured to separately register comparison failures associated with different blocks of one or more bits of the received pattern and / or to separately register comparison failures associated with different functional blocks of the device under test (wherein different blocks of one or more bits of the received pattern may be associated with different functional blocks of the device under test).

[0048] By comparing the received pattern with the expected pattern and separately registering comparison failures associated with different blocks of one or more bits of the received pattern and / or separately registering comparison failures associated with different functional blocks of the device under test, the test apparatus can effectively determine (e.g., record) errors occurring in different functional blocks of the device under test, because different blocks of one or more bits of the received pattern are generally associated with these different functional blocks of the device under test. Therefore, meaningful test result information can be provided, indicating the integrity of different functional blocks of the device under test.

[0049] In a preferred embodiment, the test device is configured to register comparison failures associated with different functional blocks of the device under test by using a mapping scheme that defines the association of bits of the received pattern with different result units (such as error flag registers or error counters) that register comparison failures, and / or by using a mapping scheme that defines the association of bits of the received pattern with different functional blocks of the device under test.

[0050] For example, a mapping scheme defining the association between bits of a received pattern and different result units registering a comparison failure may be equivalent to a mapping scheme defining the association between bits of a received pattern and different functional blocks of a device under test. For example, different result units may be associated with different functional blocks of a device under test.

[0051] This concept of utilizing a mapping scheme can provide test results that characterize the integrity of the device under test in a specific meaningful way, namely, separately for each functional block of the device under test. The mapping scheme can reflect the result bits associated with different functional blocks of the device under test into the pattern received by the test device. Therefore, the test results can help the user of the test flow control or automatic test equipment to make judgments about the device under test, wherein the provision of test results usually has very low latency because the separate registration of comparison failures can usually occur during the execution of the test program, wherein, for example, the mapping scheme can be implemented in such a way that the evaluation can be performed "on the fly" or in real time.

[0052] In a preferred embodiment, the test apparatus comprises a plurality of separate result units, which are configured to (e.g., separately) track test results (e.g., failures) associated with different functional blocks of the device under test (e.g., separately track deviations of different blocks of bits of a received pattern from corresponding bits of an expected pattern; e.g., separately track deviations of bits of a received pattern (e.g., blocks of bits) associated with different functional blocks of the device under test from corresponding bits of an expected pattern).

[0053] By using separate result units (which separately track test results associated with different functional blocks of the device under test), the integrity of different functional blocks of the device under test can be determined separately. Therefore, functional blocks of the device under test that exhibit one or more errors can be separated from non-defective functional blocks very quickly and efficiently. For example, if the separate result units are implemented using independent hardware (e.g., using independent error registers that are set when an error first occurs in a received pattern associated with a given functional block of the device under test and reset, for example, by a dedicated reset signal, or using independent counters, each of which counts errors within a received pattern associated with one or more functional blocks of the device under test), meaningful test results can be obtained quickly and efficiently, for example, without any post-processing of the received pattern using a microprocessor. Since the independent separate result units can be "triggered" in real time or "triggered" synchronously with the data clock of the incoming received pattern (e.g., to register errors associated with a certain functional block of the device under test), it may not be necessary to buffer a large part of the received pattern. We have found that implementing the separate result units in hardware is particularly suitable for such applications.

[0054] In a preferred embodiment, the test arrangement comprises a plurality of separate error flag registers associated with different functional blocks of the device under test.

[0055] We have found that implementing separate error flag registers requires very little effort. For example, separate error flag registers may be "sticky" registers that are set when an error associated with a corresponding functional block of the device under test first occurs. Thus, for example, each error flag register may be associated with one or more functional blocks of the device under test, and an error in a received pattern from the one or more corresponding functional blocks of the device under test may cause the error flag register to be set. Thus, the state of an error flag register may effectively indicate whether one or more functional blocks associated with the corresponding error flag register exhibit an error (such that one or more bits in the received pattern associated with the functional block deviate from an expected bit value). Thus, the error flag registers provide very concise "pass / fail" or "pass / fail" information for different functional blocks of the device under test, wherein such "pass / fail" information may be very helpful for classifying the device under test and / or making decisions about test flows.

[0056] In a preferred embodiment, the test apparatus comprises a plurality of separate error flag registers configured to be set in response to comparison errors (e.g. deviations) between bits of a received pattern and corresponding bits of an expected pattern occurring in different blocks of one or more bits of the received pattern (wherein, for example, different separate error flags are (individually) associated with comparison errors in different blocks of one or more bits of the received pattern, e.g., different blocks of one or more bits of the received pattern are associated with different functional blocks of the device under test).

[0057] We have found that such an arrangement can obtain meaningful test results, wherein it can be decided which individual error flag register should be set based on the separation of errors associated with different functional blocks of the device under test. For example, the above-mentioned multiplexer controlled according to a mapping rule or mapping scheme can be used to decide which individual error flag register of a plurality of error flag registers is to be set in response to an error signal. For example, the error signal can be selectively forwarded based on the distinction of different blocks of one or more bits of the received pattern. In summary, the individual error flag registers can constitute a very effective method of obtaining test result information.

[0058] In a preferred embodiment, the test arrangement comprises a plurality of individual error counters associated with different functional blocks of the device under test.

[0059] The presence of separate error counters can, for example, be very helpful in obtaining meaningful test information about different functional blocks, for example it can count errors within the received pattern associated with different functional blocks of the device under test separately. For example, the error counters can identify how many errors the different functional blocks have generated in the received pattern. Thus, it is possible to distinguish between functional blocks that do not generate any errors, functional blocks that generate only a few errors and functional blocks that generate a large number of errors. Therefore, the count values ​​of the separate error counters can be evaluated to classify the different functional blocks of the device under test and thus be used to obtain an overall classification of the device under test and / or to control the test flow. Therefore, the use of separate error counters is obviously a very powerful tool that can provide meaningful insights into the functionality of the device under test.

[0060] In a preferred embodiment, the test apparatus includes a plurality of individual error counters configured to increment in response to comparison errors (e.g., deviations) between bits of the received pattern and corresponding bits of the expected pattern occurring in different blocks of the one or more bits of the received pattern (where, for example, different individual error counters are (individually) associated with comparison errors in different blocks of the one or more bits of the received pattern; where, for example, different individual error counters are configured to count errors in different blocks of the one or more bits of the received pattern; where, for example, different blocks of the one or more bits of the received pattern are associated with different functional blocks of the device under test).

[0061] We have found that such separate error counters can efficiently and quickly obtain meaningful test information about different functional blocks of the device under test.

[0062] In a preferred embodiment, the test apparatus is configured to selectively set an error flag (e.g., a single error flag; e.g., a sticky error flag that remains active until explicitly reset) from a plurality of individual error flags (e.g., associated with different functional blocks of the device under test) in response to detecting a deviation of bits of the received pattern from bits of an expected pattern (e.g., a reference pattern) and according to an association rule (e.g., defining an association between bits of the received pattern and functional blocks of the device under test, and / or an association between bits of the received pattern and error flags; e.g., it may route an error signal indicating a comparison error to a set input of a corresponding error flag register). The association rule may, for example, be flexible, e.g., programmable in some form.

[0063] The use of a concept in which an association rule determines which of a plurality of individual error flags should be set in response to detecting a deviation between a bit of a received pattern and a bit of an expected pattern constitutes an efficient mechanism for processing received patterns in which different bits or groups of bits are associated with different functional blocks of a device under test. Thus, different individual error flags may signal errors caused by different functional blocks of the device under test. However, by using flexible association rules (e.g., programmable association rules), the test apparatus may be adapted to different devices under test, in which the association between the position of a bit in a received pattern and a functional block of the device under test may differ for different devices under test.

[0064] In a preferred embodiment, the test apparatus is configured to set a separate error flag associated with a given functional block of the device under test in response to detecting a deviation of bits of a received pattern associated with a given functional block of the device under test from an expected pattern, so as to separately register comparison failures associated with different functional blocks of the device under test.

[0065] Thus, by setting individual error flags in response to detecting deviations from an expected pattern of bits of a received pattern associated with a given functional block of the device under test, meaningful test result information characterizing different functional blocks of the device under test may be obtained without difficulty.

[0066] In a preferred embodiment, the test device is configured to selectively increment an error counter (e.g., a separate error counter) from a plurality of separate error counters (associated with different functional blocks of the device under test) in response to detecting a deviation between bits of the received pattern and bits of an expected pattern (reference pattern) and according to an association rule (defining an association between bits of the received pattern (e.g., a block of bits of the received pattern) and functional blocks of the device under test, and / or an association between bits of the received pattern and an error counter; for example, the association rule may route an error signal indicating a comparison error to an increment input of a clock input of a corresponding error counter).

[0067] By using this configuration, detailed information about the integrity of different functional blocks of the device under test can be obtained with only a small amount of effort. For example, the association rules determine which error counter is incremented when a deviation between the bits of the received pattern and the bits of the expected pattern is detected. To this end, the association rules can be based on a priori knowledge, i.e., which bit positions in the received pattern are associated with which functional blocks of the device under test. As a result, very meaningful error information characterizing the device under test can be obtained very quickly without requiring a lot of processing time.

[0068] In a preferred embodiment, the test device is configured to increment a separate error counter associated with a given functional block of the device under test in response to detecting a deviation of bits of a received pattern associated with a given functional block of the device under test from an expected pattern, so as to count comparison failures associated with different functional blocks of the device under test respectively.

[0069] Thus, reliable characterization of different functional blocks of the device under test can be achieved using low-complexity hardware, etc. For example, meaningful error information about different functional blocks of the device under test can be obtained without the need for evaluating the received pattern using a microprocessor.

[0070] In a preferred embodiment, the apparatus is configured to record individual failure information (e.g., after the test is performed, it can be uploaded to a workstation for detailed analysis), indicating the corresponding failure positions of multiple comparison failures (so that the individual failure information describes the position of the actual bit of the corresponding comparison failure within the received pattern). In addition, the apparatus is configured to obtain summary failure information (e.g., summary failure map; e.g., information describing the status of multiple error flag registers; e.g., information describing the status of multiple error counters), and describe the errors (e.g., comparison errors) associated with different functional blocks of the device under test in summary form (e.g., in the form of a separate binary value for each functional block of the device under test, indicating whether at least one bit in the received pattern associated with the corresponding functional block of the device under test deviates from the corresponding bit of the reference pattern, or in the form of a single counter value for each functional block, indicating the number of bits in the received pattern associated with the corresponding functional block of the device under test that deviate from the corresponding bit of the reference pattern).

[0071] We have found that determining individual failure information (which can determine exactly which bit in the received pattern is erroneous) and summary failure information (which only shows which different functional blocks of the device under test have generated errors in the received pattern (and optionally provides information on how many errors the functional blocks have generated in the received pattern) can enable efficient testing of the device under test. For example, the summary failure information usually does not include precise information on the positions of the erroneous bits in the received pattern, but can quickly determine whether a functional block of the device under test has not generated any errors or whether a functional block of the device under test has generated one or more errors. In some cases, the summary failure information can also be used to separate functional blocks that generate very few errors in the received pattern from functional blocks that generate a large number of errors in the received pattern (for example, if there are error counters). Therefore, the summary failure information can be obtained very quickly and is very suitable for making test flow decisions due to its rapid availability. In addition, the summary failure information includes the most relevant information, namely which functional blocks of the device under test have generated errors in the received pattern, in a very concise form.

[0072] On the other hand, the recorded individual failure information allows the user of the test equipment to perform a more detailed analysis. Since the recorded individual failure information can usually indicate which bit within the received pattern is erroneous, the source of the error can be identified in great detail (e.g., down to a single gate level or even down to a single transistor). However, it should be noted that the amount of individual failure information that can be recorded is usually limited under given resource constraints. Therefore, there may be a situation where the limited amount of individual failure information recorded only describes errors originating from a single functional block of the device under test, while the summary failure information can also identify errors from other functional blocks of the device under test.

[0073] Furthermore, it should be noted that since individual failure information usually includes a large amount of information, such as detailed error location information, etc., summary failure information is usually obtained faster and / or certain conclusions can be drawn faster than individual failure information.

[0074] In summary, we have recognized that it is valuable to determine both individual failure information and summary failure information, as summary failure information is particularly suitable for obtaining an overview of the integrity of the device under test and / or classifying the device under test and / or making test flow decisions, while individual failure information allows for a more detailed analysis of the fault.

[0075] In a preferred embodiment, the device is configured to record failure cycles (e.g., bits of a received pattern where comparison with a reference pattern indicates a deviation) in a temporally identifiable (e.g., time-recorded, traceable) manner (e.g., together with bit position information or timestamp information) (e.g., with limited recording capabilities) in addition to a per-functional block error flag and / or a per-functional block error count.

[0076] In addition to the per-function block error flags and / or per-function block error counts, the test fixture can also record the failed cycles in a time-identifiable manner, thereby providing compact overview information that is well suited for classification of the device under test and / or test flow decisions, while also providing more detailed information that is well suited for detailed error analysis. By recording the failed cycles, for example with timestamps or bit position values, some particularly useful information can be obtained if the number of errors is relatively small. For example, such failed cycles recorded in a time-identifiable manner can be stored in the test fixture, for example, and can be analyzed, for example, in a post-processing step after the test program is executed. Alternatively or in addition, the failed cycles recorded in a time-identifiable manner can, for example, be uploaded from the test fixture to a workstation, where they can be further analyzed using software tools. For example, the per-function block error flags and / or per-function block error counts can be evaluated when executing the test program, and can also be used directly for classification of the device under test or for controlling the execution of the test flow. For example, the per-function block error flags and / or per-function block error counts can be used to determine which test should be executed next in the test flow.

[0077] Therefore, the concept of recording both detailed information of the failure cycle and compact “summary” information enables fast, efficient and comprehensive testing and allows a detailed understanding of the integrity of the device under test.

[0078] In a preferred embodiment, the test apparatus is configured to continue updating summary failure information (e.g., per-block error flags and / or per-block error counts) even if memory for recording individual failure information is exhausted (e.g., due to a large number of comparison failures).

[0079] Thus, even if there is a large amount of individual failure information, such as failure information that may be caused by a severely defective functional block, the summary failure information provides reliable information about the functional status of different functional blocks of the device under test. Thus, even in the case of a large number of bit errors in the received pattern, the summary failure information enables classification of the device under test and / or very fast test flow decisions. Thus, for example, even if a single defective block of the device under test generates a large number of errors in the received pattern and blocks the recording of individual failure information, it is possible to identify a non-defective functional block of the device under test. As a result, the test efficiency can be significantly improved.

[0080] In a preferred embodiment, the test apparatus is configured to selectively mask (e.g., omit) (e.g., on a per-functional-block basis, or per-functional-block granularity) the recording of individual failure information (e.g., error mapping records) for bits of a received pattern associated with one or more functional blocks of the device under test. Alternatively or in addition, the test apparatus is configured to selectively enable (e.g., on a per-functional-block basis, or per-functional-block granularity) the recording of individual failure information (e.g., error mapping records) for bits of a received pattern associated with one or more functional blocks of the device under test.

[0081] By selectively shielding or selectively enabling the recording of individual failure information of bits of the received pattern associated with one or more functional blocks of the device under test, resources used to record individual failure information can be concentrated on the failure of one or more specific functional blocks of particular concern. Alternatively, by selectively shielding or selectively enabling the recording of individual failure information, the recording of individual failure information of one or more severely failed functional blocks of the device under test can be avoided, thereby avoiding interference with resources used to record individual failure information. Therefore, the recording of individual failure information can be concentrated on failures caused by one or more selected functional blocks of the device under test. Therefore, individual failure information of specific significance can be obtained in a resource-saving manner.

[0082] In a preferred embodiment, the test apparatus is configured to use a table defining block lengths of one or more bits of the received pattern associated with different functional blocks of the device under test to determine which bits of the received pattern should be omitted (masked) from individual failure information records.

[0083] Thus, a table may be used to define a selection of bits of a received pattern for which individual failure information should or should not be recorded. Thus, portions of the individual failure information may be selectively masked, which may help to avoid interference with the recording of individual faults, for example. In particular, we have recognised that the use of a table defining the length of a block of one or more bits of a received pattern associated with different functional blocks of a device under test is an effective mechanism for distinguishing between bits of a received pattern for which individual failure information should be recorded and bits of a received pattern for which individual failure information should not be recorded.

[0084] In a preferred embodiment, the test apparatus comprises dedicated hardware configured to identify (e.g. at runtime; e.g. during reception of a receive pattern from the device under test) bits in a received pattern from which individual failure information records should be omitted (e.g. masked) (e.g. using a table defining the lengths of blocks of one or more bits of the received pattern associated with different functional blocks of the device under test, and optionally the lengths of the start blocks, and optionally periodically).

[0085] By using dedicated hardware to identify the bits in the received pattern for which recording of the individual pattern information should be omitted, a particularly efficient implementation can be achieved. In particular, by using dedicated hardware, on-the-fly processing can be performed, thereby eliminating the need for extensive buffering mechanisms. For example, when using dedicated hardware, the generation of individual failure information can be enabled or disabled at an early stage in the processing chain, for example by suppressing the comparison or disabling (or interrupting) an error signal for the comparison between the received pattern and the reference pattern. As a result, the computational complexity can be kept low and the memory requirements can be relaxed.

[0086] In a preferred embodiment, the test apparatus is configured to (e.g. automatically) activate (e.g. selectively) mask (e.g. selectively) the recording of individual failure information for bits of a received pattern associated with a functional block of the device under test (e.g. at runtime; e.g. during reception of a receive pattern from the device under test) in response to detecting that an individual error counter selectively counting comparison errors of bits related to a particular functional block has reached a predetermined maximum value (e.g., automatically stopping the recording of individual failure information associated with the functional block when a predetermined maximum number of failures generated by the particular functional block is reached).

[0087] Using this mechanism, if it is identified that a certain functional block generates an excessive number of errors, the recording of individual failure information associated with the functional block can be stopped. Thus, by counting the number of errors generated by a certain functional block of the device under test, the amount of individual failure information associated with a certain functional block of the device under test can be limited. This helps to avoid interference with the recording of individual failure information when one or more functional blocks of the device under test have serious failures. On the contrary, the individual failure recording capability is maintained for errors generated by other functional blocks of the device under test. Thus, even in the presence of seriously failed functional blocks (even taking into account the limitation of the ability to record individual failure information), the concept maintains the possibility of recording individual failure information for multiple functional blocks of the device under test, thereby obtaining particularly meaningful test results. Thus, the concept allows to obtain meaningful test results that can be analyzed by the user of the test device, wherein the amount of individual failure information for each functional block can be limited. However, the limitation of the amount of individual failure information for each functional block is usually not a problem, because for seriously failed functional blocks, it is usually not necessary to have complete individual failure information.

[0088] Therefore, the concept can perform tests very efficiently and provide meaningful test results.

[0089] In a preferred embodiment, the test apparatus is configured to identify different blocks of one or more bits of a received pattern (e.g. associated with different functional blocks of the device under test) using a table defining the lengths of blocks of one or more bits of a received pattern (and an optional length of a start block and an optional period) associated with different functional blocks of the device under test.

[0090] We have realized that identifying different blocks of one or more bits of a received pattern using a table defining the lengths of blocks of one or more bits of a received pattern associated with different functional blocks of a device under test is a very effective concept as it is very consistent with the typical structure of a received pattern comprising a sequence of bits associated with different functional blocks of a device under test, wherein said blocks of one or more bits comprise a predetermined length that can be easily represented in a table. Furthermore, the mechanism also takes into account the periodicity of the blocks of bits associated with different functional blocks of the device under test. Thus, an effective implementation of the concept can achieve reliable identification of different blocks of one or more bits of a received pattern associated with different functional blocks of a device under test, thereby separating errors from these different functional blocks of the device under test.

[0091] In a preferred embodiment, the test apparatus is configured to use a table to identify periodic sequences of one or more bit blocks of the received pattern associated with different functional blocks of the device under test (eg, to periodically associate bit blocks with different functional blocks).

[0092] By taking advantage of the periodicity of the received pattern, the complexity of the mechanism for separating errors from different functional blocks of the device under test can be greatly reduced. For example, a table of a table-based mechanism can include entries that define a periodicity. However, for example, a table of a table-based mechanism can also include a mechanism for identifying an initial portion of the received pattern that is ignored. For example, a table can be used to define the length of one or more bits associated with different functional blocks of the device under test. If appropriate, the table can define a pair of values, including length information and an index of the functional block. In addition, for example, the table can include a traceback to the next table entry, thereby indicating periodicity.

[0093] In summary, a table-based mechanism may for example comprise a list of lengths of one or more blocks of bits, and a list of indices of functional blocks associated with the one or more blocks of bits, and periodicity information defining a sequence of blocks of bits or a repetition of subsequent blocks of bits, etc. Thus, errors associated with different functional blocks of the device under test may be separated in an efficient manner, since evaluation of the table allows a reliable association of bits of a received pattern with functional blocks.

[0094] In a preferred embodiment, the test device is configured to adjust the test flow based on error information within a received pattern associated with a given functional block of the device under test (for example, based on the value of an error flag register associated with the given functional block of the device under test and / or based on the value of an error counter associated with the given functional block of the device under test).

[0095] Accordingly, the test flow can be adjusted based on the result information describing the test results of the individual functional blocks of the device under test, wherein, since the separation of errors associated with different functional blocks of the device under test occurs during the execution of the test program, these test information can be obtained very quickly (even during the execution of the test program). Therefore, the rapid availability of test results associated with different functional blocks of the device under test is achieved by using the concepts disclosed herein to improve the quality of the test. For example, if a functional block of the device under test is found to have generated one or more errors in the received mode, a retest of the specific functional block can be triggered. On the other hand, if the test result information obtained during the execution of the test program (by separating the errors of different functional blocks of the device under test) indicates that a functional block has failed seriously, the test can be adjusted to omit the test of the seriously failed functional block so as to efficiently obtain meaningful test results for other functional blocks. Therefore, the test result information associated with different functional blocks of the device under test obtained by separating the errors during the execution of the test program can be used to influence the test flow execution decision. Therefore, by executing the test program or test function adapted to the previously obtained test result information, a higher test efficiency can be achieved.

[0096] In a preferred embodiment, the test apparatus is configured to adjust the test flow in response to determining (e.g. finding or detecting) that the number of errors (e.g. the number of comparison errors) in a received pattern associated with a given functional block of the device under test has reached or exceeded a predetermined maximum number.

[0097] Using this concept, the test flow can be adjusted in such a way that a functional block that fails badly does not reduce the reliability or efficiency of further testing of the device under test. For example, further testing can be limited to other functional blocks of the device under test, which have therefore been found to produce no errors or only a small number of errors. For example, it can be avoided to spend test time on testing a functional block that has been identified as producing a large number of errors, because it cannot be expected that the functional block is defect-free. Therefore, test resources (such as test time and / or separate failure recording capacity) can be concentrated on testing functional blocks of the device under test that do not produce an excessive number of errors in the received mode. Therefore, a good test efficiency can be achieved.

[0098] In a preferred embodiment, the test device is configured to activate masking of individual failure information records, or deactivate individual failure information records, for bits of a received pattern associated with a given functional block of the device under test, and repeat testing (e.g., a complete test flow or a portion of a test flow) (e.g., using the same multi-core test pattern and the same expected pattern) in response to determining (e.g., discovering or detecting) that the number of errors (e.g., the number of comparison errors) in a received pattern associated with a given functional block of the device under test has reached or exceeded a predetermined maximum number (e.g., a limit).

[0099] Using such a concept, it is possible to ensure that sufficient individual failure information is recorded for multiple different functional blocks of the device under test, even in the case where there is a severely failed functional block of the device under test. In particular, if it is found that a certain functional block of the device under test generates too many errors, the individual recording of these errors can be automatically disabled, so that when the test program is re-executed, there is sufficient recording capacity to individually record errors from other functional blocks of the device under test (except for the severely failed functional block of the device under test).

[0100] Therefore, meaningful test results can be obtained without being disturbed by errors caused by critically failing functional blocks of the device under test.

[0101] An embodiment creates a test apparatus (e.g., a test processor, or a channel module of an automatic test apparatus, or an automatic test apparatus) for testing a device under test. The test apparatus is configured to receive a pattern (e.g., a result pattern; e.g., a response pattern) from the device under test, the pattern comprising a sequence of bits representing (e.g., represented in a combined form; e.g., in an interleaved form) information (e.g., test results; e.g., test response information) from multiple functional blocks (e.g., "cores"; e.g., result blocks; e.g., functional blocks that provide substantially independent test results or test responses) of the device under test (e.g., associated with the device under test). The test apparatus is configured to separate (e.g., separately process or separately record) errors within the received pattern associated with different blocks of one or more bits (e.g., separate errors of different cores) during the execution of a test program (e.g., in order to obtain test results for each functional block of the device under test (e.g., each core of the device under test) during the execution of the test program).

[0102] The present embodiment is based on similar considerations as the above-described embodiment, wherein it should be noted that the test apparatus is configured to separate errors in the received pattern associated with different blocks of one or more bits during the execution of the test procedure. Therefore, there does not have to be a fixed association between the bits in the received pattern and the functional blocks of the device under test. On the contrary, the concept is also generally applicable, for example, in cases where different blocks of one or more bits in the received pattern include different meanings, indicate different types of errors, etc. However, it should be noted that the concept can be selectively supplemented by any features, functions and details disclosed herein.

[0103] An embodiment creates a method for testing a device under test. The method includes receiving a pattern (e.g., a result pattern; e.g., a response pattern) from the device under test, the pattern including (e.g., in a combined form; e.g., in an interleaved form) information (e.g., test results; e.g., test response information; e.g., a bit sequence) from (e.g., associated with) multiple functional blocks (e.g., "cores"; e.g., result blocks; e.g., functional blocks that provide substantially independent test results or test responses) of the device under test. The method further includes separating (e.g., processing or recording separately) errors within the received pattern associated with different functional blocks of the device under test (e.g., separating errors of different cores) during execution of a test program (e.g., in order to obtain test results for each functional block of the device under test during execution of the test program, e.g., in order to obtain test results for each core of the device under test).

[0104] The method is based on the same considerations as the test device discussed herein. In addition, it should be noted that the method can be selectively supplemented by any features, functions and details disclosed herein, both individually and in combination.

[0105] According to an embodiment of the invention a computer program is created for performing the method according to claim 37 when the computer program is run on a computer. BRIEF DESCRIPTION OF THE DRAWINGS

[0106] Embodiments according to the present invention will now be described with reference to the accompanying drawings, in which:

[0107] Figure 1 A block diagram of a testing device according to an embodiment of the present invention is shown;

[0108] Figure 2 A block diagram of a testing device according to an embodiment of the present invention is shown;

[0109] FIG3 shows a block diagram of a testing device according to an embodiment of the present invention;

[0110] Figure 4 A schematic representation of a bit stream is shown;

[0111] Figure 5 A block diagram showing a mapping mechanism that can be used for a test device according to another embodiment of the present invention is shown;

[0112] Figure 6 A schematic representation showing table-based separation of error information; and

[0113] Figure 7 A flow chart of a method according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0114] 1. According to Figure 1 Test device

[0115] Figure 1 FIG. 1 is a block diagram of a testing device 100 according to an embodiment of the invention.

[0116] The test apparatus 100 is configured to receive an input signal 110 from a device under test 102, wherein the device under test 102 is not typically part of the test apparatus 100. For example, the input signal 110 may define an input mode. In addition, the test apparatus 100 is configured to provide test result information 112 based on the input signal 110.

[0117] It should be noted that the test apparatus 100 may be part of a test system. However, the test apparatus 100 may also be implemented, for example, in a test processor or a channel module of an automatic test equipment, or in general in an automatic test equipment.

[0118] The test apparatus 100 is configured to receive a pattern (e.g., a result pattern, e.g., a response pattern) from a device under test. The received pattern typically includes (e.g., in a combined form; e.g., in a cross-linked form) information (e.g., test results; e.g., response information; e.g., a bit sequence) from (e.g., associated with) multiple functional blocks (e.g., "cores"; e.g., result blocks; e.g., functional blocks that provide substantially independent test results or test responses) of the device under test. The test apparatus includes an error separation or error separator configured to separate (e.g., separately process and / or separately forward, and / or separately record) errors within the received pattern associated with different functional blocks of the device under test during execution of a test program, e.g., separate errors of different functional blocks or "cores" of the device under test.

[0119] Therefore, during the execution of the test program, the test apparatus 100 may obtain (e.g., independent or different) test results for each functional block of the device under test (e.g., each core of the device under test). Therefore, the test result information 112 may, for example, describe independent test results associated with different functional blocks or cores of the device under test.

[0120] Thus, during the execution of the test program, by separating errors within the received pattern associated with different functional blocks, or separating errors within the received pattern associated with different blocks of one or more bits, meaningful test result information can be obtained with moderate implementation effort and very low latency. Thus, during the execution of the test program, the test result information 112 can include meaningful information describing the integrity of different functional blocks or cores of the device under test, respectively, e.g., without the need for extensive buffering of the complete received pattern. Thus, the concept of our invention provides a good compromise between complexity, test coverage, latency, and accuracy. Thus, the test apparatus 100 facilitates efficient testing of devices under test that provide test results of different functional blocks or cores in a multiplexed form (e.g., through a single common pin).

[0121] Furthermore, it should be noted that the testing device 100 may be optionally supplemented with any of the features, functions and details disclosed herein.

[0122] 2. According to Figure 2 Test device

[0123] Figure 2 1 shows a block diagram of a test apparatus 200 according to an embodiment of the present invention. The test apparatus 200 receives an input signal 210 from a device under test 202. For example, the input signal 210 may be a signal from a pin of the device under test. For example, the input signal may be a response of the device under test to a stimulus signal, and the input signal 210 may define an input mode.

[0124] In addition, the test device 200 provides test result information 212, which may include, for example, summary failure information 212a and / or individual failure information 212b. For example, the summary failure information 212a may describe the errors associated with different functional blocks of the device under test 202 in a summarized form. For example, the summary failure information 212a may indicate, for example, for a plurality of functional blocks or a plurality of functional block groups, which functional blocks or functional block groups caused at least one error in the received mode (e.g., in the mode determined by the input signal 210). For example, the summary failure information 212a may include a binary value for each functional block or each functional block group, the corresponding binary value indicating whether the corresponding functional block or functional block group of the device under test caused at least one error in the received mode. Alternatively or in addition, the summary failure information 212a may include an independent count value for counting the number of errors generated by different functional blocks or functional block groups of the device under test. Thus, for example, different count values ​​may describe errors that occurred in different blocks of one or more bits in the received pattern (wherein the different blocks of one or more bits may be associated with different functional blocks or groups of functional blocks of the device under test). For example, the counter values ​​may respectively indicate how many errors in the received pattern were caused by different functional blocks or groups of functional blocks of the device under test.

[0125] Therefore, the summary failure information 212a can provide meaningful information, for example, whether different functional blocks have caused errors in the received mode, and / or how many errors different functional blocks (or functional block groups) of the device under test have caused in the received mode. Therefore, the summary failure information can be used to determine whether different blocks (or functional block groups) operate as expected (for example, if they do not cause any errors in the received mode), or whether different functional blocks (or functional block groups) do not operate in an expected manner (for example, cause at least one error in the received mode).

[0126] In addition, in the case where counter information is provided as part of the summary failure information 212a, it is also possible to quickly determine whether one or more functional blocks (or groups of functional blocks) of the device under test have failed seriously, resulting in a relatively large number of errors in the received pattern. For example, if the number of errors in the received pattern caused by a certain functional block (or group of functional blocks) of the device under test is found to reach or exceed a predetermined number, the test device may conclude that the functional block (or group of functional blocks) has failed seriously. For example, such identified functional blocks (or groups of functional blocks) may be excluded from further testing because it can be considered that functional blocks (or groups of functional blocks) that have failed seriously do not require further testing and will complicate or hinder the testing of other functional blocks because these functional blocks will not cause errors in the received pattern or will only cause a small number of errors in the received pattern.

[0127] However, it should be noted that the summary failure information 212a, which is usually provided during the execution of the test program, is very helpful for the testing of the device under test because it is usually low-latency and in some cases sufficient to classify the device under test (e.g., functioning properly or defective). In particular, the summary failure information can provide an overview of the integrity of different functional blocks (or groups of functional blocks) of the device under test, which may be useful for making test flow decisions and / or for more refined classification of the device under test.

[0128] The individual failure information 212b may be part of the test result information 212, for example, the individual failures in the received pattern may be described in a temporally distinguishable manner. For example, the individual failure information 212b may describe the individual failures in the received pattern using time information describing the time when the individual errors occurred (e.g., describing the position of the bits of the individual failures in the received pattern, such as using a timestamp or an index of the position of the bits, etc.). Typically, the individual failure information describes the individual failures in the received pattern, rather than a complete copy of the received pattern, thereby saving memory capacity. For example, the individual failure information may be helpful for detailed analysis of the fault, such as determining which hardware component of the device under test failed.

[0129] The test apparatus 200 includes a comparator 220 that compares a received pattern (which may be represented by the input signal 210) with an expected pattern (e.g., which may be considered a reference pattern and may be provided, for example, by a reference signal generator or reference pattern generator). For example, the comparator 220 may provide an error signal 222 in response to detecting an error within the received pattern (wherein a deviation between a bit of the received pattern and a bit of the reference pattern may be considered an error). For example, the comparator may provide an error signal 222 for each error between a bit of the reference pattern and a bit of the received pattern, but in some cases, the comparison may be selectively enabled and / or selectively disabled and / or error signaling 222 may be provided and / or forwarded for different blocks of one or more bit positions in the received pattern (e.g., thereby separating errors associated with different functional blocks (or groups of functional blocks) of the device under test).

[0130] The test device 200 also includes an overview failure information determination / summary failure information determiner 230, which receives the error signaling 222 from the comparator 220 and provides the overview information 212. The overview failure information determination 230 can be configured to perform bit position-related / functional block-related error registration and / or bit position-related / functional block-related error counting. For example, the error registration can perform a comparison failure registration, wherein the comparison failures in different blocks of one or more bits of the received pattern can be registered in different error registers. Similarly, the error counting can perform a comparison failure counting, wherein the comparison failures occurring in different blocks of one or more bits of the received pattern can be counted by different counters. For example, the overview failure information determination can receive a control signal from the control 240, wherein the control signal 242 can, for example, indicate to the overview failure information determination which error register should be activated by the error signal, or which error counter of a plurality of error counters should be incremented in response to the fault signal 222. For example, the control 240 may provide one or more control signals 242 based on a priori knowledge of which bit position in the received pattern is associated with which functional block (or functional block group) of the device under test, taking into account the timing of the input signal 210. Thus, the determination of the summary failure information may separately register and / or count comparison failures caused by different functional blocks (or functional block groups) of the device under test. Thus, meaningful summary failure information may be generated.

[0131] In addition, the test device 200 includes a separate failure information recorder / separate failure information recorder 250, which can receive the error signal 222 from the comparator 220 and can also receive one or more control signals 244 from the control 240. The separate failure information recorder / separate failure information recorder provides separate failure information 212b. For example, the separate failure information recorder / separate failure information recorder 250 can perform error recording related to the position of the bit / related to the functional block, thereby obtaining the separate failure information 212b. For example, the separate failure information 212b can include time information describing the time position of the comparison failure. However, the separate failure information recorder / recorder 250 can be controlled in such a way that the comparison failures (comparison errors) associated with different functional blocks of the device under test are recorded separately, and / or the recording of separate failure information can be activated and / or deactivated for the faults associated with different functional blocks of the device under test. For example, the activation and / or deactivation of the separate failure information recording can be controlled by the control signal 244 provided by the control 240. Thus, individual failure information associated with different functional blocks of the device under test can be selectively recorded, wherein, for example, the recording of individual failure information can be disabled for failures caused by one or more specific functional blocks of the device under test. Thus, the recording of individual failure information can be focused on individual failure information associated with one or more functional blocks of the device under test that are currently of interest. Alternatively, or in combination, the recording of individual failure information for failures caused by one or more specific functional blocks of the device under test can be selectively suppressed, for example, the recording of individual failure information for one or more severely failed (and therefore generating excessive failures) specific functional blocks of the device under test can be disabled.

[0132] For example, if the summary failure information determination 230 determines that the number of errors generated by a certain functional block of the device under test in the received pattern reaches or exceeds a predetermined threshold, the test device (e.g., through control 240) can automatically disable the recording of individual failure information for a certain functional block of the device under test. Thus, for example, it can be ensured that only a predetermined maximum amount of individual failure information is recorded for a given functional block of the device under test (or all functional blocks of the device under test). For example, further recording of individual failure information for severely failed functional blocks of the device under test can be controlled by the control signal 244 provided by the summary failure information determination.

[0133] Thus, the test apparatus 200 can separate errors in a received pattern associated with different functional blocks of a device under test during the execution of a test program. Overview Failure information 212a can indicate failure information for different functional blocks of the device under test, respectively, the failure information indicating whether different functional blocks of the device under test caused a failure in the received pattern and / or how many failures different functional blocks of the device under test caused. In addition, the apparatus also allows for providing separate failure information, wherein, since the errors in the received pattern associated with different functional blocks are separated, it can be determined (set) for which errors to record separate failure information 212b. For example, for errors caused by some functional blocks of the device under test, the recording of separate failure information can be selectively enabled and / or disabled. Therefore, the amount of separate failure information can be kept quite small, thereby reducing memory requirements and / or preventing interference with available memory (e.g., by disabling the recording of errors generated by severely failed functional blocks of the device under test).

[0134] Therefore, the test apparatus can provide a very efficient test of the device under test, wherein the overview of failure information can be obtained with almost no delay, can help to classify the device under test, and can also help to make decisions on the test process. In addition, selectively recording individual failure information also helps to save test resources, and can effectively obtain meaningful test results even in the case of serious failure of one or more functional blocks of the device under test.

[0135] Furthermore, it should be noted that the testing device 200 may selectively be supplemented with any of the features, functions, and details disclosed herein, either alone or in combination.

[0136] 3. According to the test device shown in Figure 3

[0137] FIG. 3 shows a block diagram of a testing device 300 according to another embodiment of the present invention.

[0138] The test apparatus 300 according to FIG. 3 is configured to receive an input signal 310 and provide result information 312 based thereon, for example, the result information 312 may include summary failure information 312a and individual failure information 312b. It may be assumed here that the device under test 302 provides the input signal 310 to the test apparatus 300. For example, the input signal 310 may be a signal output by the device under test 302 at a pin of the device under test 302. For example, the input signal 310 may be a digital signal, wherein test result data from a first functional block of the device under test is included in the input signal 310 in the form of a first block of one or more bit positions, and wherein test result data from a second functional block of the device under test 302 is included in the input signal 310 in the form of a second block of one or more bit positions. In other words, the test result data from different functional blocks of the device under test 310 may be multiplexed (e.g., time multiplexed) in the input signal 310, for example, using a predetermined multiplexing rule. Thus, for example, input signal 310 may be a signal from a pin of the device under test and may represent a response of the device under test to a stimulus signal, which may also be provided by the test apparatus.For example, input signal 310 may define an input mode, also referred to herein as a receive mode.

[0139] The input signal 310 may optionally undergo some preprocessing in the test apparatus, which is not shown in Fig. 3. For example, the preprocessing may include converting the actual analog input signal 310 into a digital signal, time discretization (eg, sampling), and the like.

[0140] Thus, for example, a time-discrete digital version of the input signal may be provided to the comparator 320. The comparator 320 also receives a reference signal or reference pattern from a reference signal generator / reference pattern generator 326. Thus, the comparator may compare the input signal 310 (or a digitized and time-digitized version thereof) with a reference signal 328 provided by the reference signal generator 326, or the comparator 320 may compare a received pattern (defined by the input signal 310) with a reference pattern provided by the reference pattern generator 326. For example, the comparator 320 may perform a bit-wise comparison of the input signal (or a digitized and time-discrete version thereof) with a corresponding reference signal, or the comparator may perform a block-wise comparison of the received pattern with the reference pattern.

[0141] It should be noted that in the present concept, both the bit-wise comparison between the input signal 310 (or the digitized and time-digitized version) and the reference signal and the block-wise comparison between the received pattern and the corresponding reference pattern can be used to identify errors within the received pattern (where it is assumed that the difference between the bits of the input signal and the bits of the reference signal indicates an error within the received pattern, and the difference between one or more bits in the received pattern and one of the bits in the reference pattern also indicates an error within the received pattern). In other words, it should be noted that the input signal received by the test device can be considered as a representation of the received pattern.

[0142] In other words, detecting whether bits of the input signal received by the test device deviate from corresponding bits of the reference signal is one possibility for detecting errors in the received pattern. However, block-wise comparison between blocks of bits of the input signal 310 and blocks of bits of the reference pattern provided by the reference signal generator 326 is another concept for identifying errors in the received pattern. In general, it should be noted that the time evolution of the input signal 310 defines the received pattern, so that the detection of errors in the received pattern corresponds to the detection of deviations of the input signal from the corresponding reference signal.

[0143] Furthermore, it should be noted that the received pattern received by the testing apparatus may be a bit pattern in which test result data from different functional blocks of the device under test are time multiplexed (preferably according to a predetermined time multiplexing rule).

[0144] The comparator provides an error signal 322, which may, for example, indicate a deviation between bits of the received signal and bits of a reference signal, or equivalently indicate an error within the received pattern.

[0145] For example, the error signal may be evaluated to determine summary failure information. For example, the test apparatus 300 may include one or more error separators / error signal forwarders 332a, 332b (where, for example, the use of multiple error separators / error signal forwarders may be advantageous in the case where multiple error signals are generated simultaneously or sequentially in time), and the test apparatus 300 may also include multiple result units 336a, 336b, 336n. For example, the error signal separator 332a may receive the error signal 322 and forward the error signal 322 to one of the result units 336a, 336b, 336n based on control information (e.g., based on the error separator control signal 342). For example, the error separator 332a may be considered as an error signal forwarder and may be implemented using a multiplexer. Therefore, the error separator 332a may determine to which result unit 336a, 336b, 336c the error signal is forwarded.

[0146] The decision to which result unit 336, 336b, 336n to forward the error signal can be based on determining which functional block of the device under test the error bit within the received pattern that caused the error signal 322 to be activated is associated with. For example, if the error bit within the received pattern that caused the error signal 322 to be activated is associated with (or caused by) a first functional block of the device under test, the error signal 322 can be forwarded to the first result unit 336a. Conversely, if the error bit within the received pattern that caused the error signal 322 to be activated is associated with (or caused by) a second functional block of the device under test, the error signal 322 can be forwarded to the second result unit 336b. In addition, in general, if the activation of the error signal 322 is caused by an error bit within the received pattern, and the error bit is associated with (or caused by) an nth functional block of the device under test, the error signal 322 can be forwarded to the nth result unit 336n through the error separator 332a.

[0147] For example, the corresponding result unit 336a, 336b, 336n may be configured to register the activation of the error signal forwarded to the corresponding result unit. For example, the first result unit 336a may include an error flag register 337a and / or an error counter 338a. Accordingly, if the error signal 322 is forwarded to the first result unit 336a, the error flag register 337a of the first result unit 336a may be set, thereby indicating that the error in the received pattern is caused by the first functional block of the device under test (wherein the first result unit 336a is actually associated with the first functional block of the device under test). Alternatively or in addition, if the error signal (i.e., the activated error signal 322) is forwarded to the first result unit 336a, the error counter 338a of the first result unit 336a will be incremented. Accordingly, the error counter 338a of the result unit 336a can count the number of errors in the received pattern associated with the first functional block of the device under test. Thus, the result unit 336a may, for example, register whether there are errors in the received pattern caused by the first functional block and / or how many errors in the received pattern are caused by the first functional block of the device under test. Similarly, when the (activated) error signal is forwarded to the second result unit 336b via the error separator 332a, the error flag register 337b of the second result unit 336b will be activated. In other words, the error flag register 337b will be set in response to errors associated with (or caused by) the second functional block of the device under test in the received pattern. Alternatively or in addition, if an error associated with (or caused by) the second functional block of the device under test occurs in the received pattern, the error counter 338b of the second result unit 336b will be incremented.

[0148] Thus, the corresponding result unit registers and / or counts errors in the received pattern associated with the corresponding functional block of the device under test. However, alternatively, the corresponding result unit may also register and / or count errors in the received pattern caused by a group of functional blocks in the device under test. In other words, there is not necessarily a one-to-one association between the functional blocks of the device under test and the result unit. Instead, in some cases, multiple functional blocks of the device under test may be associated with a single result unit (e.g., if the number of result units is less than the number of functional blocks in the device under test).

[0149] In summary, by selectively forwarding the error signal to one of the result units (e.g., controlled by the error separator 332a or the control unit 340 providing the error separator control signal 342), the errors in the received pattern associated with different functional blocks of the device under test can be registered and counted in different result units. Therefore, the error flag register of the corresponding result unit indicates whether the functional block of the device under test associated with the corresponding result unit causes the error in the received pattern. Similarly, the error counter of the corresponding result unit indicates how many errors the functional block of the device under test associated with the corresponding result unit has caused in the received pattern. Therefore, different result units provide integrity information of different functional blocks of the device under test. For example, the corresponding error flag register of the result unit indicates whether the corresponding functional block of the device under test has caused one or more errors in the received pattern, and the error counter of the corresponding result unit indicates how many errors the corresponding functional block of the device under test has caused in the received pattern.

[0150] Therefore, information of the error flag register and / or the error counter in the result unit may be used as the summary failure information 312a.

[0151] It should be noted that the result unit may have the function of resetting the error flag register and / or the error counter, and / or the function of freezing the state of the error flag register and / or the error counter, and the function of reading the state of the error flag register and / or the count value of the error counter. For example, the read value (e.g., the binary value of the error flag register and / or the numerical value of the error counter) may constitute the summary failure information. Therefore, the summary failure information 312a provides a quick summary of which functional blocks of the device under test cause one or more errors in the received mode. In addition, the summary failure information 312a can also quickly summarize which functional blocks of the device under test are seriously faulty, i.e., generate a large number of errors in the received mode.

[0152] The test device 300 also includes (optionally) an error recorder 350, which can provide individual failure information 312b. For example, the error recorder 350 can record (e.g., store in a memory) individual failure information that describes the error in detail, which information typically includes time information that accurately defines when the error occurred. For example, the individual failure information can describe in detail multiple errors in the received pattern, including the exact time (or position of the bit) when the error occurred. Since it is usually assumed that the received pattern only includes relatively few error information, it is usually much more efficient to store the individual error information than to store the complete received pattern for later evaluation. However, the individual error information usually allows the user of the test device to analyze the errors in the device under test in detail. Therefore, the individual failure information can usually determine more accurately what type of error has occurred in the device under test, while the summary failure information 312a can usually only identify that an error has occurred in a functional block of the device under test, and the degree of failure of the functional block of the device under test.

[0153] However, the test apparatus 300 may be configured to selectively enable and / or disable the recording of individual failure information for errors originating from some functional blocks of the device under test. For example, the control 340 may provide one or more error recording control signals 343 to selectively enable and / or disable the recording of individual failure information for errors within the received pattern associated with some functional blocks of the device under test. For example, when the control 340 finds that the bit position of the currently analyzed received pattern is associated with a functional block of the device under test for which individual failure information should be recorded, the control 340 may enable the recording of individual failure information and / or enable the forwarding of the failure signal 322 to the error recorder 350. On the other hand, if the control 340 finds that the bit position of the currently analyzed (or processed) pattern is associated with a functional block of the device under test for which individual failure information should not be recorded, the control 340 may provide one or more control signals to disable the error recorder 350 from performing error recording, or to disable the forwarding of the error signal 320 to the error recorder 350 (thereby preventing the recording of individual failure information).

[0154] Thus, the control 340 can track which functional block of the device under test the position of the bit currently processed by the comparator 320 is associated with, and can control the error separator 332a accordingly to forward possible error signals to the appropriate result unit, and can also enable or disable the recording of individual failure information. Thus, the recording of individual failure information for one or more functional blocks of the device under test can be avoided. This is particularly advantageous if one or more functional blocks of the device under test have previously been found to be seriously faulty, i.e., a large number of errors have occurred in the received pattern. In this case, by prohibiting the recording of individual failure information from seriously failed functional blocks of the device under test in the received pattern, interference with the error recorder or the individual failure memory of the error recorder can be prevented.

[0155] Furthermore, it should be noted that in the test apparatus 300, for example, the recording of individual failure information can be automatically disabled for a functional block of the device under test for which an excessive number of failures is identified by a result unit. For example, if an error counter of a result unit associated with a functional block of the device under test reaches or exceeds a predetermined threshold, the recording of individual failure information for a bit position associated with a severely failed functional block of the device under test can be automatically disabled. For this purpose, a simple control logic can be used, which can recognize that the error counter of a certain result unit has reached or exceeded a predetermined threshold and deactivate the recording of individual failure information for the associated block of one or more bits of the received pattern.

[0156] It is worth noting that the control 340 can be used to provide control signals to the error separator 332a, and can also be used to enable and disable the recording of individual failure information by the error recorder 350. For example, the control 340 can be synchronized in time with the excitation generator that provides the excitation signal to the device under test, the reference signal generator 326, and the comparator 320. Therefore, for example, the control 340 can operate in a time-synchronized manner with the bit clock of the input signal 310. Therefore, the control unit 340 can count the received bits of the input signal 310, so as to be able to operate synchronously with the bits of the received signal 310. For example, the control unit can count the received bits of the input signal 310, so as to derive which functional blocks of the device under test are associated with each bit. For example, the control 340 can include a definition of a group of positions of bits in the input signal 310 based on a table. For example, the definition based on the table can describe the length of different groups (or blocks) of bits in the input signal 310. For example, the definition of the group of positions of bits based on the table can indicate that some "unreliable" bits should be discarded at the beginning of the input signal. Then, the table-based definition of the groups of bit positions used by control 340 can specify that the next group of bits is associated with the first functional block of the device under test, while the subsequent group of bits is associated with the second functional block of the device under test. In the table-based bit group definition, the lengths of different groups of one or more bits can also be defined.

[0157] In addition, the definition of the group of bit positions based on the table may also include information about the repetition of the bit group (e.g., a repetition count). For example, the definition of the group of bit positions based on the table may include jump position information or period information, such as information that may define the repetition of a sequence of the group of bit positions. For example, the jump position information may indicate a jump back to a row based on the table definition, thereby defining a repetitive definition of the group of bit positions associated with the device under test functional block. Therefore, the periodicity of the group of bit positions within the input signal 310 may be defined by the table.

[0158] Thus, the control 340 can determine a functional block index for each bit in the received pattern. In other words, for each bit in the received pattern, the control 340 can determine which functional block of the device under test the bit is associated with (wherein some bits of the received pattern may not actually be associated with any functional block of the device under test, for example, may be represented by a "special" functional block index indicating no association). Thus, for example, the control 340 can provide a functional block index for each bit (bit position) of the received pattern, including an index indicating no association. For example, the index can be used to control the error separator 332a, because the index can define to which result unit 336a, 336b, 336n the error signal (or error signaling) should be forwarded. In addition, the index determined by the control 340 can also be used to determine whether the error recorder 350 should record the individual failure information 312b in the event of an error in the corresponding bit. For example, it can be defined that for an error bit (bit position) to which the control 340 has associated a certain index value, the individual failure information should be recorded, while if other index values ​​are associated with the error bit (bit position), the individual failure information should not be recorded. Therefore, the control 340 can distinguish different groups of one or more bit positions, for example, based on the table definition of the group of bit positions, and using the timing synchronization with the stimulus generator, the reference signal generator and the comparator, the control 340 can control the generation of summary failure information and the recording of individual failure information according to the determination that the error occurs in one or more bit groups (defined in the definition of the group of bit positions based on the table). Therefore, the test device 300 can obtain summary failure information 312a indicating the integrity of different functional blocks of the device under test, and the test device can obtain individual failure information 312b of selected functional blocks of the device under test.

[0159] Furthermore, it should be noted that the test apparatus includes a test flow control 380, which can, for example, determine which test programs are to be executed. For example, the test flow control can control the stimulus generator and the reference signal generator, but the test flow control can also control other components of the test apparatus. However, the test flow control 380 can make decisions on the execution of the test flow based on the summary failure information 312a. In this regard, it should be noted that since the summary failure information 312a is usually determined during the execution of the test program, the summary failure information 312a can be obtained with almost no delay. Therefore, the test flow control 380 can quickly identify which functional blocks of the device under test seem to be error-free and which functional blocks are faulty or seriously faulty based on the summary failure information. Therefore, the test flow control 380 can decide which test programs should be executed based on the functional status information of different functional blocks of the device under test provided by the summary failure information. Therefore, a particularly efficient test flow can be achieved, for example, further testing of seriously failed functional blocks can be avoided, or, for example, a more detailed analysis of seriously failed functional blocks can be performed.

[0160] Of course, you can also modify the test parameters such as power supply voltage, clock frequency, etc. according to the overview failure information.

[0161] In summary, the test apparatus 380 provides a large amount of information about the device under test in a very efficient and fast manner. Interference with individual failure information records can also be prevented, and individual failure information records can be directed to one or more functional blocks of particular interest. Test flow control can also be optimized by using summary failure information.

[0162] Furthermore, it should be noted that the functionality of the apparatus 300 may be implemented completely or partially in hardware to allow for particularly fast reaction times. However, it should be noted that at least some of the functionality of the test apparatus 300 may be implemented in software.

[0163] Furthermore, it should be noted that the test apparatus may optionally include a plurality of error separators / error signal repeaters. For example, this may be advantageous if the comparator compares blocks of bits of the input signal and blocks of bits of the reference signal in a block-by-block manner. In this case, a plurality of error signals resulting from the block-by-block comparison may be processed in parallel. However, it should be noted that more than one error separator / error signal repeater is not necessarily required.

[0164] Furthermore, it should be noted that the functions described herein may also be implemented using different functional blocks. For example, the functions of an error separator / error signal forwarder may be implemented in a result unit, for example using a selective enabling mechanism.

[0165] Similarly, it should be noted that different practical implementations may be used to selectively enable and disable the recording of individual failure information. However, it seems important to have a control mechanism that can track which group of one or more bits the currently considered bit of the received pattern is associated with (which is equivalent to tracking which functional blocks the bits of the received pattern are associated with). By knowing which groups of bits (or equivalently which functional blocks of the device under test) the bits of the received pattern are associated with, the determination of summary failure information and / or individual failure information can be efficiently and accurately controlled.

[0166] Furthermore, it should be noted that the testing device 300 shown in FIG. 3 may optionally be supplemented with any features, functions and details disclosed herein.

[0167] 4. According to Figure 4 The bit stream

[0168] Figure 4 A schematic diagram representation of an example bit stream provided by a device under test is shown. The bit stream is indicated at 400.

[0169] The bit stream is provided by the device under test and may constitute a received pattern received by the test apparatus disclosed herein.

[0170] For example, the bit stream may be logically divided into 32-bit blocks, where each row 410a, 410b, 410c displays a sequence of 32 bits from a different pin of the device under test. For example, bits 0-2, 8-10, 16-18, and 24-26 may not be related to a functional block of the device under test, but may provide general information such as synchronization information, parity information, undefined information, or a determined fixed value. However, bit positions 3-7, 11-15, 19-23, and 27-31 may provide information associated with different functional blocks of the device under test. For example, bit positions 3-7, 11-15, 19-23, and 27-31 may include test results for different functional blocks of the device under test.

[0171] For example, different functional blocks of the device under test may be stimulated by one or more stimulus signals provided by the test apparatus, wherein the stimulus signals may be input into a scan chain of the device under test and / or input into an input terminal (e.g., the device under test). However, the result information of the functional blocks of the device under test may, for example, be based on internal signals of the device under test (or the functional blocks of the device under test), which are multiplexed into the bitstream 400.

[0172] For example, it can be seen from the first row 410a that the bit sequence designated as 422a may start from bit e0 of the (first) functional block e of the device under test, may continue from two bits c7, c3 of the (second) functional block c of the device under test, may continue from two bits b6, b2 of the (third) functional block b of the device under test, may continue from three bits a8, a4, a0 of the (fourth) functional block a of the device under test, may continue from two bits g, g4, g0 of the (fifth) functional block g of the device under test, and may end with two bits e8, e4 of the first functional block e of the device under test. Thus, the sequence 422a may include 12 bits from five different functional blocks of the device under test (three bits of functional block e, two bits of functional block c, two bits of functional block b, three bits of functional block a, and two bits of functional block g). It can be seen that bits from different functional blocks of the device under test (e.g., which may represent the status of internal signals of the corresponding functional blocks) are interleaved into a common signal. For example, different bit positions may be associated with different internal signals of a functional block of the device under test, so that the actual values ​​of different bit positions may actually change over time, for example, depending on the "stimulus" of different functional blocks of the device under test. Thus, for example, the bit at bit position e0 may describe the state of a certain internal signal of the first functional block e and the bit at bit position e8 may describe the state of another internal signal of the first functional block e, and the bit at bit position e4 may describe another internal signal of functional block e. Similarly, the bits at bit positions c7 and c3 may describe different internal signals of functional block c, and so on.

[0173] However, the assignment of positions may have a certain periodicity. For example, bit position 21 in the 32-bit group shown in the first row of row 410a may again represent the same internal signal of the device under test that was sent out at bit position 3 in the first group of 32 bits (but at a later time). In addition, the following bit positions 22, 23, 27, 28, 29, 30 and 31 may also represent the same internal signal of the corresponding functional block that has been represented in bit positions 4, 5, 6, 7, 11, 12 and 13.

[0174] However, similar signals may appear on different pins of the device under test, as may be shown in the second row 410b and the third row 410c.

[0175] In general, it should be noted that the device under test usually provides a signal as an input signal to the test apparatus, which signal includes periodicity. The signal provided by the device under test at the input of the test apparatus usually includes a repetitive bit sequence that describes various signals within the device under test, which are usually internal signals of the functional blocks of the device under test, but may also include externally available signals.

[0176] However, the test apparatus is configured to keep track of which bits in the bit sequence belong to which functional blocks of the device under test (or which bits of the received signal or "received pattern" belong to which group of functional blocks), so that errors belonging to different functional blocks or groups of functional blocks of the device under test can be separated. To this end, the test apparatus can be configured to use rules that define which bits (or bit positions) in the received signal or received pattern are associated with which functional blocks of the device under test to trace back the assignment, for example using a table-based association rule definition.

[0177] For example, a table-based association rule description may define a group of bits by their length (one or more bits) and an index specifying their associated functional block or associated functional block group. In addition, a table-based association rule definition may optionally include definitions of periodicity and definitions of bits that are not associated with any functional block of the device under test (e.g., bit positions 0-2, 8-10, 16-18, and 24-26).

[0178] However, it should be noted that Figure 4 The shown bitstream 400 should be regarded as an example only, and different formats of the bitstream are possible.

[0179] 5. According to Figure 5 Mapping mechanism

[0180] Figure 5 1 shows a block diagram of a mapping mechanism that can be used in a test device according to the present invention. Figure 5 The mapping mechanism 500 can be selectively used in any test device discussed herein, for example according to Figure 1In the test device 100, according to Figure 2 in the test device 200 or in the test device 300 according to Fig. 3. However, the mapping mechanism 500 may also constitute an independent embodiment, which can be used alone.

[0181] according to Figure 5 The mapping mechanism 500 is configured to receive pass / fail-data (PFD) 510 .

[0182] In addition, the mapping mechanism 500 provides masked pass / fail data 512 and / or pass / fail data 514 for each core based on the pass / fail data 510. For example, the mapping mechanism 500 includes a hardware mapper 520 that receives the pass / fail data 510 and provides masked pass / fail data 512 and / or pass / fail data 514 for each core based on the pass / fail data 510. The hardware mapper 520 receives mapping data 522 from a mapping scheme 530.

[0183] For example, the mapping scheme 530 may define how the hardware mapper 520 should map the pass / fail data 510 to the masked pass / fail data 512 and / or the per-core pass / fail data 514. For example, the mapping scheme 530 may define which pass / fail data 510 should be masked (or omitted) in the masked pass / fail data 512, and / or may define which pass / fail data 510 should be received in the masked pass / fail data 512. For example, the mapping scheme 530 may define that some bits of the pass / fail data 510 may be received in the masked pass / fail data 512, or the mapping scheme 530 may define that some bits of the pass / fail data 510 should be blocked and should not be received in the masked pass / fail data 512.

[0184] For example, the mapping scheme 530 may include defining the positions of bits (e.g., groups of bits) of the pass / fail data 510 that should be received in the masked pass / fail data 510, and / or defining the positions of bits (e.g., groups of bits) in the masked pass / fail data 512 that should not be received from the pass / fail data 510. For example, the hardware mapper 520 may include a controllable transmission gate for obtaining the masked pass / fail data 512 based on the pass / fail data 510, wherein the controllable transmission gate may be controlled by the mapping data 522.

[0185] In addition, the hardware mapper 520 can distribute the pass / fail data 510 (e.g., to multiple different outputs) to obtain pass / fail data for each core or a pass / fail signal 514 for each core. For example, the hardware mapper can forward a portion of the pass / fail data 510 to a first output, and can forward another portion of the pass / fail data 510 to another output. For example, the hardware mapper 520 can include a multiplexer for selectively forwarding the pass / fail data 510 to corresponding outputs, wherein the multiplexer can be controlled by the mapping data 522. Therefore, one or more bits of pass / fail data associated with (e.g., originating from) a first functional block (e.g., core) of the device under test can be forwarded to the first output by the hardware mapper, and the hardware mapper 510 (or its multiplexer) can forward one or more other bits of pass / fail data 510 associated with another functional block (e.g., core) of the device under test to another output. Thus, the pass / fail data 510 can be separated into pass / fail data 510 associated with different functional blocks (e.g., cores) of the device under test, for example, different bits of the pass / fail data 510 can be forwarded to different outputs to obtain independent per-core pass / fail data signals. This multiplexing can also be controlled by mapping data 522, which comes from mapping scheme 530.

[0186] For example, the mapping mechanism 500 may be configured to forward pass / fail data based on bits e0, e4, e8, c3, c7, b2, b6, g0, and g4 into the masked pass / fail data 512, but may, for example, block pass / fail data from bits a0, a4, and a8, so that the pass / fail data based on bits a0, a4, and a8 are not included in the masked pass / fail data 512. This may be useful, for example, if functional block (or core) a fails severely (e.g., generates a large number of fail bits). Thus, the amount of pass / fail data indicating error bits can be kept within a reasonably small range.

[0187] In addition, the mapping mechanism 500 can be configured, for example, to selectively forward pass / fail data based on bits a0, a4, and a8 to a first output (a first core-by-core pass / fail data output), forward pass / fail data based on bits b2 and b6 to a second output (a second core-by-core pass / fail data output), forward pass / fail data originating from bits c3 and c7 to a third output (e.g., a third core-by-core pass / fail data output), forward pass / fail data originating from bits e0, e4, and e8 to a fourth output (e.g., a fourth core-by-core pass / fail data output), and forward pass / fail data originating from bits g0 and g4 to a fifth output (e.g., a fifth core-by-core pass / fail data output). Thus, pass / fail data based on bits within a received pattern associated with different functional blocks (cores) of the device under test can be forwarded to different outputs of the hardware mapper 520, so that errors associated with different functional blocks (cores) of the device under test can be separately registered and / or counted.

[0188] Furthermore, it should be noted that the hardware mapper 520 can, for example, take over the functionality of the error separator / error signal forwarder 332a and / or selectively forwarding error signals to the error logger 350. For example, the pass / fail data 510 can correspond to one or more error signals 322, and the masked pass / fail data 512 can, for example, correspond to one or more masked error signals that trigger the error logger 350. Furthermore, the pass / fail signal 514 per core can correspond to the error signal that is selectively forwarded to the result units 336a, 336b, 336n. For example, the mapping scheme 530 can be evaluated by the control 340, and the mapping data 522 can correspond to the error separator control signal 342 and / or the error logging control signal 343. For example, the multiplexing functionality implemented in the hardware mapper 520 can correspond to the multiplexing functionality implemented in the error separator / error signal forwarder 332a.

[0189] For example, the masking function implemented in the hardware mapper 520 may correspond to selectively forwarding multiple errors in the comparator 320 to the error logger 350. For example, the control 340 may evaluate the mapping scheme 530, where the mapping scheme 530 may correspond to the definition of the group of table-based bit positions shown in FIG.

[0190] Furthermore, it should be noted that the mapping defined by the mapping scheme 530 should preferably be periodic after X periods. However, the functionality of the mapping generally depends on the mapping scheme used (wherein in some embodiments, a table-based mapping scheme may be used).

[0191] In summary, Figure 5A block diagram showing a mapping mechanism that may be used in any embodiment of the present invention.

[0192] In addition, it should be noted that Figure 5 The mapping mechanism may optionally be supplemented by any features, functions and details disclosed herein.

[0193] 6. According to Figure 6 Per-core result mappers and mapping schemes

[0194] The following will refer to Figure 6 The result mapper per core (RPC (result per core), RPCM (result per core mapper)) is described. It should be noted that the result mapper per core described below can be selectively used in any embodiment disclosed herein.

[0195] A per-core result mapper (RPC) may be configured to view a comparison result (e.g., evaluate a comparison result), but (for example) at a granularity of four device cycles (e.g., a granularity of four bits or four bytes, for example, if a device cycle provides four bytes). However, different length device cycles may be used, and different numbers of device cycles processed by the per-core result mapper may be used. Additionally, the per-core result mapper may also choose to operate on individual bits.

[0196] On this subject, it should be noted that if the mapping description does not end at the end of the mapper line, it should be expanded (or in some cases needs to be expanded) until it fits completely.

[0197] For example, if it is desired (or necessary) to initially ignore some test processor cycles, they may be mapped to unused cores. For example, an unused core index may be associated with such data (associated with the test processor cycles to be ignored).

[0198] Now refer to Figure 6 , describes the mapping scheme and the table-based mapping scheme definition. For example, the mapping scheme is used for the so-called "X4 mode", in which, for example, four device cycles are processed together. However, the mapping scheme can also be used for different modes, even for modes in which individual bits of the received mode are processed separately.

[0199] For example, table-based definition 600 (which may be considered a mapping description) includes a plurality of rows 610a to 610b. n For example, the table-based definition 600 may include a plurality of columns 612a through 612d, where the number of columns may vary between one column and a plurality of columns.

[0200] For example, each device cycle is associated with one column, but there may be different associations. For example, in a simple embodiment, there may be only one column, and the column may be associated with a single group of one or more bits.

[0201] Optionally, the row can have a repeat indicator 616, for example, it can indicate whether the row should be repeated and / or can indicate how many times the row should be repeated. Optionally, the row can include a jump indicator (not shown), for example, it can define jumping back to the previous row or further jumping to the next row.

[0202] exist Figure 6 In the example shown, rows 610a, 610b, 610c, 610d (or at least a portion of the rows) include a data field for each device cycle, wherein the data field may, for example, include a function block index (or core index) for each bit associated with each device cycle. For example, if it is assumed that the bits of the received pattern should not be evaluated in the first four device cycles DC1, DC2, DC3, DC4 (described by the first row 610a), an unused function block index (e.g., "9") is included in the data field of the first row, which is related to the association of the bits of the received pattern with the function blocks. For example, the function block index of all bits of device cycle 1, device cycle 2, device cycle 3, and device cycle 4 may be set to an unused function block index value of 9. For example, this may cause the control 340 or the mapping scheme 530 or the hardware mapper 540 to discard (rather than forward) an error signal associated with the relevant device cycle.

[0203] For example, the first row 610a may also include a repeat indication 616 indicating that the definition of the first row 610 should be repeated n times. Therefore, the received bits of the received pattern of 4xn device cycles will be discarded. This may be reasonable, for example, if the device under test requires 4xn device cycles to provide predictable (deterministic) results after starting the test. Therefore, the received pattern associated with these 4xn device cycles will not be used for error registration, error counting, or error logging (for the logging of individual signal information).

[0204] However, starting with row 1 (610b), one or more rows in the map 600 will define the association of the bits of the received pattern with the (real) functional blocks (cores) of the device under test.

[0205] For example, the first entry in row 610b may define that (all) bits of the first device cycle are associated with the first functional block of the device under test (functional block index "1"). The second entry in row 610b may indicate that three bits of the second device cycle are associated with the second functional block of the device under test (functional block index "2"), and the other bits of the second device cycle are associated with the third functional block (functional block index "3"). In addition, the third entry in row 610b may indicate that the first bit of the third device cycle may be associated with the third functional block of the device under test (functional block index "3"), and the other bits of the third device cycle are associated with the fourth functional block of the device under test (functional block index "4"). In addition, the fourth entry in row 610b indicates that (all) bits of the fourth device cycle are again associated with the first functional block of the device under test (functional block index "1").

[0206] Furthermore, the definitions in row 610c and row 610d are similar. Figure 6 As can be clearly seen in FIG. 610b, the bits associated with the different functional blocks of the device under test have a periodicity of, for example, three device cycles. Thus, given that each of rows 610b to 610d defines bits of four device cycles associated with a functional block of the device under test, at the end of row 610d, Figure 6 The periodicity of the entire row in the table.

[0207] Thus, for example, in the entry of row 610d, or in the entry of the next row, or in separate information, there may be an indication that after the mapping of row 610d is completed, the mapping should jump back to the beginning of row 610b. Thus, the associations defined in rows 610b to 610d will be repeated. Thus, the periodicity of the bit positions associated with the functional blocks can be effectively taken into account.

[0208] However, it should be noted that different mechanisms may be used to define the association between one or more blocks of bits and the functional blocks of the device under test. For example, in the case of large block lengths, it may be more efficient to define the length of the block of bits using a value (e.g., in bits or bytes, or in any suitable length unit), while it may still be advantageous to use indications of repeats or jumps in such a table or list.

[0209] In conclusion, Figure 5 and Figure 6 The concepts described may be selectively used in any embodiment of the present invention or in the present invention. However, it should be noted that Figure 5 and Figure 6 The functions described may be optionally supplemented by any features, functions and details disclosed herein, either alone or in combination. Figure 5 and Figure 6 The concepts described can also be used individually.

[0210] In the following example, a brief description of how the per-core result mapper (RPC, RPCM) works is provided. In an embodiment, the RPC looks at the comparison results, but at a granularity of four device cycles. If the mapping description does not end at the end of the mapper line, it may be expanded until it fits. For example, an automated test equipment may run in X4 mode, where, for example, four device cycles are processed per step.

[0211] For example, if you want to initially ignore some test processor cycles, you can map them to unused cores.

[0212] For example, the mapping starts at row #1.

[0213] At the end of line #3, we can programmatically jump to the start of line #1 - in some cases this will run forever. For example, a reset will cause the program to go back to the start of #0.

[0214] In other words, the table-based mechanism may be able to handle a jump instruction, jump to another row of the table, such as back to the previous row. Infinite repetitions may be programmed, for example, the test flow control 380 may stop such repetitions, but the number of repetitions may also be limited in the table-based mechanism.

[0215] However, it is important to note that these implementations should be considered optional.

[0216] 7. According to Figure 7 Methods

[0217] Figure 7 A flow chart of a method 700 for testing a device under test is shown. The method 700 includes 710, receiving a pattern from the device under test, the pattern including information from a plurality of functional blocks of the device under test. The method also includes 720, isolating errors within the received pattern associated with different functional blocks of the device under test during execution of a test program. Thus, using the method 700, test results by functional block can be obtained.

[0218] It should be noted that the method 700 is based on the same considerations as the above-mentioned test apparatus.

[0219] Furthermore, it should be noted that the method 700 may selectively be supplemented with any of the features, functions, and details disclosed herein, either alone or in combination.

[0220] 8. Other aspects and conclusions of the embodiments

[0221] Other aspects and details of the present invention will be described below. In addition, corresponding conclusions will be provided. However, it should be noted that any aspect and embodiment disclosed herein can be selectively combined with other embodiments disclosed herein, and can be used alone or in combination.

[0222] It should be noted that per-core processor results are created according to embodiments of the present invention.

[0223] It should be noted that in order to improve the best utilization of available bandwidth for scan and functional testing, EDA software and test design participants started to study how to send test patterns for different cores to the device under test (DUT) through the test interface, rather than sending pure patterns (individual cores) to the target IP core one by one. This will be done on the test stimulus side and the device response side.

[0224] We have learned that it is very advantageous to have specialized hardware to understand (e.g., evaluate) the device's answers and quickly make the necessary test flow decisions.

[0225] The basic considerations are outlined below.

[0226] To improve the best utilization of available bandwidth for scan and functional testing, EDA software and test design participants began to investigate how to interleave test patterns for different cores when sending them to the device under test (DUT) through the test interface, rather than sending pure patterns (individual cores) to the target IP cores one by one.

[0227] It should be noted that in the context of the present invention, "core" refers here to a basic unit of logic design, which should be analyzed separately in testing (e.g., test unit, e.g., granularity of test results). In addition, it should be noted that "core" is an example of a "functional block".

[0228] The extent to which this occurs may vary from case to case. For example, the present invention encompasses the following examples, but is not limited thereto:

[0229] For example, the device under test may consist of four cores 1, 2, 3, and 4. The test data is divided as follows, in the test pattern, the sequence is repeated 1...N times. N is usually between 10000..., 500000 (but it can also take other values).

[0230] οCore 1 32-bit

[0231] οCore 2 18-bit

[0232] οCore 3 24-bit

[0233] οCore 4 48-bit

[0234] • In the second example, the sequence of cores is longer and the cores may be interleaved or non-stop.

[0235] ο 10000 bits of core 1

[0236] οCore 2 32000 bits

[0237] οCore 3 50320 bits

[0238] οCore 4 200010 bit

[0239] These sequence examples will differ on all test pins involved in the test, but may be identical in special cases.

[0240] In summary, the received pattern may comprise a plurality of bit groups, e.g. from different cores, wherein the received pattern may comprise a (e.g. periodic) repetition of a sequence, wherein each sequence comprises, e.g., a group of one or more bits associated with a different functional block (core) of the device under test. However, if the sequence is relatively long, it is not necessary to repeat the sequence.

[0241] Figure 4 An example of a bit sequence over time (columns, x-axis) is shown for different test pins (rows).

[0242] For example, this will be tested on the test stimulus side and the device response side. On automated test equipment (ATE), it is best to have a result processor to handle this mode, which will be called "multi-core mode" below.

[0243] Generally speaking, during test execution, a stimulus pattern is sent to a device under test (DUT) (where, for example, the stimulus pattern is generated by stimulus generator 390 shown in FIG. 3 ), and at the same time, a response of the device under test is compared with a response pattern (where, for example, the response pattern may be generated by reference signal generator 326 , where the response pattern may be designated as a “reference pattern,” where the response pattern may be represented by reference signal 328 ). For example, both parts include test patterns.

[0244] The comparison part (e.g., comparator 320) checks the level information from the device under test (DUT) according to the expected logic state to understand the correct expected state (where the expected state can be defined by a reference pattern or a reference signal). The response part of the pattern usually defines expected 0 (low, L), expected 1 (high, H) or mask (ignore state, X).

[0245] If a deviation is identified, and the expected pattern does not show an "X", this is typically recorded in the status flags (e.g. global and / or per signal) highlighting "Compare Failed" and detailing the N failed cycle errors (expected state for the sequence within the pattern) and their addresses (sequence numbers).

[0246] In traditional SCAN and functional test flow decisions, decisions are usually made based on global pass / fail status flags and each test signal pass / fail status flags, but it has been recognized that in the case of the multi-core mode mentioned above, this used model has become invalid because there is no longer exactly the same mapping signal failure → core / functional block failure, because many cores are behind the signal pin or may cause a failed test result. Therefore, we find that the ATE architecture should introduce new elements to cope with this type of test mode.

[0247] According to aspects of the present invention, the design of the result processor encompasses the following functionality (as defined in the claims).

[0248] Test result tracking based on core granularity

[0249] According to one aspect, test results are tracked based on a per-core granularity.

[0250] According to aspects of the present invention, it is desirable that the hardware supports multiple cores, where a "core" refers to a result unit. Each result unit tracks whether a failure occurred during the test execution. For example, the hardware may support 64 result units, which may be allocated to track the results of one or more IP cores in the device under test. This hardware is hereinafter referred to as a "core mapper". It involves mapping the location of a fault to a core in other modules described below (or generally referred to herein).

[0251] For example, the error separator / error signal forwarder 332a may assume part or all of the functionality of a so-called "core mapper." However, the result units 336a, 336b, 336n may also assume part of the functionality of a "core mapper."

[0252] For example, the core mapper may be able to track these test results for each test execution or each mode used in the test execution (eg, intermediate results may be reset after a result mode). Thus, per-core test results at the time granularity of one test mode may be achieved.

[0253] For per-pattern profiling, one might want (or need) fine-grained control to reset (restart) the profiler as well as to freeze and reset the results obtained in the pattern that just finished and start from a clean state at the start of the next pattern.

[0254] For example, the reset input and / or freeze input of the result units 336a, 336b, 336n can reset the corresponding error flag register and / or the corresponding error counter, wherein the time of reading the result units 336a, 336b, 336n and / or the time of resetting the result units and / or the time of "freezing" the result units can be determined by the control 340 or the test flow control 380 as required.

[0255] According to one aspect, it should also support starting the core mapper only once per test execution and processing all results at the end (eg after the test execution). For example, the test flow control 380 or the control 340 can control this mechanism.

[0256] According to one aspect of the invention, the hardware should support short sequences of multiple cores as well as sequences of long blocks and test them in order (see above).

[0257] Results by core

[0258] According to one aspect, embodiments of the present invention provide results per core.

[0259] According to one aspect, the hardware can work in parallel with the compare failure logging that is typically done in the test equipment, it can record which cores have experienced at least one compare failure. For example, the hardware can be configured to report the results discussed herein at the granularity of a single test pattern or in groups (lists) of patterns. For example, this can be implemented in a (sticky) bit in the core overview error map that is set at the first failure and can then be read out after the test is completed.

[0260] For example, the error flag registers 337a, 337b, 337n can be used as "sticky bit" registers, and the outputs of these error flag registers can be combined to form a "core overview error map". Accordingly, by reading a single error flag register or a "core overview error map" formed by the combination of the outputs of the error flag registers, an overview of which functional blocks of the device under test have generated at least one error in the received mode can be quickly obtained.

[0261] For example, according to one aspect of the invention, this capability may be present even in situations where fault logging (e.g., performed by error logger 350) is limited or not performed at all, because information about which cores failed may be important for test flow decisions (e.g., as may be made by test flow control 380). For example, these decisions may involve additional test runs to further analyze the failure (e.g., involving special diagnostic modes) or branching to new test content for repair or the like.

[0262] For example, the summary error map should be able to be reset at the start of the mode, or more generally reset by the test execution controller (e.g. test flow control 380) when appropriate. But for example, individual reset of the error flag registers 337a, 337b, 337n is also possible.

[0263] Failure log requirements

[0264] In the following, some failure log requirements will be described, which may be selectively applied in some embodiments according to the present invention.

[0265] First, since the ATE test patterns are still derived from the ATPG tool (e.g., from an automatic test pattern generation tool), the data logger that generates the STDF file (e.g., Standard Test Data Format file) should record the failed cycles as before and generate the STDF or other format logger files for the EDA tool (Electronic Design Automation tool) to analyze the failure of the device. First, this cannot be changed.

[0266] In practice, the error map depth for recording these errors is limited, and a balance needs to be found between upload time and processing time. For the scenarios listed in the description (or in the cases listed here), this may result in a severely or fatally failed core generating a large number of comparison files (or comparison failures) in the response mode, making it impossible to analyze the cores or functions behind these severely failed cores. Therefore, in a mode, the failure contribution of elements tested later may not be visible in the error record.

[0267] However, users can tell that a core has failed by the sticky bit in the core overview error map.

[0268] In other words, the output of the "core overview error map" or error flag registers 337a, 337b, 337n allows the user of the test apparatus (or test flow control) to obtain a quick overview of the integrity of the functional blocks of the device under test.

[0269] Masking capabilities by core

[0270] In the following, per-core shielding capabilities will be described, which may be implemented in embodiments according to the present invention.

[0271] According to one aspect of the invention, a core feature is the ability to mask comparison failures. Traditionally, this is accomplished by setting the expected state character of the bit to a mask (usually designated by an "X"). In classic test mode, this is sometimes necessary to ignore initial failure states until a stable device state is reached, so that the initial random internal states are discarded until the first test result of the stimulus mode is obtained. The same applies to areas of the test mode where the expected results are unstable (such as logic and timing analysis modes).

[0272] According to one aspect, this approach is extended to a multi-core model, where results attributable to a specific core can be masked on a per-core basis. Applications include, but are not limited to:

[0273] Mask (error) results for fatal or severely failing cores, because if time recording is limited for practical reasons (test time, post-processing time), these results will flood the error map recording and prevent recording of cores with only a small number of failures

[0274] Centralized logging for one or more individual cores.

[0275] For example, per-core masking capability may be implemented in a variety of ways. For example, the test device may automatically insert masking information (e.g., "X") into the reference signal / reference pattern at a location associated with the functional block to be masked (e.g., during execution of the test program). Alternatively, the test device may disable the comparator and / or the error logger at the bit location associated with the functional block to be masked. For example, the test device may disable the forwarding of error signals from the comparator to the error logger for the bit (or bit position) associated with the device under test functional block to be masked.

[0276] Therefore, different hardware implementations can be used to obtain per-core automatic masking capability, wherein it should be noted that in a preferred embodiment, the per-core masking capability can be implemented "on the fly", for example during the execution of a test program, without modifying the input signals or input data of the reference signal generator / reference pattern generator (for example by introducing masking behind (after) the output of the reference signal generator / reference pattern generator).

[0277] Error counting capability per core

[0278] The per-core error counting capability is described below. According to one aspect of the invention, new logic is designed to accurately count the failures recorded per time period, not only in total, but also per core set in the core table. For example, failures (e.g., comparison failures) can be recorded per core (e.g., per core set in the core table).

[0279] This capability is very useful (or even required) to determine which cores (test units) show failures sufficient for analysis and which cores failed severely. This capability is useful (or required in some cases) because it allows analysis of which cores should be blocked (or must be blocked) in subsequent runs of the same multi-core mode when more results for a specific core are needed to obtain higher resolution result data. For example, it can decide which cores the test should focus on, select cores, and thus save the time needed to record results for severely (fatally) failing cores that the user is not interested in.

[0280] In other words, by counting the failures on a per-function block basis, it is possible to distinguish between function blocks without errors, function blocks with a small number of errors, and function blocks with a large number of errors. Therefore, this information (indicating whether a function block has no errors, only a small number of errors, or even a large number of errors) can be used to decide how to continue testing, wherein, for example, the test flow control 380 can use this information about the number of errors for each function block. For example, different test programs can be selected based on the number of errors associated with different function blocks, thereby focusing the test on function blocks with serious failures when necessary, or focusing the test on function blocks with no errors or only a small number of errors in the previous stage of the test. Therefore, efficiency can be improved.

[0281] Automatic shielding capability by core

[0282] In the following, a per-core masking capability that can be used according to aspects of the present invention will be described. This capability combines accurate error counting and masking capabilities. It also uses (or sometimes requires) comparing error counts to limits. For example, if one of the cores (or functional blocks) reaches a limit during a run test, the mask can be reprogrammed to mask subsequent failures of the core for comparison. In this way, each core can record a limited number of failures, regardless of whether the failure occurs at the beginning or end of the test execution, thereby avoiding flooding or blocking.

[0283] For example, when the error counter associated with a certain core reaches or exceeds a threshold, the control 340 may prohibit the error recorder 350 from recording the individual failure information associated with the core. Therefore, the amount of individual failure information recorded by each functional block of the device under test may be limited, so that even if there are one or more seriously faulty functional modules or cores, individual failure information of many different functional modules or cores (or even all functional modules) may be recorded. Therefore, efficient testing may be provided.

[0284] However, it should be noted that the per-core shielding capability, per-core error counting capability, and per-core automatic shielding capability described herein should be considered optional, and thus it is not necessary to implement all of these functions in a specific embodiment of the present invention.

[0285] in conclusion

[0286] A brief summary of various aspects of the invention is provided below.

[0287] The functionality discussed here enables us to obtain most or all of the desired test results in a single execution of the test mode in some embodiments, for example, the following results can be obtained without re-execution:

[0288] Pass / fail information by core, e.g. for process decision making

[0289] By the absolute number of failures per core → determine if a fatal failure has occurred and whether a core needs to be re-executed in order to make a process decision

[0290] Limited number of failures recorded per core, e.g. for all cores → sufficient to record failure data for post-processing by EDA software

[0291] o First failed test cycle, standard information for analysis can be obtained for each core (e.g., guaranteed to be obtained)

[0292] In most cases, re-execution is only necessary if a single core should re-execute to record a large number of comparison failures.

[0293] Disable some cores for testing. In some cases, this requires combining two capabilities:

[0294] o Ability to disable testing of individual cores in the DUT's test circuit design (outside the scope of this invention)

[0295] o The ability to mask comparison failures for disabled cores, since a large number of (random) failures can be generated when comparing to the expected multi-core pattern. (Included in various aspects of the invention)

[0296] According to one aspect of the present invention, this new hardware capability eliminates the need for ATE software to perform complex post-processing and filtering of comparison results, greatly reducing the amount of data that needs to be recorded and post-processed. It also reduces the amount of setup data required because specific single core patterns can be removed, avoiding test time consumed by re-execution.

[0297] Furthermore, it should be noted that embodiments according to the present invention may be used in digital cards, such as digital channel modules for automatic test equipment.

[0298] In particular, the embodiments according to the present invention can be used in V93000 automated test equipment, for example, to improve T4 scanning capability and process multi-core mode.

[0299] 9. Implement alternatives

[0300] Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of a corresponding method, where a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware device, such as a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such a device.

[0301] According to some implementation requirements, embodiments of the present invention may be implemented in hardware or software. The implementation may be performed using a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM or flash memory, on which electronically readable control signals are stored, which may cooperate (or be capable of cooperating) with a programmable computer system to perform the corresponding method. Thus, the digital storage medium may be computer readable.

[0302] Some embodiments according to the invention comprise a data carrier having electronically readable control signals, which are capable of cooperating with a programmable computer system, such that the system performs one of the methods described herein.

[0303] Generally speaking, the embodiments of the present invention can be implemented as a computer program product with a program code, which is operable to perform one of the above methods when the computer program product runs on a computer.For example, the program code can be stored on a machine-readable carrier.

[0304] Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier.

[0305] In other words, an embodiment of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0306] A further embodiment of the inventive method is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) on which is recorded the computer program for performing one of the methods described herein. The data carrier, the digital storage medium, or the recorded medium are typically tangible and / or non-transitory.

[0307] Therefore, a further embodiment of the inventive method is a data stream or a sequence of signals representing the computer program for performing one of the methods described herein.For example, the data stream or the sequence of signals may be configured to be transmitted via a data communication connection, for example via the Internet.

[0308] A further embodiment comprises a processing means, for example a computer or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0309] A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0310] A further embodiment according to the invention comprises an apparatus or system configured to transmit (e.g. electronically or optically) a computer program for performing one of the methods described herein to a receiver. For example, the receiver may be a computer, a mobile device, a storage device, etc. For example, the apparatus or system may comprise a file server for transmitting the computer program to the receiver.

[0311] In some embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array may be used in conjunction with a microprocessor to perform one of the methods described herein. Typically, the method is preferably performed by any hardware device.

[0312] The devices described herein may be implemented using hardware devices, or using computers, or using a combination of hardware devices and computers.

[0313] The apparatus described herein, or any component of the apparatus described herein, may be implemented at least partially in hardware and / or software.

[0314] The methods described herein may be performed using a hardware device, or using a computer, or using a combination of a hardware device and a computer.

[0315] Any component of a method described herein or an apparatus described herein may be implemented at least in part by hardware and / or software.

[0316] The above embodiments are merely illustrative of the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to other persons skilled in the art. Therefore, it is intended that the present invention be limited only by the scope of the patent claims to be filed, and not by the specific details presented herein by way of description and explanation of the embodiments.

Claims

1. A test device (100; 200; 300; 500) for testing a device under test, in, The test apparatus is configured to receive a pattern from a device under test (102; 202; 302), the pattern comprising information from a plurality of functional blocks of the device under test; Therein, the test apparatus is configured to separate errors within the received pattern associated with different functional blocks of the device under test during execution of the test program.

2. The test device (100; 200; 300; 500) according to claim 1, in, The test apparatus is configured to instantly separate errors within the received pattern associated with different functional blocks of the device under test.

3. The test device (100; 200; 300; 500) according to claim 1 or 2, in, The test apparatus is configured to separate errors within a received pattern associated with different functional blocks of the device under test in real time and / or in time synchronization with a data rate at which the received pattern is received from the device under test and / or in time synchronization with a data clock at which the received pattern is received from the device under test.

4. The test device (100; 200; 300; 500) according to any one of claims 1 to 3, in, The test apparatus includes dedicated hardware (130; 230, 240, 250; 332a; 336a, 336b, 336n, 340; 520, 530) configured to separate errors within a received pattern associated with different functional blocks of a device under test.

5. The test device (100; 200; 300; 500) according to any one of claims 1 to 4, in, The test apparatus includes dedicated hardware (230; 332a; 520) configured to selectively forward an error signal indicating a deviation of a bit value of a received pattern associated with a specific functional block of the device under test from an expected bit value defined by an expected pattern to a result unit (336a, 336b, 336n) associated with the specific functional block of the device under test.

6. The test device (100; 200; 300; 500) according to any one of claims 1 to 5, in, The test apparatus includes dedicated hardware (240; 340) configured to selectively inhibit comparison between one or more bits of a received pattern associated with a particular functional block of the device under test and one or more corresponding bits of an expected pattern, and / or selectively inhibiting forwarding of comparison results between one or more bits of a received pattern and one or more corresponding bits of an expected pattern associated with a particular functional block of the device under test, and / or Processing of a comparison result between one or more bits of a received pattern and one or more corresponding bits of an expected pattern associated with a particular functional block of the device under test is selectively inhibited.

7. The test device (100; 200; 300; 500) according to any one of claims 1 to 6, in, The test apparatus includes dedicated hardware (240; 340; 530) configured to identify different blocks of one or more bits of a received pattern associated with different functional blocks of the device under test in order to separate errors within the received pattern associated with the different functional blocks of the device under test.

8. The test device (100; 200; 300; 500) according to any one of claims 1 to 7, in, The test apparatus comprises dedicated hardware (240; 340; 530) configured to identify different blocks of one or more bits of a received pattern using a table (341) defining the lengths of the blocks of one or more bits of the received pattern associated with different functional blocks of the device under test.

9. The test device (100; 200; 300; 500) according to any one of claims 1 to 8, in, The test apparatus includes a reference pattern generator (326) configured to generate a time signal (328) representative of an expected pattern, and The test device comprises a comparator circuit (220; 320) configured to compare a time signal (310) representing a received pattern with a time signal (328) representing an expected pattern, Therein, the comparator is configured to provide an error signal (222; 322) in response to a deviation between bits of the expected pattern and bits of the received pattern.

10. The test device (100; 200; 300; 500) according to any one of claims 1 to 9, in, The test apparatus is configured to individually track test results of different functional blocks of the device under test.

11. The test device (100; 200; 300; 500) according to claim 10, in, The test apparatus is configured to track test results of different functional blocks of the device under test separately by test mode or by test execution, the test results being obtained based on the received pattern.

12. The test device (100; 200; 300; 500) according to claim 10 or claim 11, in, The apparatus includes a plurality of result units (336a, 336b, 336n) associated with different functional blocks of the device under test; wherein the test device is configured to selectively reset one or more result units, and / or Therein, the testing device is configured to selectively freeze one or more result units.

13. The test device (100; 200; 300; 500) according to any one of claims 1 to 12, in, The test device is configured to compare the received pattern to an expected pattern; as well as wherein the apparatus is configured to separately register comparison failures associated with different blocks of one or more bits of the received pattern, and / or Comparison failures associated with different functional blocks of the device under test are registered separately.

14. The test device (100; 200; 300; 500) according to claim 13, in, The test fixture is configured to pass using a mapping scheme (341; 600) that associates bits defining a received pattern with different result locations (336a, 336b, 336n) that register comparison failures, and / or using a mapping scheme that defines the association of bits of the received pattern to different functional blocks of the device under test; Comparison failures associated with different functional blocks of the device under test are registered separately.

15. The test device (100; 200; 300; 500) according to any one of claims 1 to 14, in, The test apparatus includes a plurality of separate result units (336a, 336b, 336n) configured to track test results associated with different functional blocks of the device under test.

16. The test device (100; 200; 300; 500) according to any one of claims 1 to 15, in, The test apparatus includes a plurality of separate error flag registers (337a, 337b, 337n) associated with different functional blocks of the device under test.

17. The test device (100; 200; 300; 500) according to any one of claims 1 to 16, in, The test apparatus includes a plurality of separate error flag registers (337a, 337b, 337n) configured to be set in response to comparison errors between bits of the received pattern and corresponding bits of the expected pattern occurring in different blocks of one or more bits of the received pattern.

18. The test device (100; 200; 300; 500) according to any one of claims 1 to 17, in, The test apparatus includes a plurality of individual error counters associated with different functional blocks of the device under test.

19. The test device (100; 200; 300; 500) according to any one of claims 1 to 18, in, The test apparatus includes a plurality of separate error counters (338a, 338b, 338n) configured to increment in response to comparison errors between bits of the received pattern and corresponding bits of the expected pattern occurring in different blocks of one or more bits of the received pattern.

20. The test device (100; 200; 300; 500) according to any one of claims 1 to 19, in, The test apparatus is configured to selectively set an error flag from a plurality of individual error flags in response to detection of a deviation between bits of a received pattern and bits of an expected pattern and in accordance with an association rule (341; 600).

21. The test device (100; 200; 300; 500) according to any one of claims 1 to 20, in, The test apparatus is configured to, in response to detecting a deviation of bits of a received pattern associated with a given functional block of the device under test from an expected pattern, set a separate error flag associated with the given functional block of the device under test so as to respectively register comparison failures associated with different functional blocks of the device under test.

22. The test device (100; 200; 300; 500) according to any one of claims 1 to 21, in, The test apparatus is configured to selectively increment an error counter (338a, 338b, 338n) from a plurality of individual error counters in response to detection of a deviation between a received pattern of bits and an expected pattern of bits and in accordance with an association rule (341; 600).

23. The test device (100; 200; 300; 500) according to any one of claims 1 to 22, in, The test apparatus is configured to, in response to detection of a deviation of bits of a received pattern associated with a given functional block of the device under test from an expected pattern, increment a separate error counter (338a, 338b, 338n) associated with a given functional block of the device under test so as to respectively count comparison failures associated with different functional blocks of the device under test.

24. The test device (100; 200; 300; 500) according to any one of claims 1 to 23, in, The apparatus is configured to record individual failure information (312b), the individual failure information indicating corresponding failure positions for a plurality of comparison failures, and The apparatus is configured to obtain summary failure information (312a), which describes errors associated with different functional blocks of the device under test in summary form.

25. The test device (100; 200; 300; 500) according to any one of claims 1 to 24, The device is configured to record the failure cycle in a time-identifiable manner in addition to the error flag for each functional block and / or the error count for each functional block.

26. The test device (100; 200; 300; 500) according to claim 24 or 25, The test device is configured to continue updating the summary failure information (312a) even if the memory used to record the individual failure information (312b) is exhausted.

27. The test device (100; 200; 300; 500) according to any one of claims 24 to 26, in, The test apparatus is configured to selectively mask the recording of individual failure information (312b) for bits of the received pattern associated with one or more functional blocks of the device under test; and / or Therein, the test apparatus is configured to selectively enable recording of individual failure information (312b) of bits of the received pattern associated with one or more functional blocks of the device under test.

28. The test device (100; 200; 300; 500) according to claim 27, in, The test apparatus is configured to determine for which bits of the received pattern the recording of individual failure information (312b) should be omitted using a table (341) defining the lengths of blocks of one or more bits of the received pattern associated with different functional blocks of the device under test.

29. The test device (100; 200; 300; 500) according to claim 27 or claim 28, in, The test device includes dedicated hardware (340) configured to identify bits of the received pattern for which recording of individual failure information (312b) should be omitted.

30. The test device (100; 200; 300; 500) according to any one of claims 27 to 29, in, The test apparatus is configured to activate masking of recording of individual failure information (312b) of bits of a received pattern associated with a specific functional block of a device under test in response to detecting that an individual error counter (338a, 338b, 338n) that selectively counts comparison errors of bits associated with a specific functional block has reached a predetermined maximum value.

31. The test device (100; 200; 300; 500) according to any one of claims 1 to 30, in, The test apparatus is configured to identify different blocks of one or more bits of the received pattern using a table (341) defining the lengths of the blocks of one or more bits of the received pattern associated with different functional blocks of the device under test.

32. The test device (100; 200; 300; 500) according to claim 32 in, The test apparatus is configured to use the table (341) to identify periodic sequences of blocks of one or more bits of the received pattern associated with different functional blocks of the device under test.

33. The test device (100; 200; 300; 500) according to any one of claims 1 to 32, in, The test apparatus is configured to adapt the test flow based on information about errors within the received pattern associated with a given functional block of the device under test.

34. The test device (100; 200; 300; 500) according to claim 33, in, The test apparatus is configured to adjust the test flow in response to determining that a number of errors within a received pattern associated with a given functional block of the device under test has reached or exceeded a predetermined maximum number.

35. The test device (100; 200; 300; 500) according to claim 34, in, The test apparatus is configured to, in response to determining that the number of errors in a received pattern associated with a given functional block of the device under test has reached or exceeded a predetermined maximum number, activate masking of recording of individual failure information or deactivate recording of individual failure information for bits of the received pattern associated with the given functional block of the device under test, and repeat the test.

36. A test device (100; 200; 300; 500) for testing a device under test, in, The test apparatus is configured to receive a pattern from a device under test, the pattern comprising a bit sequence; Therein, the test apparatus is configured to separate errors within a received pattern associated with different blocks of one or more bits during execution of a test program.

37. A method (700) for testing a device under test, Wherein the method includes receiving (710) a pattern from a device under test, the pattern including information from a plurality of functional blocks of the device under test; Therein the method includes isolating (720) errors within the received pattern associated with different functional blocks of the device under test during execution of the test program.

38. A computer program for executing the method according to claim 37 when the computer program is run on a computer.

Images