Device Under Test

Description

Background

Embodiments of the present invention relate to a method for performing a plurality of tests of a device under test. Further embodiments of the present invention relate to an automatic test equipment for performing a plurality of tests of a device under test.

An Automatic Test Equipment (ATE) has to perform a couple of electrical tests to ensure the functionality of a Device Under Test (DUT) according to its device specification. For analog devices like Analog-To-Digital Converters (ADC) or RF devices like mobile phone transceivers, a single test consists of 5 basic steps:

1. Setup: Set the ATE equipment and the DUT into a required test mode

2. Capture: Capture the DUT output in an ATE measurement instrument

3. Upload: Upload the captured data to a post-processing unit

4. Calculate: Calculate the result in the post-processing unit

5. Judge: Judge whether the result is within the DUT specification

Fig. 5 shows a plurality of tests performed on a DUT sequentially. For each test the respective procedures or processes are indicated.

A Communication Link (CL) between the ATE Measurement Units and the ATE Post- Processing Unit can be a shared resource: The link is used to setup measurement instruments as well as to read back capture results. This forces the next test to wait until the DUT output of the previous test was uploaded.

Commonly known systems use one of the following concepts'.

(1) The ATE does the upload and the calculation in a serial fashion as shown in Fig. 5.

(2) The ATE uses separate dedicated calculation DSP units (DSP = Digital Signal Processing), which require additional hardware links and link management, as is shown schematically in Fig. 6. Summary of the Invention

It is an object of the present invention to create a concept for testing a device under test enabling a high test throughput with a low hardware effort.

This objective is solved by a method according to claim 1 and an automatic test equipment according to claim 12. Embodiments of the invention relate to a method for performing a plurality of tests of a device under test, wherein each test comprises a foreground process comprising a setup procedure during which a desired test mode is set, and a background process comprising an upload procedure during which data captured from the device under test is provided, and wherein the foreground process is executed with a higher priority than the background process, thereby minimizing a delay between the start of consecutive tests of the device under test.

According to further embodiments, a capture procedure may be provided in the foreground process (e.g. after the setup procedure), during which data from the device under test is captured.

According to further embodiments, a calculate procedure may be provided in the background process (e.g. after the upload procedure) for calculating a result of the test based on the data uploaded.

It is an idea of embodiments of the present invention that a high test throughput can be combined with a low hardware effort if a test performed on a device under test is split into a foreground process and a background process with different priorities. The foreground process can comprise time critical test steps, like the setup procedure for setting the desired test mode, while the background process can comprise less time critical test steps like the upload procedure of the captured data from the device under test. By having a test split into a foreground process and a background process with different priorities it can be achieved that a resource, which may be shared by the foreground process and the background process, is only used by the background process if the foreground process does not need it. Typically, such a shared resource is not needed during the complete procedure of the foreground process, therefore there may be times during which the resource is free and can be used by the background process to perform its procedure. This enables a start of a second test, during which a first test is still active. For example, a second test can be started when the first test performs its background process (e.g. performs the upload procedure). The second test may start with its foreground process (e.g. performing its setup procedure) and therefore may have a higher priority than the background process of the first test. Hence, the background process of the first test may be halted when the foreground process of the second test needs a shared resource and may be continued when the foreground process does not need the shared resource. Hence, a delay between the start of consecutive tests of the device under test can be reduced or minimized, since a second test can be started while the first test is not completed. This dramatically increases the test throughput, i.e. more tests can be performed in the same period.

Further embodiments of the invention relate to an automatic test equipment for performing a plurality of tests of a device under test, including one or more measurement units; a postprocessing unit; a communication link connecting the one or more measurement units and the post-processing unit; and a control unit; wherein each test comprises a foreground process comprising a setup procedure during which a desired test mode is set, and a background process comprising an upload procedure during which data captured from the device under test is provided, wherein the communication link is shared by the foreground process and the background process, and wherein the control unit is configured to execute the foreground process with a higher priority than the background process, thereby minimizing a delay between the start of consecutive tests of the device under test.

