A test vector generation method and device for ATE chip testing

Abstract

The application discloses a test vector generation method and device for ATE chip testing, relates to the technical field of ATE chip testing, and solves the problems of low coding efficiency, high error rate and incapability of supporting differentiated batch generation of multiple types of pins in the prior art. The method comprises the following steps: acquiring a pin list, a pin electrical type label and hardware DATA data, automatically matching pins and a test vector output template according to a mapping rule library, then performing standardized sorting processing on the matching result, finally performing compliance verification, and without manually reading a netlist, manually distinguishing types and selecting templates one by one, the method can greatly save man-hours, and the standardized sorting enables an engineer to quickly locate a corresponding Pattern line of a target pin in an ATE machine debugging stage, all data abnormalities are intercepted in advance before machine operation by using a compliance verification mechanism, ATE test interface errors and repeated shutdown rectifications caused by test vector errors are avoided, and retest costs are effectively compressed.

Description

Technical Field

[0001] This application relates to the field of ATE chip testing technology, and in particular to a test vector generation method and apparatus for ATE chip testing. Background Technology

[0002] ATE (Automatic Test Equipment) chip testing is a critical step in the integrated circuit manufacturing process, designed to verify the functional integrity and performance reliability of chips before delivery. The test system applies predefined test patterns—a set of input signals (logic levels such as 0 / 1 / L / H, etc.) arranged in a time sequence—to the chip under test (DUT) through multiple channels of the tester, and collects the chip's output response, comparing it with expected results to determine if there are manufacturing defects or design deviations. ATE testing is integrated throughout the chip design verification, wafer probing (CP), and final testing (FT) stages, and is a core means of ensuring chip yield and shipment quality.

[0003] Currently, in ATE chip test development, chroma patterns are manually written, requiring manual reading of the data netlist, differentiation of various pins, and matching of vector content one by one. There is a lack of automated tools that can generate patterns in batches for multiple pin types. This manual approach has the following problems:

[0004] 1. Insufficient batch processing capability and low coding efficiency: Modern chips typically contain dozens to hundreds of pins, each requiring a corresponding level sequence in the test vector. Manually processing each pin is time-consuming and inefficient, making the low coding efficiency particularly pronounced in scenarios involving multi-pin, high-volume chip test program development.

[0005] 2. Lack of unified coding standards, high error rate and difficulty in troubleshooting: Manual coding lacks standardized pin sorting rules and template constraints, and mismatches between pins and test vectors are prone to occur; once an error occurs, due to the lack of an automated exception capture mechanism, the error is often only exposed after the ATE machine is running, making troubleshooting and localization difficult, and repeated shutdowns and debugging lead to a significant increase in retesting costs.

[0006] 3. Inability to support differentiated batch generation of multiple pin types: Different types of pins (such as input / output signals, differential signals, power / ground, etc.) have different level formats and arrangement rules in the test vector. Existing solutions do not have the ability to automatically adapt the output format for the electrical type of the pin.

[0007] 4. Lack of an automatic verification mechanism for data compliance: Manual review is difficult to fully identify data anomalies such as pin duplication, inconsistent data length, and mismatch between pin electrical type and level signal. These anomalies cannot be automatically intercepted in the traditional process and are often exposed only after entering the ATE test execution stage, which further exacerbates the waste of test resources. Summary of the Invention

[0008] The purpose of this application is to overcome the problems of low coding efficiency, high error rate and inability to support batch generation of different types of pins in the prior art, and to provide a test vector generation method and apparatus for ATE chip testing.

[0009] Firstly, a test vector generation method for ATE chip testing is provided, including:

[0010] Obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test equipment, and preprocess them to generate unified netlist data;

[0011] Based on the preset mapping rule library between pin electrical types and test vector output templates, the system automatically matches the pins in the unified netlist data with the test vector output templates and outputs the matching results.

[0012] The matching results are standardized based on the hardware DATA and preset standardization rules to generate standardized test vector data.

[0013] The standardized test vector data is subjected to compliance verification. If the verification passes, a test vector file that can be recognized by the target test device is exported. If the verification fails, an alarm report containing abnormal pin information and the cause of the abnormality is generated.

[0014] In some possible implementations, the pin list contains unique numbers for all pins, the pin electrical type labels include the electrical type labels for the pins, and the hardware DATA includes DATA content and a pin data netlist.

[0015] In some possible implementations, the preprocessing includes format cleaning and pin and data association binding.

