WO2002054095A1

WO2002054095A1 - Test environment and a method for testing electronic systems

Info

Publication number: WO2002054095A1
Application number: PCT/DE2001/004768
Authority: WO
Inventors: Matthias Bauer; Renate Henftling; Wolfgang Ecker; Andreas Zinn
Original assignee: Infineon Technologies Ag
Priority date: 2000-12-28
Filing date: 2001-12-16
Publication date: 2002-07-11
Also published as: DE10065508A1

Abstract

The invention relates to a method for testing electronic systems, according to which a test environment (1) is configured in such a way that it generates stimuli, which trigger a reaction in the system (3) to be tested. The test environment (1) has a plurality of test bench elements (11, 12, 13), which emit stimuli via a respective line (9), or receive reaction signals of the system (3). The test bench elements (11, 12, 13) have a respective memory (17) for saving test commands and a generator (19) for generating the stimuli or for evaluating the reaction signal, said generator (19) executing the test commands.

Description

description

Test environment and method for examining electronic systems

The invention relates to a test environment and a method for examining electronic systems or for examining models of the systems, wherein stimuli are generated which are intended to trigger a reaction in the system to be examined.

The term "electronic system" is meant in its broadest meaning and also includes subsystems or individual components such as ASICs.

Electronic systems, subsystems or components are usually verified by simulation. The functionality of the systems is checked using test signals (stimuli), in particular test vectors, and output signals that are compared with expected values. The systems to be examined are usually described in a form that can be synthesized in a hardware description language, such as VHDL, and are therefore available at a register transfer level (RTL). For test purposes, the RTL also switches to the network list level, in which in particular the type of the logic gates, their links and their timing are defined. In addition to the pure simulation of the system by software, the systems are also mapped on hardware for test purposes. In particular, the logic gates are then at least partially concrete. The mapping on hardware brings about a considerable acceleration of the test compared to a pure software solution. So-called hardware or simulation accelerators, FPGA (Field Programmable Gate Array) solutions or finished designs such as ASIC (Application Specific Integrated Circuit) and / or boards are used. Hardware or simulation accelerators are special combinations of hardware components that due to their hardware structure allow special functions to be carried out directly at the hardware level. Nevertheless, the hardware accelerators for controlling their operation are mostly connected to a PC or a computer workstation.

It is desirable to be able to use the same hardware for different systems to be examined. It is also desirable to be able to use the same hardware again.

Due to the increasing complexity of electronic systems and the ever faster implementation of the systems, there is a high need for test environments for test purposes, which make it possible to carry out the increasingly extensive tests in a reasonable time. Furthermore, the test environment should also be able to be used as universally as possible and be reusable in order to keep the effort of the test creation low. In addition to generating the stimuli, it is usually the task of the test environment to monitor and at least partially evaluate the reactions of the system.

Various approaches are known in the prior art for accelerating test environments.

Test environments are mostly pure software solutions, i.e. the environment of the system to be investigated is simulated on a software simulator, the stimuli are generated and, if necessary, the troubleshooting is carried out. Software simulators distributed on different computers can also be used.

It is also known to describe the test environment on RTL in a hardware description language and at least partially implement it in hardware, in particular to map it to a hardware accelerator. A disadvantage of this known solution is that the test environment is largely unstructured internally and therefore usually only for one Test or few similar tests can be used. Both the examination of another system and a changed test strategy require a completely new description of the test environment.

The object of the present invention is to provide a test environment and a method of the type mentioned at the outset in which a rapid and reliable testing of the electronic systems or of models of the systems is possible.

The object is achieved by a test environment with the features of claim 1 and by a method with the features of claim 9. Further developments are the subject of the respective dependent claims.

A main idea of the invention is to provide a plurality of test bench elements, each of which has one or more connections for outputting the stimuli and / or for inputting a reaction signal from the system. At least one of the test bench elements generates stimuli. The test bench elements each have a memory for storing test commands and a generator for generating the stimuli and / or for generating information for evaluating the reaction signal. The generator processes the test commands stored in the memory.

On the process side, this approach corresponds to distributing test commands for examining the system over a plurality of test bench elements and storing them there. The stimuli and / or the information for evaluating the reaction of the system to the stimuli are generated from the test commands in the test bench elements.