It is a further idea that a test throughput of an automatic test equipment can be improved, when the test performed by the automatic test equipment comprises a foreground process and a background process which share the same communication link and which have different priorities. Compared to systems in which the test are not split into foreground and background processes, in embodiments the start of consecutive tests can be reduced, for example, by running a first test and by starting a second test with its foreground process while the first test still runs with its background process. The shared resource (the communication link) can be used by the background process of the first test and the foreground process of the second test. Due to the higher priority of the foreground process of the second test, the background process of the first test may use the communication link only when it is not blocked by the foreground process of the second test. It has been found that a procedure (e.g. a setup procedure) of a test does not need the shared resource throughout the complete procedure, but only at certain times during the procedure. Hence, during the procedure of the foreground process of the second test there may periods in which the procedure does not need the communication link. During these periods the background process of the first test may use the communication link. Hence, the second test does not have to wait until the first test is finished. As an example, the second test can be started when the first test finishes its foreground process and starts its background process.

Hence, embodiments enable a higher throughput of tests by splitting tests into foreground processes and background processes, such that several tests can run in parallel. As an example, a first test of a plurality of test running parallel may run in its foreground process, while the other tests of the tests running parallel run in the background process with a lower priority than the foreground process of the first test. Short Description of the Figures

Embodiments of the present invention will be described in the following using the accompanying figures, in which: Fig. 1 shows a schematic illustration how a method according to an embodiment may be performed;

Fig. 2 shows a block schematic diagram of an automatic test equipment according to an embodiment of the present invention;

Fig. 3 a shows a comparison between a method for performing a plurality of tests according to an embodiment and a method for performing the plurality of tests as it is commonly known; Fig. 3b shows a self-contained pseudo code example for a test performed by the automatic test equipment from Fig. 2;

Fig. 4a shows an example for a serial test approach; Fig. 4b shows how the tests from Fig. 4a may be performed according to an embodiment of the present invention;

Fig. 5 shows a known concept for performing a plurality of tests on a device under test sequentially; and

Fig. 6 shows an automatic test equipment using dedicated calculation DSP units.

Detailed Description of Embodiments Before embodiments of the present invention will be described in more detail using the accompanying figures it is to be pointed out that the same or functionally equal elements are provided with the same reference numbers and that a repeated description of this elements is omitted. Hence, descriptions of embodiments provided with the same reference numbers are mutually exchangeable.

Fig. 1 shows an illustration for a method for performing a plurality of tests of a device under test, according to an embodiment. In this method each test comprises a foreground process comprising a setup procedure during which a desired test mode is set and a background process comprising an upload procedure during which data captured from the device under test is provided. The foreground process is executed with a higher priority than the background process, thereby minimizing a delay between the start of consecutive tests of the device under test.

Fig. 1 shows a first test, Test 1, comprising a foreground process and a background process. The foreground process comprises a setup procedure for setting a desired test mode, for example, of the device under test. Furthermore, Test 1 comprises a background process comprising an upload procedure during which data captured from the device under test is provided. Typically the setup procedure is performed before the upload procedure. Furthermore, Fig. 1 shows a second test, Test 2, comprising a foreground process, the foreground process comprising a setup procedure. Furthermore, Test 2 comprises a background process, the background process comprising an upload procedure. The background processes of the two tests have a lower priority than the foreground processes, i.e. a resource shared by the foreground process and the background process can be blocked by the foreground process. In other words, the background process can use the shared resource (only) when the foreground process does not need the shared resource.

From Fig. 1 it can be seen that Test 2 can be started when Test 1 finishes its foreground process. Hence, Test 1 and Test 2 may share the same shared resource and either Test 1 or Test 2 runs in its foreground process, while the other test may run in its background process.