[0016] In some possible implementations, each pin electrical type in the mapping rule base uniquely corresponds to and is bound to a set of test vector output templates; the automatic matching includes: by traversing all structured pin data in the unified netlist data, automatically retrieving the corresponding test vector output template from the mapping rule base according to the pin electrical type of each pin, and establishing a one-to-one correspondence between pins and test vector output templates.

[0017] In some possible implementations, the pre-defined standardization rules include: placing input pins before output pins, grouping pins of the same electrical type together, grouping pins of the same protocol together, placing differential signal type pins first, and placing ground signal type pins last.

[0018] In some possible implementations, the compliance verification includes at least one of the following:

[0019] Pin repeatability check: Detects whether there are duplicate pins. If duplicate pins are found, an alarm is triggered.

[0020] Data length consistency check: Checks whether the data lengths of each pin are consistent. If they are inconsistent, an alarm is triggered.

[0021] Pin data consistency check: Checks whether the pin, pin electrical type and corresponding data are consistent. If they are inconsistent, an alarm is triggered.

[0022] Invalid data warning verification: Detects whether there are pin data with completely identical or invalid content. If so, an alarm is triggered.

[0023] In some possible implementations, an alarm report containing abnormal pin information and the cause of the abnormality is generated, including: summarizing all abnormal pins that failed the verification to generate an alarm list log, which includes the pin number that failed the verification and the reason for the failure, so that it can be manually checked and corrected and then re-imported to generate a secondary test vector.

[0024] Secondly, a test vector generation device for ATE chip testing is provided, comprising:

[0025] The import module is used to obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test equipment, and to preprocess it to generate unified netlist data;

[0026] The matching module is used to automatically match the pins in the unified netlist data with the test vector output template according to the preset mapping rule library between the pin electrical types and the test vector output template, and output the matching results.

[0027] The standardization module is used to standardize the matching results according to the hardware DATA and preset standardization rules to generate standardized test vector data.

[0028] The verification module is used to perform compliance verification on the standardized test vector data. If the verification passes, it exports a test vector file that can be recognized by the target test device. If the verification fails, it generates an alarm report containing abnormal pin information and the cause of the abnormality.

[0029] Thirdly, a computer-readable storage medium is provided that stores program code for execution by a device, the program code including steps for performing a method as described in any of the implementations of the first aspect above.

[0030] Fourthly, an electronic device is provided, the electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any of the implementations of the first aspect above.

[0031] This application has the following beneficial effects:

[0032] 1. This application uses PIN number, PIN electrical type label and hardware DATA as input, and the program reads and automatically associates and binds them; the mapping rule base pre-stores the pattern templates corresponding to DIG / DIFF / ANALOG and input / output pins, etc. When traversing all the pins of the chip, the corresponding template is automatically retrieved according to the electrical type label of each pin. The whole process does not require manual reading of netlists, manual differentiation of types and selection of templates one by one, which shortens the original manual configuration work of several hours to the second-level automatic completion, greatly saving manpower and time.

[0033] 2. After template matching is completed, this application uniformly sorts the output pattern rows according to the pin electrical type (input pins are placed first, output pins are placed last, and pins of the same type are grouped together, etc.). Unlike the shortcomings of traditional manual coding, where the pin order is messy and scattered and requires repeated reference tables during debugging, the standardized sorting enables engineers to quickly locate the pattern row corresponding to the target pin during the ATE machine debugging phase, significantly shortening the troubleshooting time and lowering the debugging threshold.

[0034] 3. This application incorporates four verification rules: pin repeatability verification, data length consistency verification, PIN number / PIN type / DATA matching consistency verification, and invalid data warning verification. All verifications are automatically executed before the test vector file is generated. Upon detecting an anomaly, output is terminated and a detailed alarm log is generated (marking the abnormal pin number and specific error cause). Engineers can correct the errors and re-import the log to continue generation. Unlike traditional manual visual verification, which is prone to missing errors, this application intercepts all data anomalies before testing, avoiding ATE test interface errors and repeated shutdowns for rectification due to pattern errors, effectively reducing retesting costs.

[0035] 4. The entire automated workflow described in this application can be implemented using the Python standard library (file I / O library, dictionary data structure, conditional judgment logic). Test engineers only need to provide a basic manifest file and do not need to master complex programming syntax to operate it. It can also be packaged as a graphical desktop application (exe) that can preview and generate test vectors and alarm reports, significantly lowering the technical barrier. Furthermore, this application can flexibly adapt to offline coding requirements of different pin sizes (tens to hundreds of pins) and different chip types, effectively shortening the overall chip testing and verification cycle. Attached Figure Description

[0036] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart of the test vector generation method for ATE chip testing according to Embodiment 1 of this application;

[0039] Figure 2 This is a simplified example diagram of the test vector file in Embodiment 1 of this application;