Because the test commands can be processed simultaneously in the different test bench elements, the test can be carried out in a significantly shorter time. Time-critical behavior can also be examined. WEI Furthermore, the structure or strategy given enables the test commands to be generated at a high level of abstraction. For example, only a procedure that has already been defined is designated by a test command, for example increasing the value of a stimulus in a ramp-like manner over time. The test bench elements then have the task of generating the stimuli from them with relatively great effort. However, since the test commands can be processed in parallel, and are preferably processed directly by hardware, the stimuli can nevertheless be generated and output in a reasonable time, or the operations corresponding to a test command for evaluating or processing the reaction signals of the system can be carried out quickly enough.

At least one of the test bench elements is preferably implemented as a hardware structure, in particular as an ASIC and / or board and / or FPGA and / or simulation accelerator. In this case, the test of a system can be carried out very quickly. In particular, the test environment can be combined with systems implemented by hardware, the test being able to run approximately in real time. The test environment is no longer, or only insignificantly, a time-consuming factor. Furthermore, with the test environment according to the invention there is a structure which can not only be used once for a specific system to be tested using a specific test strategy , The at least partially, preferably completely, hardware-implemented test environment thus overcomes the disadvantages of known hardware implementations mentioned, while at the same time the advantages of a hardware solution come into play.

Corresponding to test bench elements which emit signals to the system to be examined, conversely one or more test bench elements can also be provided which receive signals from there and store information, in particular test results. These test bench elements can also store test commands that process the processing of data on an abstract level Specify signals. The respective test bench element can thus output information about the test that has already been prepared after the end of a test phase or the entire test. The at least one test bench element which test results are expected is preferably stored and / or the expectation is compared with the actual test result.

Furthermore, the proposed structure of a test environment or the proposed procedure allows special test bench elements to be provided for certain tasks and / or with certain defined interfaces. In one development, at least one of the test bench elements is designed in such a way that signals can be connected via its connection in accordance with a defined protocol or standard, such as e.g. ATM, USB or CAN. In particular, a sufficient number of specialized test bench elements are provided for each protocol in order to be able to test a large number of different electronic systems. Alternatively or additionally, test bench elements can be used which can be programmed in such a way that they can execute one or more of a number of selectable protocols. In particular, at least one of the test bench elements can have a programmable protocol generator which is designed as a component delimited from other hardware components of the test bench element and which permits or executes the transmission of the signals between the system in the test and the test bench element in accordance with the programmed protocol or in accordance with the programmed protocols.

In an expedient embodiment of the test environment, at least one of the test bench elements has a controller which reads out the test commands from the memory and makes them available to the generator. Furthermore, the test environment has a control unit which is connected to the at least one controller and controls the operation of the controller in time. The controller and the generator can be used as separate rate components as well as integrated into a common component.

The control unit, for example a clock generator, preferably has a control connection via which the operation of the system to be examined can be timed. In this case, the control unit can control the entire test so that it is carried out in the shortest possible time. As far as possible, the test bench elements can be relieved of tasks of timing their working methods and the working methods of other test bench elements and / or the system. The test bench elements can also have their own control units. Furthermore, the control unit can cause the system to be examined to be tested as realistically as possible. In particular, the operation of the system can be controlled such that the operation is only continued when the test bench elements are ready to transmit the respective stimuli and / or to receive the reaction signals.

In a development of the test environment according to the invention, the test bench elements are connected to a central processing unit, so that the test commands can be transferred from the processing unit to the test bench elements and / or information about an at least partially carried out test can be transferred from the test bench elements to the processing unit. This allows a central description of the entire test or a central evaluation of the test.

In particular, further test commands can be generated during the examination of the system and can be distributed to the test bench elements after generation. For example, a part of the test that has already been carried out can be evaluated and, depending on the evaluation result, the further course of the test can be defined accordingly. Preferably, several test cases are loaded one after the other into the individual test bench elements and stored there. After processing one test case, the next one is loaded and saved. Each test case has a series of test operations, for example sending a data packet to the system under investigation, or receiving a test result or part of it. In particular, after a specific test operation or sequence of test operations, it may be necessary for the operation of several or all test bench elements to be synchronized or to be coordinated with one another in some other way. The information about when this is the case and / or how to coordinate it can be stored in one or more test bench elements and / or externally, for example in an external control unit. After coordination, the respective test bench element can operate independently again.