By starting Test 2 when Test 1 finishes its foreground process instead of starting Test 2 after the complete Test 1 is finished, the complete test time for the two tests can be reduced and therefore a test throughput can be increased. Fig. 2 shows a block schematic diagram of an automatic test equipment 200 according to an embodiment. The automatic test equipment 200 can be coupled to a device under test 202 for performing a plurality of tests of the device under test 202. The automatic test equipment 200 comprises one or more measurement units 204a to 204n (also designated as ATE measurement units). Furthermore, the automatic tests equipment 200 comprises a post-processing unit 206 (also designated as ATE post-processing unit). Furthermore, the automatic test equipment comprises a communication link 208 connecting the measurement units 204a to 204n and the post-processing unit 206. Furthermore, the automatic test equipment 200 comprises a control unit 210. Each test performed by the automatic test equipment 200 comprises a foreground process comprising a setup procedure during which a desired test mode is set, and a background process comprising an upload procedure during which data captured from the device under test 202 is provided. The communication link 208 is shared by the foreground process and the background process. The control unit 210 is configured to execute the foreground process with a higher priority than the background process, thereby minimizing a delay between the start of consecutive tests of the device under tests 202. The control unit 210 may be configured to control the measurement units 204a to 204n, the communication link 208 and the post processing unit 206. According to further embodiments, the control unit 210 may be part of the post processing unit 206. This approach of implementing the control unit 210 in the post processing unit 206 is simpler to implement and much cheaper to upgrade as the known concepts described in the introductory part of the application. Especially for low cost automatic test equipments, the integration of the control unit 210 in the post processing unit 206 has an economical advantage while still providing optimized throughput.

According to further embodiments, the post processing unit 206 may be part of a (commercial) personal computer, e.g. comprising a multi core CPU. Furthermore, the control unit 210 may be part of this personal computer.

As an example, the automatic test equipment 200 may perform Test 1 and Test 2 as shown in Fig 1.

As an example, during the setup procedure of Test 1 a first ATE measurement unit 204a and the device under test 202 are set into the desired test mode, for example, by the control unit 210 using the communication link 208. During the upload procedure of Test 1, data captured from the device under test 202 is uploaded from the first ATE measurement unit 204a to the post-processing unit 206 using the communication link 208. Therefore, the communication link 208 is used for both procedures of Test 1, namely for the setup procedure and the upload procedure. This may apply for all test performed by the automatic test equipment 200. Furthermore, Test 2 can be started after Test 1 has finished its setup procedure, for Test 2 a second measurement unit 204b and the device 202 may be set into the desired test mode (e.g. by the control unit 210) using the communication link 208. As can be seen from Fig. 1, the upload procedure for Test 1 may run parallel to the setup procedure for Test 2, the parallel running of these two procedures of the different tests is enabled by having different priorities for the setup procedure of Test 2 (as a foreground process) and of the upload procedure of Test 1 (as a background process). Hence, the upload procedure (as background process) of Test 1 can be halted by the control unit 210 when the setup procedure (as foreground process) of Test 2 needs the communication link 208 and can be continued when the setup procedure of Test 2 does not need the communication link 208 anymore. Hence, with the automatic test equipment 200 a plurality of tests can be performed on the device under test 202, wherein at least one test runs one of its procedures as a background process.

As mentioned before the automatic test equipment 200 may be configured, such that during the setup procedure of a test the one or more measurement units 204a to 204n and the device under test 202 are set into the desired test mode and during the upload procedure data captured from the device under test 202 is provided to the post-processing unit 206.

According to further embodiments the automatic test equipment 200 may comprise an optional judge unit 212 for judging if a result of the tests performed on the device under test 202 are within a specification for the device under test 202. The judge unit may be comprised in the post processing unit 206.

Fig. 3a shows a comparison between a plurality of test performed using the method according to the concept of the present invention and using a conventional concept. As can be seen from Fig. 3a a test can comprise additional steps. In the example in Fig. 3a foreground processes of the tests comprise a setup procedure and a capture procedure, while background processes of the tests comprise an upload procedure, a calculate procedure and a judge procedure. The judge procedure basically determines, whether a specific test result is within its tests limits (according to device specification), but in some cases a logging may be needed. Hence, according to further embodiments, the background processes may comprise an optional logging procedure. The logging can happen to a terminal like screen or a file. The goal as achieved with the concept shown in Fig. 3 a is to start the next test as soon as a setup and capture step (in a foreground process) of the preceding test have finished and to perform the upload and the calculation/judge step in a background process. This generates a clear throughput improvement. Although the communication link 208 is a shared resource, the communication between foreground (setup and capture) and background (upload, calculation and judge) may not impact test time in the critical path (for example, the foreground processes). The foreground processes may perform electrical tests on the device under test, for example, in the capture procedure. During this capture procedure a measurement unit, which has been set into a desired setup mode by the preceding setup procedure, captures the data from the device under test 202, which is then uploaded to the post-processing unit 206. A capture (procedure) represents the actual measurement with the ATE measurement units 204a- 204n, and may comprise just a simple response bit or large device under test response arrays to be postprocessed. The post-processing unit 206 calculates a result based on the uploaded data. The judge unit 212 judges whether the calculated result is within the device under test specification. Embodiments of the invention take advantage out of today's multithreading CPUs and their use as ATE Post-Processing Unit. The capture upload, calculation and judge are encapsulated in a self-contained coding unit and executed in a separate background process or thread. While calculation and judge can run in parallel to any other step, the upload needs to be controlled via the foreground due to the shared resource.