[0040] Figure 3 This is a simplified example diagram of the alarm report in Embodiment 1 of this application;

[0041] Figure 4 This is a structural block diagram of the test vector generation device for ATE chip testing according to Embodiment 2 of this application;

[0042] Figure 5 This is a schematic diagram of the internal structure of the electronic device according to Embodiment 4 of this application.

[0043] Figure label:

[0044] 100. Import module; 200. Matching module; 300. Standardization module; 400. Validation module. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] Example 1

[0047] like Figure 1 As shown in Embodiment 1 of this application, a test vector generation method for ATE chip testing includes:

[0048] S100: Obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test device, and preprocess them to generate unified netlist data.

[0049] This step involves acquiring three core types of external input data:

[0050] 1. Pin list data of the chip under test: all pins have unique numbers;

[0051] 2. Electrical type labels for the pins of the chip under test: Engineers distinguish between input and output signals. For example, GPIO0-1 is an input, GPIO2-3 is an output, GCLK is the clock, and GND is categorized by input. The electrical types of these pins are shown in Table 1 below:

[0052] Table 1: Pin Electrical Type Labels

[0053]

[0054] 3. Hardware DATA of the target test equipment: data content and pin data netlist. The data content refers to the data level information of each pin in the test vector (Pattern), that is, the content filled in the "data section" of the Pattern file. The pin data netlist refers to the physical connection mapping relationship between the pin and the test instrument channel, that is, recording which physical pin of the chip is connected to which test channel of the ATE test instrument.

[0055] Then, the above three types of data are preprocessed by format cleaning and pin & data association binding to generate unified netlist data, which is then sent to the next step.

[0056] S200: Based on the preset mapping rule library between pin electrical types and test vector output templates, automatically match the pins in the unified netlist data with the test vector output templates and output the matching results.

[0057] In this step, automatic matching is completed by retrieving the preset PIN-Pattern mapping rule library. In the preset PIN-Pattern mapping rule library, each type of PIN electrical type is uniquely bound to a set of Chroma Pattern data output type templates (i.e. test vector output templates).

[0058] The specific automatic matching process is as follows: By traversing all structured pin data in the unified netlist data, the corresponding test vector output template is automatically retrieved from the PIN-Pattern mapping rule base according to the pin electrical type of each pin, and a one-to-one correspondence between the pin and the test vector output template is established.

[0059] In this step, unlike the traditional manual selection of templates one by one, this step automatically performs pattern matching for all pins of the entire chip in batches, without manual intervention. For example, Table 2 below shows the mapping relationship between pin output types and test vector content:

[0060] Table 2: Mapping Relationship between Pin Output Types and Test Vector Contents

[0061]

[0062] S300. The matching result is standardized according to the hardware DATA and preset standardization rules to generate standardized test vector data.

[0063] In this step, the retrieved basic test vector output template is standardized by combining the hardware DATA data of the target test equipment: First, the electrical type of the pin is read, and the pins of different types are sorted according to the preset standardization rules. The preset standardization rules include: placing input pins before output pins, grouping pins of the same electrical type together, grouping pins of the same protocol together, placing differential signal type pins first, and placing ground signal type pins last, which is beneficial for subsequent debugging (i.e., subsequent debugging and troubleshooting / fault location).

[0064] For example, as shown in Table 3, the data positions of the pattern output are uniformly sorted according to the input first and the output last, based on the pin electrical type (each group of pins is arranged together).

[0065] Table 3: Sorting Table of Data Positions in Pattern Output

[0066]

[0067] In this step, the output pattern rows are uniformly sorted according to the pin electrical type (input pins are placed first, output pins are placed last, and pins of the same type are grouped together). Unlike the shortcomings of traditional manual programming, where the pin order is messy and scattered and requires repeated reference tables during debugging, the standardized sorting enables engineers to quickly locate the pattern row corresponding to the target pin during the ATE machine debugging phase, significantly shortening the troubleshooting time and lowering the debugging threshold.

[0068] S400. Perform compliance verification on the standardized test vector data. If the verification passes, export the test vector file that the target test device can recognize. If the verification fails, generate an alarm report containing abnormal pin information and the cause of the abnormality.

[0069] Specifically, compliance verification includes:

[0070] Verification rule 1: Check for duplicate pins; Solution: Delete redundant pins.

[0071] Verification rule 2: Inconsistent data lengths between pins; Solution: Check the data and supplement any missing or redundant data.

[0072] Verification rule 3: Inconsistent pin type, pin type, and corresponding data; Solution: An alarm will be triggered if the input pin type has an LH signal. Engineers need to check the input / output and O1, HL matching issues.