The invention will now be described in more detail using exemplary embodiments. Reference is made to the attached drawing. The individual figures in the drawing show:

1 shows a test environment with the system to be examined connected to it,

Fig. 2 shows a procedure when performing a test and

Fig. 3 shows a detail of the timing of a test.

1 shows a test environment 1 with a plurality of test bench elements 11, 12, 13. An electronic system 3 to be tested is connected to the test environment 1. Alternatively, a system model described by software can be connected instead of system 3. In the present case, the system 3 is mapped onto a hardware accelerator. A prototype implementation with FPGA or other configurable elements could also be tested. To the For example, each test bench element could be mapped to an FPGA.

The test bench elements 11, 12, 13 each have an instruction memory 17, a controller 18 connected thereto via a line 6 and a generator 19 connected to the controller 18 via a line 7. The command memory 17 can be, for example, a RAM or another commercially available memory component with a short access time. There are only three test bench elements in the exemplary embodiment. In other embodiments, any other number of test bench elements with the same internal structure or different internal structures can be provided. The command memories 17 are connected to a central processing unit 25 via a bus 5 for the transmission of test commands and for the transmission of evaluation results of the test. The central processing unit 25 is in turn connected via a line 4 to a test description memory 27, in which the test is stored in a defined manner in a suitable description language. The computing unit 25 and the test description memory 27 can be parts of a PC or a workstation, for example.

The test bench elements 11, 12, 13 each have a connection 14, 15, 16 to which the transfer of signals between the system in the test (SIT) 3 and the test bench elements 11, 12 takes place via one or more SIT lines 9 , 13 is possible.

Furthermore, the test environment 1 has a control unit 21 for timing the operation of the test bench elements 11, 12, 13 and for timing the operation of the SIT 3. For this purpose, the control unit 21 is connected to each of the controllers 18 via one or more clock lines 8. The control unit 21 is also connected to the SIT 3 via a control connection 23 of the test environment 1 and one or more clock lines 10. The functioning of test environment 1 and SIT 3 is, for example, as follows: first, the test sequence is described in one or mixed in several suitable description languages, taking into account the interfaces of SIT 3 and the desired behavior of SIT 3. In particular, when describing the test, libraries can be used which contain standardized test sequences for one or more of the test bench elements 11, 12, 13.

After the test has been written and stored in the test description memory 27, the computing unit 25 compiles the test described and generates the test commands for the individual test bench elements 11, 12, 13. It is also determined taking into account the properties of the test bench elements 11, 12, 13, how the test commands are best distributed to the test bench elements 11, 12, 13. The test commands are then correspondingly transferred to the command memory 17 via the bus 5.

The control unit 21 starts the test, for example by driving the SIT 3 and the controllers 18 of the test bench elements 11, 12, 13 via clock signals. Alternatively, the computing unit can also initiate the start of test processing. Thereupon, and also still coordinated by the control unit 21, the controllers 18 read the test commands from the command memories 17 and generate the stimuli for the SIT 3 or generate the information on how reaction signals of the SIT 3 are to be treated. The stimuli or reaction signals are transmitted via the SIT lines 9.

Such a test relates, for example, to a SIT, which is a multiplier. Three test bench elements are used to test the multiplier. The first test bench element outputs a stimulus signal which contains a numerical value which is increased in a ramp-like manner over time. The first argument, which the multi- multiplier multiplied by a second argument and returns the corresponding result.

In a first test phase, the second test bench element supplies a stimulus signal that is constant over time and corresponds to a number, for example 2, and provides the second argument for the multiplier.

The third test bench element is used to evaluate the result, which the multiplier supplies after calculation of the multiplication result. The test command of the third test bench element therefore contains information about the respectively expected test result or allows the third test bench element to calculate the expected value. In line with the ramping first argument, the expected value also ramps up.

When testing the multiplier, the test commands can be present, for example, at a high level of abstraction and can be stored in the command memories of the test bench elements. For example, the test command of the first test bench element merely states that a number ramp is to be generated as a stimulus signal starting from the value 0 to a value n with a step size of 1. Due to its structure and / or preprogramming, the first test element already knows in what form the stimulus signal is to be output to the multiplier. Furthermore, the test bench element knows whether it has to output control signals to the multiplier in addition to the actual stimulus signal, for example in order to signal the presence of a new signal.