Some embodiments may split up the upload into multiple smaller segments. This allows to halt the upload quickly in case the foreground needs to take over control (e.g. to continue with the next test) and to resume at a later point of time. Foreground may not be slowed down by upload. The upload may be triggered by the foreground at situations, when there is no communication between post-processing and measurement unit necessary and the measurement unit is working in a self-sustainable mode, e.g. during device settling time or capture time. Before a new capture data segment is uploaded, the background threads evaluates whether the measurement unit is still operating in this particular mode. Otherwise data upload will halt other operations to start. Or, in other words, whenever a segmented background execution is finished, it is checked (e.g. by the control unit 210) if the foreground process requires the shared communication link 208, and if not, the next segmented background execution can be started (when required). According to further embodiments, the control unit 210 can determine when the communication link 210 is available and for how long (e.g. with a training run, calculation or similar) it is available. Based on this information, the control unit 210 may split the upload procedure of the background process (e.g. in segments fitting into this time windows, during which the communication link 208 is available).

According to further embodiments, the foreground process and the background process may have fixed time slots (time multiplexing), where they can access the shared communication link 208. The foreground process may have larger slots than the background process.

According to further embodiments, whenever the foreground process needs the shared resource (the communication link 208), the foreground process can immediately interrupt the background process, which can be resumed later on. In other words, the control unit 210 may implement an interrupt functionality, in which the foreground process has a higher priority than the background process. Hence, the control unit 210 may be configured to interrupt the background process, when the foreground process needs the communication link 208, and may resume the background process, when the foreground process does not need the communication link 208 anymore.

As an example, Test 1 may run on the first measurement unit 204a. After capturing the data from the device under test 202 Test 1 switches from the foreground process to the background process for uploading the captured data from the device under test 202 to the post-processing unit 206. The control unit 210 may now start Test 2 by setting up the second measurement unit 204b and the device under Test 202, using the communication link 208. Due to the higher priority of the foreground process of Test 2, the control unit 210 may pause the upload procedure of Test 1 until the communication link 208 is not needed anymore by the setup procedure for the second ATE measurement unit 204b. The control unit 210 may resume the upload of the data captured in Test 1 when no communication through the communication link 208 is needed for the foreground process.

From Fig. 3 a it can be seen that once the test data is captured a background process (for uploading, calculating and judging the test data) is called, and the flow can continue with the next test (for example, Test 2) and the next capture (of Test 2). The background process (also designated as background thread) independently handles the uploads and the calculation. According to an embodiment, a measurement unit (e.g. the first measurement unit 204a) may be configured such that it does not need the communication link 208 during the capture procedure, as during the capture procedure the measurement unit only communicates with the device under test 202. Hence, during the capture procedure the communication link 208 is available and can be used for the background processes, for example, for uploading captured data from another measurement unit to the postprocessing unit 206.

According to an embodiment, each test is written as a single entity (self-contained) to ensure proper code development.

Fig. 3b shows a self-contained pseudo code example for a test performed by the automatic test equipment 200. It becomes clear that the setup and capture procedure are run in a foreground process, for example with a high priority and the upload, calculate and judge procedures are run in a background process with a low priority.

As can be seen from Fig. 3a a plurality of background processes of a plurality of tests may run in parallel with one foreground process of another test. The test execution engine is as follows (also see Fig. 3 a and Fig. 3b):

The background process covers upload, calculation and judge, the foreground process covers setup and capture, the foreground triggers and halts the background upload. According to further embodiment alternative communication methods are possible, like prioritized interrupts (e.g. generated by the foreground process) or time sliced communication.

In other words, the background process can be controlled by the foreground process, such that the upload procedure of the background process starts or halts dependent on the availability of the communication link. The communication link is typically available when it is not required by the foreground process.