[0073] Verification Rule 4: Warning alarm for completely identical data content and invalid pin data; Solution: For pins that are all 0s and 1s, only an alarm should be triggered. It is necessary to check whether the pin is required, and it is not necessary to modify the pattern.

[0074] If the compliance verification passes, standard Chroma Pattern files that can be directly imported by Chroma devices will be exported in batches, along with a corresponding output pin-pattern mapping table, such as... Figure 2 The image shows a simple example of a standard Chroma Pattern file. Follow these notes to write the pattern file template: From top to bottom, the first rectangle retrieves the Chroma-specific dec resource definition file; the second rectangle contains the fixed format required before the pattern begins, including the HEADER (line 2), followed by the pin order, then the pattern name within parentheses, and then the start signal; the third rectangle contains the data, located between two asterisks, followed by the TS timing sequence; the fourth rectangle is the ending STOP; and the fifth rectangle is a "}" that corresponds to the previous "{". Only the pin order of the HEADER and the content of the data section are changed; the rest is a fixed template.

[0075] If the compliance verification fails, an alarm log is generated by summarizing all failed pins. This log includes the pin number and the reason for the failure, allowing for manual review and correction before re-importing for secondary test vector generation. Figure 3 The image shown is an example of an alarm inventory log, addressing situations such as... Figure 3 The alarm shown indicates that the engineer needs to check for duplicate GPIO1 pins and remove the redundant pins.

[0076] In this step, all compliance checks are automatically performed before the test vector file is generated. If an anomaly is detected, the output is terminated and a detailed alarm log is generated (marking the abnormal pin number and the specific error cause). Engineers can then correct the errors and re-import the log to continue generation. Unlike traditional manual visual verification, which is prone to missing errors, this embodiment intercepts all data anomalies before testing, avoiding ATE test interface errors and repeated shutdowns for rectification due to pattern errors, effectively reducing retesting costs.

[0077] The following complete functions can be achieved by writing program scripts using the Python programming language: inputting text using the PIN-data data list from the Python file read / write library; storing the mapping relationship between PIN types and Chroma Pattern data output type templates using a dictionary / data table; adding conditional judgment logic to achieve automatic verification and capture data anomalies; finally, batch writing Chroma configuration files according to the Chroma test program specification format; and can be extended and packaged into a desktop EXE tool, providing a visual interface to preview the generated pattern and log information.

[0078] In this embodiment, the PIN number, PIN type label, and hardware DATA data are used as inputs, and the program reads them and automatically associates and binds them. The pattern templates corresponding to DIG / DIFF / ANALOG and input / output pins are pre-stored. When traversing all the pins of the chip, the corresponding template is automatically retrieved according to the electrical type label of each pin. The entire process does not require manual reading of the netlist, manual differentiation of types, and selection of templates one by one. The manual configuration work that originally took several hours is shortened to seconds and completed automatically, which greatly saves manpower and time.

[0079] Furthermore, the entire automated workflow in this embodiment can be implemented using the Python standard library (file I / O library, dictionary data structure, conditional judgment logic). Test engineers only need to provide a basic manifest file and do not need to master complex programming syntax to operate it. It also supports packaging as a graphical desktop application (exe) that can preview generated patterns and error logs, allowing newcomers to quickly get started. This lightweight feature enables the solution to flexibly adapt to offline coding requirements of different pin sizes (tens to hundreds of pins) and different chip types, effectively shortening the overall chip testing and verification cycle.

[0080] Example 2

[0081] like Figure 4 As shown, Embodiment 2 of this application relates to a test vector generation device for ATE chip testing, comprising:

[0082] Import module 100 is used to obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test equipment, and to preprocess it to generate unified netlist data;

[0083] The matching module 200 is used to automatically match the pins in the unified netlist data with the test vector output template according to the preset mapping rule library between the pin electrical type and the test vector output template, and output the matching result.

[0084] The standardization module 300 is used to standardize the matching results according to the hardware DATA data and preset standardization rules to generate standardized test vector data;

[0085] The verification module 400 is used to perform compliance verification on the standardized test vector data. If the verification passes, it exports a test vector file that can be recognized by the target test device. If the verification fails, it generates an alarm report containing abnormal pin information and the cause of the abnormality.

[0086] It should be noted that other specific implementations of the test vector generation device for ATE chip testing in this embodiment can be found in the specific implementations of the test vector generation method for ATE chip testing described above. To avoid redundancy, they will not be repeated here.

[0087] Example 3