The test command for the second test bench element can be present at a comparable level of abstraction.

The test command for the third test bench element contains, for example, the same information as the test command for the first test bench element, but with correspondingly adapted ones Starting values and increments, according to the second argument. Furthermore, the test command contains the instruction that the response signals received by the multiplier are to be compared with the expected values. Alternatively, this information can already be contained in the test bench element in a fixed or reprogrammable manner.

2 shows a procedure for a multi-phase test of an electronic system. Three blocks are shown along a time axis labeled "t", each of which corresponds to a test case. Each test case has a plurality of test operations, which in turn are defined by one or more test commands. The first block is labeled "Pl". This stands for a first packet of test instructions issued during a period of one or more

Test bench elements are to be executed. The middle block, labeled "P2", represents a second packet of test instructions to be executed by one or more test bench elements. The right block, which in turn is labeled "PI", stands for the same packet of test instructions as the left block in FIG. 2.

At time ti, the test commands of the package "PI" are loaded into the respective test bench elements. The test sequence defined thereby, that is to say the test case, is then carried out. At time t ₂ , the test results from the relevant test bench elements are transferred to an evaluation unit. Information can also be retrieved from the test bench elements that have not received any results from the system in the test, for example the information that the

Test vectors were generated correctly.

At time t ₃ , the test commands of packet P2 are transferred to the relevant test bench elements. The corresponding test sequence is then carried out. The test result is again called up at time t ₄ , this time the result of the second test sequence. Then at the time Point t ₅ in turn transmits the command packet P1 into the test bench elements and the first test sequence is repeated.

In an alternative exemplary embodiment of the invention, a procedure is supported in which all command packets are first transmitted to the test bench elements, then all partial test sequences are processed and finally the result or results are transmitted to an evaluation unit.

The exemplary embodiment illustrates essential advantages of a test environment with parallel processing of test commands and with the possibility of loading test commands into independently operating components. Test phases can be repeated at any time. Possible reasons for this can be, for example, incorrect test results in a previous test sequence of the same type or the fact that systems can deliver different results even with identical test sequences.

3 illustrates a detail in the timing of a test. Above a time axis labeled "t", two blocks are shown, the extent of which along the time axis corresponds to the duration of a sequence of test operations. The sequence "Cl" is carried out by a first test bench element. It takes less time to execute than a sequence "C2", which is executed by a second test bench element.

The operation of the system in the test is controlled by a clock signal, for example from the control unit 21 in FIG. 1. For example, the SIT reacts to the rising edge of a square-wave signal. At each point in time at which the SIT receives the rising edge of the clock signal, a dash is drawn through the time axis in FIG. 3. The SIT receives a rising edge three times while the sequences C1 and C2 are being processed. For various reasons, the execution of both sequences may have to end is before the next measure begins. However, since the execution of the sequence C2 takes longer, in this exemplary embodiment the timing of the test environment is designed in such a way that the cycle does not end in the time end area of the execution of the sequence C1 but continues until the sequence C2 is processed is.

The described configuration allows electronic systems to be tested realistically when the test environment is busy with the processing of complex or lengthy test commands. This is often the case when there are test commands with a high degree of complexity, ie many individual changes are generated from one command. However, the procedure described above can also be used if the processing of commands is not particularly complex or lengthy, but the operation of the test environment has to be re-coordinated or synchronized, or for example when new test sequences are loaded.

Furthermore, in the period up to the fourth rising

Flank (FIG. 3), the test bench elements are synchronized and / or the operation of the test bench elements is otherwise coordinated. For example, the test bench elements exchange information, for example the information that a sequence of operations in the respective test bench element has ended. A synchronization of the test bench elements can take place, for example, in that a control unit for controlling the time operation of the test bench elements expects a feedback from all involved test bench elements. The feedback states that the

Sequence of test operations has ended. The control unit only outputs the next clock signal, which triggers the continuation of the test operation, when it has received all the feedback.

In particular, such a synchronization occurs repeatedly in the exemplary embodiment according to FIG. 1 for the test bench elements 11, 12, 13 instead. The control unit 21 synchronizes the operation via the clock line 8 and the controller 18.

Alternatively, the synchronization can also take place decentrally, i.e. each test bench element is waiting for the feedback from all other test bench elements. In this case, a control unit is not required for the synchronization.