The upload procedure can be divided into a plurality of segments. By dividing the upload procedure into a plurality of segments, the upload procedure can be stopped and resumed easily.

According to further embodiments, the calculation procedure and the judge procedure can be executed by one or more threads provided in the post-processing unit. In an embodiment, the judge unit 212 may be part of the post-processing unit 206. As an example, the post-processing unit 206 may comprise a processor, for example, a multi-core processor. Therefore, embodiments make use of the fact that a multi-core processor can calculate several threads in parallel. From Fig. 3 a it can be seen that the background processes of Test 1 and Test 2 can run in parallel. For example, the calculate and judge procedures of Test 2 can run in parallel together with the calculate and judge procedures of Test 1 on different threads and therefore may be performed by different cores of the processor, as the shared resource (the communication link 208) is not needed for the calculation and judge procedures. As described before, the upload procedure for one test can be executed during the capture procedure of one or more tests following the one test.

To summarize, the measurement units 204a to 204n are configured to execute the capture procedure and the post-processing unit 206 (comprising a judge unit 212) is configured to execute the calculation procedure and the judge procedure, for example, of two or more tests in parallel. The scheduling of these calculation and judge procedures can be handled by the control unit 210.

Furthermore, the calculate and judge procedures of several tests can run in parallel, for example, without interruption of a setup procedure and a capture procedure of another test, since the calculate and judge procedure do not need the communication link 208.

Fig. 4a shows a test execution flowchart representing a conventional approach operating serially. Fig. 4b shows a test execution flowchart for the same test as in Fig. 4a in accordance with an embodiment of the present invention.

From Fig. 4b it can be seen that Test 1 kicks-off a background thread after his capture procedure has finished. Furthermore, Test 2 starts with its foreground process (in detail with the setup procedure). The setup procedure uses the communication link 208, therefore the upload procedure of Test 1 is paused. The capture procedure of Test 2 triggers the upload procedure of Test 1 and halts it as soon as the capture procedure has finished. During the capture procedure typically the communication link 208 is not used, therefore it is free for the upload procedure of Test 1. After the capture procedure of Test 2, Test 2 starts its background process. Furthermore, Test 3 starts its foreground process (in detail its setup procedure), such that the upload procedures of Test 1 and Test 2 are paused. Upon finishing the setup procedure of Test 3, Test 1 resumes its upload procedure, as the communication link 208 is not used by any foreground process (capture procedure of Test 3 does not need the communication link). In other words, the capture procedure of Test 3 triggers the upload procedure of Test 1 to finish and kicks-off the upload procedure of Test 2. The upload procedure of Test 2 starts after the upload procedure of Test 1 , because during the upload procedure of Test 1 the communication link 208 is used by the upload procedure of Test 1.

The calculation and judge procedures of the three tests can run in parallel, since they are not limited by the communication link.

By comparing Figs. 4a and 4b it become clear that a test time for the three tests can be reduced dramatically and therefore a test throughput can be increased with embodiments of the present invention.

According to further embodiments, the upload procedure of Test 1 may run during the setup procedure of Test 2, as during the setup procedure of Test 2, periods in time may exist, during which the shared communication link is not used by the setup procedure.

According to further embodiments, the upload procedure of Test 1 may start before the capture procedure of Test 1 finishes, such that already captured data is uploaded, while new data is captured (during one and the same Test).

In other words, the application could add an additional statement that the upload procedure (or in general the background process) may also perform during the setup procedure (e.g. device setup may require a long settling time, which can be used without overall performance impact, since the communication link is not used during the settling time) or capture (e.g. capture is large and since measurement units may feature a dual port memory and multiple capture banks, it could start uploading of already finished smaller blocks).

Embodiments of the present invention have the following advantages: No additional hardware link is necessary to allow parallel data upload and ATE measurement unit control.

No protocol change on the communication link is necessary to allow parallel data upload and ATE measurement unit control.

The simple implementation allows clear performance improvement (test time reduction) as shown with Figs. 4a and 4b. Embodiments of the present invention allow performance improvements without changing any hardware in the ATE measurement or the post-processing unit and are therefore applicable to any ATE platform. A further advantage is that the coding model in the test flow execution engine stays self- contained.