[0088] This application relates to a computer-readable storage medium in embodiment 3, which stores program code for execution by a device, the program code including steps for performing the method as described in any implementation of embodiment 1 of this application;

[0089] The computer-readable storage medium may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM); the computer-readable storage medium may store program code, and when the program stored in the computer-readable storage medium is executed by a processor, the processor is used to perform the steps of the method in any of the implementations of Embodiment 1 of this application.

[0090] Example 4

[0091] like Figure 5 As shown, an electronic device according to Embodiment 4 of this application includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the method in any of the implementations in Embodiment 1 of this application.

[0092] The processor can be a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute related programs to implement the method in any of the implementations of Embodiment 1 of this application.

[0093] The processor can also be an integrated circuit electronic device with signal processing capabilities. In implementation, each step of the method in any of the implementations of Embodiment 1 of this application can be completed by the integrated logic circuitry in the processor's hardware or by software instructions.

[0094] The aforementioned processor can also be a general-purpose processor, digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the functions required by the units included in the data processing apparatus of the embodiments of this application, or executes the methods in any implementation of Embodiment 1 of this application.

[0095] The above are merely preferred embodiments of this application; however, the scope of protection of this application is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in this application, based on the technical solution and its improved concept, should be covered within the scope of protection of this application.

Claims

1. A test vector generation method for ATE chip testing, characterized in that, include: Obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test equipment, and preprocess them to generate unified netlist data; Based on the preset mapping rule library between pin electrical types and test vector output templates, the system automatically matches the pins in the unified netlist data with the test vector output templates and outputs the matching results. The matching results are standardized based on the hardware DATA and preset standardization rules to generate standardized test vector data. The standardized test vector data is subjected to compliance verification. If the verification passes, a test vector file that can be recognized by the target test device is exported. If the verification fails, an alarm report containing abnormal pin information and the cause of the abnormality is generated.

2. The test vector generation method for ATE chip testing according to claim 1, characterized in that, The pin list contains unique numbers for all pins, the pin electrical type label includes the electrical type label for the pin, and the hardware DATA includes DATA content and a pin data netlist.

3. The test vector generation method for ATE chip testing according to claim 2, characterized in that, The preprocessing includes format cleaning and pin and data association binding.

4. The test vector generation method for ATE chip testing according to claim 1, characterized in that, In the mapping rule base, each pin electrical type uniquely corresponds to and is bound to a set of test vector output templates; the automatic matching includes: by traversing all structured pin data in the unified netlist data, automatically retrieving the corresponding test vector output template from the mapping rule base according to the pin electrical type of each pin, and establishing a one-to-one correspondence between pins and test vector output templates.

5. The test vector generation method for ATE chip testing according to claim 1, characterized in that, The pre-defined standardization rules include: placing input pins before output pins, grouping pins of the same electrical type together, grouping pins of the same protocol together, placing differential signal type pins first, and placing ground signal type pins last.

6. The test vector generation method for ATE chip testing according to claim 1, characterized in that, The compliance verification includes at least one of the following: Pin repeatability check: Detects whether there are duplicate pins. If duplicate pins are found, an alarm is triggered. Data length consistency check: Checks whether the data lengths of each pin are consistent. If they are inconsistent, an alarm is triggered. Pin data consistency check: Checks whether the pin, pin electrical type and corresponding data are consistent. If they are inconsistent, an alarm is triggered. Invalid data warning verification: Detects whether there are pin data with completely identical or invalid content. If so, an alarm is triggered.

7. The test vector generation method for ATE chip testing according to claim 6, characterized in that, Generate an alarm report containing information on abnormal pins and the reasons for the abnormality, including: summarizing all abnormal pins that failed the verification to generate an alarm list log. The alarm list log includes the pin number that failed the verification and the reason for the failure, so that it can be manually checked and corrected and then re-imported to generate a secondary test vector.

8. A test vector generation device for ATE chip testing, characterized in that, include: The import module is used to obtain the pin list and pin electrical type labels of the chip under test, as well as the hardware DATA data of the target test equipment, and to preprocess it to generate unified netlist data; The matching module is used to automatically match the pins in the unified netlist data with the test vector output template according to the preset mapping rule library between the pin electrical types and the test vector output template, and output the matching results. The standardization module is used to standardize the matching results according to the hardware DATA and preset standardization rules to generate standardized test vector data. The verification module is used to perform compliance verification on the standardized test vector data. If the verification passes, it exports a test vector file that can be recognized by the target test device. If the verification fails, it generates an alarm report containing abnormal pin information and the cause of the abnormality.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code for execution by the device, the program code including steps for performing the method as described in any one of claims 1-7.

10. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any one of claims 1-7.

Images