In summary, the following advantages of the test environment according to the invention and of the method according to the invention are to be emphasized:

- Due to the possible acceleration of the working of the test environment, tests can be carried out approximately at the clock frequency of real electronic systems, in particular at 10 to 50 MHz.

- Test sequences can be repeated at any time.

- In particular by loading new packets of test commands and by using different combinations of test bench elements, different environments of the system can be created in an existing system to be tested. Errors in the system can thus be identified in the test that only occur in certain environments. - Very complex test commands can be generated and processed in parallel in the individual test bench elements. This means that not only can electronic systems that can be implemented in hardware be tested, but also software packages related to hardware systems can be tested. Examples of this are e.g. DSP (digital signal processors), switching systems for telecommunications equipment and higher layers of telecommunications systems, for example according to the UMTS or DECT standard.

- The test environment itself does not depend on whether the system is represented in the test using software and / or hardware. In particular, systems with software and hardware components can be easily tested. MO LΠ

s: rt CQ CD 3 σ <: H CD α

Φ 0 Ω Φ Φ H- Φ φ Ω d

H- tr P 3 Φ ri CD r

CQ 0 l rr fU: rr H- Ω

Φ M H- 3 Φ H ö d Φ! -T

M φ H- 3 Φ C 3 Cb

Tr CD tr Ω CD Φ LQ Φ d

P- Φ! -R 0> rr Φ 3 3

3 Hi 3 rt d d rr Φ rt d = l-h 3 d Φ

Φ M £ 0 ⁾ ≤ LQ s. 3 • -_

3 Φ d Φ Φ Φ LQ Φ CQ rr l-h H- tr H CD Ω

CQ H- Cb CQ d 0- 0 rr t-T 3 φ Φ ω Φ 3 Φ Cb ω H-

Ω 3 LQ 3 Φ N Φ

Φ O - M Φ Cb

Ω tr 3 X 3 3 M lT Φ CQ H- σ 0 ⁾ d H- 0> H-

Φ ^ 0 rr H- 3 (>! -T ri Ω

3 rt 3 rr Φ 3 H- t- α H CQ Φ Φ φ

Φ 0 ⁾ Φ rr 0 ⁾ £ 3 CQ D tQ M Φ 3 H- d 3 M Φ & 0 ⁾ to ι-3 3 M CL O d Φ

Φ LQ φ Φ 0 ⁾ Φ ΓT CD

CQ CQ 3 CQ H- LQ rr Φ <! 3 Φ tr Φ H tr CO Φ 3 Hi, 8 Φ G φ Φ Φ H d d = 3

3 H- 3 H s: 3 t-D

Ω ω Ω Φ Φ LQ H br rt! -T 0 ⁾ 3 rt Φ

Φ H- rr <! d 0 ⁾ CQ

M 3 0 CQ tr d ≤

Φ d Cb ü N 0 ⁾ Hi Φ CQ

3 M H- d ü Ό φ H- Φ ι_ι. LQ Φ Φ

3 Φ φ o> Φ H- rt> tr CD CD 3 Ω l- d Φ Φ rt ** 3-

0> d = CD 3 3 H CG Φ d ü ≤ ex d ^> <: 0 M

CQ 0> 3 Φ x CD - CQ

IQ ^{^} Φ 3 rr rt 3 φ 0 ⁾ M dd Φ Φ

M Q Φ CΩ M 3 0 =

Φ Φ 3 rr Φ & 3

LQ tr H- H- M H- 0 ⁾ 3 rr Φ 3 H 3 M 3 CD Φ

H- Φ φ d Φ CD 3

H-ra CD ω M H

01 Ό et H- Φ Cb <rr H-> τ) 0 CD H- φ

• Φ ri er 3 3 rt Φ ι-i

M 0 Φ d = ^• Ό 1

CQ 1 1 CD 0 1 1 1

Claims

claims

1. Test environment (1) for examining electronic systems or for examining models of the systems, the test environment (1) being designed in such a way that it generates stimuli which are intended to trigger a reaction in the system (3) to be examined, characterized in that the test environment (1) has a plurality of test bench elements (11, 12, 13), each of which has a connection (14,

15, 16) for outputting the stimuli and / or for entering a reaction signal of the system (3), at least one (11) of the test bench elements (11, 12, 13) generating the stimuli, - the test bench elements (11, 12, 13 ) each have: a) a memory (17) for storing test commands, b) a generator (19) for generating the stimuli and / or for generating information for evaluating the reaction signal, the generator (19) storing the data in the memory ( 17) stored test commands processed.