The concept of the invention, also referred to as the SmartCalc concept, takes advantage of the multi-core processor trend in the consumer market. Single consumer workstations can take over control of ATE measurement unit as well as perform parallel (in case multiple DUTs are tested at the same time) post-processing without loss of performance.

Thus, embodiments of the invention provide an ATE that allows the user to define setup, capture, upload, calculation and judge in one self-contained entity and partitions execution in the presence of a shared communication link in such a way that the critical foreground process is optimized.

Further embodiments of the invention provide an ATE that encapsulates and performs an upload of captured data in a background thread via a shared communication link between ATE measurement and post-processing unit.

Further embodiments of the invention provide an ATE that encapsulates and performs an upload of captured data in a background thread via a shared communication link between ATE measurement and post-processing unit and dividing the upload burst in multiple segments.

Further embodiments of the invention provide an ATE that encapsulates and performs capture data upload, result calculation and judge in single background thread, while performing upload via a shared communication link between ATE measurement and post- processing unit.

Further embodiments of the invention provide an ATE that controls the capture data upload, which runs on a background thread via a shared communication link, from the foreground, allowing to start or halt upload dependent on availability of the communication link between the ATE measurement and the post-processing unit.

Embodiments of the present invention allow data from a measurement to be uploaded from a measurement unit to a post-processing unit while other tests are being performed. The control unit 210 controls the upload of the digital or analog data from the measurement unit 204a to 204n to the post-processing unit 206 to avoid any impact on test time, e.g. it automatically triggers the upload whenever certain procedures are executed in parallel (for example, when a capture procedure and/or a calculation procedure and/or a judge procedure of another test are active at the same time). When the execution time of such a single procedure running in parallel to the upload procedure is not sufficient, the upload procedure may span over multiple such parallel procedures. This is possible because the upload can be performed in small segments. The upload in the background will automatically pause when such a parallel procedure is finished and seamlessly continues with the next, besides the next procedure is a setup procedure, needing the communication link 208. As soon as the upload is done, the calculation will continue regardless of what happens in the foreground. As the upload procedure of a test can be paused when another test performs a setup procedure, the measurement units 204a to 204n may comprise a memory for storing the data captured from the device under test 202, at least until the captured data is completely uploaded to the post-processing unit 206.

According to further embodiments, the control unit 210 will trigger a waiting upload procedure of a test whenever it does not effect the throughput of the main test flow (of the running foreground process). As soon as the (serial) upload thread or upload procedure is finished, the calculation thread or procedure continues in parallel on different CPU cores.

According to further embodiments the calculation procedure and the judge procedure of two or more tests run in parallel on different threads, e.g. on different CPU cores of a CPU of the post processing unit 206.

Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Analogously, 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 executed by (or using) a hardware apparatus, like for example, a microprocessor, a programmable computer or an electronic circuit. In some embodiments, some one or more of the most important method steps may be executed by such an apparatus.

Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be performed using a digital storage medium, for example a floppy disk, a DVD, a Blue-Ray, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, having electronically readable control signals stored thereon, which cooperate (or are capable of cooperating) with a programmable computer system such that the respective method is performed. Therefore, the digital storage medium may be computer readable.

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 one of the methods described herein is performed.

Generally, embodiments of the present invention can be implemented as a computer program product with a program code, the program code being operative for performing one of the methods when the computer program product runs on a computer. The program code may for example be stored on a machine readable carrier.

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

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.

A further embodiment of the inventive methods is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) comprising, recorded thereon, 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- transitionary.

A further embodiment of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be configured to be transferred via a data communication connection, for example via the Internet.

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. A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

A further embodiment according to the invention comprises an apparatus or a system configured to transfer (for example, electronically or optically) a computer program for performing one of the methods described herein to a receiver. The receiver may, for example, be a computer, a mobile device, a memory device or the like. The apparatus or system may, for example, comprise a file server for transferring the computer program to the receiver .

In some embodiments, a programmable logic device (for example a field programmable gate array) may be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor in order to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware apparatus.

The above described embodiments are merely illustrative for the principles of the present invention. It is understood that modifications and variations of the arrangements and the details described herein will be apparent to others skilled in the art. It is the intent, therefore, to be limited only by the scope of the impending patent claims and not by the specific details presented by way of description and explanation of the embodiments herein.