2. Test environment according to claim 1, so that at least one of the test bench elements (11, 12, 13) is designed in such a way that via its connection (14, 15, 16) signals according to a defined protocol or standard, such as, for. B. ATM, USB or CAN, are transmitted.

3. Test environment according to claim 2, characterized in that at least one of the test bench elements (11, 12, 13) has a programmable protocol generator which is designed as a delimited structural unit and which transmits the signals according to one or more programmed

Protocol / s allowed.

4. Test environment according to one of claims 1 to 3, characterized in that at least one of the test bench elements (11, 12, 13) has a controller (18) which reads out the test commands from the memory (17) and is available to the generator (19) and that the test environment (1) further comprises a control unit (21) which is connected to the at least one controller (18) and controls the operation of the controller (18) in time.

5. Test environment according to claim 4, so that the control unit (21) has a control connection (23) via which the operation of the system (3) to be examined can be timed.

6. Test environment according to one of claims 1 to 5, characterized in that the test bench elements (11, 12, 13) are connected to a central processing unit (25), so that the test commands from the processing unit (25) into the test bench elements (11, 12 , 13) are transferable and / or information about an at least partially performed test can be transferred from the test bench elements (11, 12, 13) to the computing unit (25).

7. Test environment according to one of claims 1 to 6, characterized in that at least one of the test bench elements (11, 12, 13) is implemented as a hardware structure, in particular as one or more copies of the group ASIC, board, FPGA and simulation accelerator.

8. Test environment according to claim 7, so that the test bench elements (11, 12, 13) are each formed by a hardware unit, in particular by an ASIC or an FPGA.

9. A method for examining electronic systems or for examining models of the systems, wherein stimuli are generated which are intended to trigger a reaction in the system (3) to be examined, characterized in that test commands for examining the system (3) on a plurality of test bench elements (11, 12, 13) are distributed and stored there, the stimuli and / or information for evaluating the reaction of the system (3) to the stimuli being generated from the test commands in the test bench elements (11, 12, 13).

10. The method according to claim 9, so that the stimuli and / or reaction signals to be transmitted between the test bench elements (11, 12, 13) and the system to be examined (3) and / or reaction signals to be transmitted are at least partially in accordance with a defined protocol or standard, such as, for. B. ATM, USB or CAN, are transmitted.

11. The method according to claim 10, characterized in that at least one of the test bench elements (11, 12, 13) has a programmable protocol generator which is designed as a delimited structural unit and which transmits the stimuli according to one or more programmed protocols and / or receive the response signals accordingly.

12. The method according to any one of claims 9 to 11, characterized in that the operation of the test bench elements (11, 12, 13) is time-coordinated.

13. The method according to any one of claims 9 to 12, wherein the operation of the system (3) to be examined is time-controllable, characterized in that the operation of the system (3) is controlled such that the operation is only continued when the test bench elements (11, 12, 13) are ready to transmit the respective stimuli and / or to receive the reaction signals.

14. The method according to any one of claims 9 to 13, so that at least two of the test bench elements (11, 12, 13) exchange control information and / or synchronization information with one another during the test operation.

15. The method according to any one of claims 9 to 14, that the test commands are generated in a central processing unit (25) and transmitted to the test bench elements (11, 12, 13).

16. The method according to any one of claims 9 to 15, so that additional test commands are generated during the examination of the system (3) and are distributed to the test bench elements (11, 12, 13) after generation.

17. The method according to any one of claims 9 to 16, characterized in that after the execution of a sequence of test operations, one or more new test commands are loaded into at least one of the test bench elements (11, 12, 13) and are to be examined. de system (3) is further tested according to the new test command (s).

18. The method according to any one of claims 9 to 17, characterized in that at least a part of the test commands is organized in blocks each with a plurality of the test commands, the blocks each defining an independent test sequence or an independent part of a test sequence, in particular according to their Completion of test results can be evaluated, and that a plurality of the blocks are loaded into a memory of one of the test bench elements (11, 12, 13) and processed one after the other.