JPH08212103A - Test data preparing method for multithread processor - Google Patents

Abstract

PURPOSE: To prepare test data for multithread processor verification on the execution environment of a single thread processor. CONSTITUTION: First of all, a shared memory area is damped in a shared area initial value file (step 11a) and next, after local memory areas are successively allocated to respective threads (step 13), the local memory areas are damped in local area initial value files (step 12a). After threads are executed, the local memory areas are damped in local area expected value files again (step 12b) and when the instruction codes of all the threading is completely executed, the shared memory area is damped in a shared area expected value file (step 11b). Thus, exactness in the verification of a multithread processor is improved and time for verification can be shortened as well.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multi-thread processor LSI for executing a plurality of instructions in an independent instruction stream in parallel.
The present invention relates to a test data creation method for a multi-thread processor used when designing and verifying.

[0002]

2. Description of the Related Art Recently, a large-scale microprocessor LS has been used.
I has been developed, and its verification work requires a great deal of cost. Conventionally, a test program for verifying a microprocessor has been manually created by using an assembler language (or directly in a machine language). It is also necessary to manually prepare the initial value data for operating the test program. What is more difficult is that the result data after operating the test program using the initial value data, that is, the expected value data must also be manually created, which is very expensive in terms of creation time and accuracy. Was required.

On the other hand, the developed microprocessor LS
The scale and complexity of I have been bloated, and it has become too late to create test programs by hand. By using an instruction level simulator (simulator relating to the instruction set) created for software development in parallel with LSI development, automation has been achieved for creation of expected value data. In particular, when developing a compatible processor for an existing instruction set, a program development environment such as a compiler is already in place, and a large-scale practical program written in a high-level language can be used as a test program at the time of LSI verification. It is also possible to use.

Furthermore, if software functions capable of controlling program execution, such as dumping of data in a memory area (extrusion of data) and execution trace (recording how each command is executed), are provided, the actual machine can be used. By executing the test program above, it is possible to create expected value data more easily and at higher speed than in the case of using the instruction level simulator.

[0005]

However, the processor verification method as described above is possible only when the architecture similar to the existing architecture is followed. Since the processor with the newly developed architecture has no software-like assets, there is a problem in that the verification work requires a great deal of cost as in the initial case.

The processor targeted by the test data generation method of the present invention has an instruction set architecture compatible with the existing instruction set, and the instruction execution system is disclosed in, for example, Japanese Patent Laid-Open No. 3-134882. It adopts the architecture disclosed in. Japanese Patent Laid-Open No. 3-1
The processor disclosed in 34882 discloses a program
It has a plurality of counters and executes independent instruction streams (called threads) which are sequence-controlled by the respective program counters in parallel.

However, the processor developed so far is intended for execution of a single thread, and there is no processor intended for multithread execution as disclosed in Japanese Patent Laid-Open No. 3-134882. It is difficult to verify a multi-threaded processor efficiently as in the case of a single-threaded processor without the software environment in place. I haven't seen any reports on test methods.

The present invention has been made in view of such conventional problems, and automatically creates test data for multi-thread processor verification in an execution environment of a single-thread processor, Multithreaded processor test that improves accuracy of verification work and shortens verification work time.
The purpose is to realize the data creation method.

Further, the present invention has the ability to use a program at the time of creating test data, which is executed in the environment of a single-thread processor, for verification as it is on a functional simulator (or logic simulator) of a multi-thread processor. Test multi-threaded processor with
The purpose is to realize the data creation method.

[0010]

According to the invention of claim 1 of the present application, a plurality of originally independent program segments are linked and executed as one program on an actual machine, and initial value data and expected value data for testing are executed. A method for creating test data for a multi-threaded processor, in which the shared memory area is first dumped to a shared area initial value file before execution of all program segments, and then for each of the program segments. Allocate the local memory areas so that they do not overlap each other, dump the data of the local memory areas to the local area initial value file in sequence for each program segment, execute the multiple program segments linked on the actual machine, Virtual multithreading using shared area initial value file and local area initial value file After the processor is executed and the program segment is executed, the data in the local memory area is dumped again to the local area expected value file, and finally the shared memory area is expected to be the shared area when the execution of all program segments is completed. It is characterized in that an expected value file obtained on a real machine and an execution result file obtained by a virtual multi-thread processor are collated with each other by dumping to a value file.

According to the second aspect of the present invention, the memory reference address during execution of each program segment is traced and recorded in each trace file, and the result of the memory dump in each local area initial value file is recorded. In contrast, the contents of memory cells at addresses not recorded in the trace file are flushed to update the local area initial value file, and the trace file is added to the memory dump result in each local area expected value file. The local area expected value file is updated by flushing the contents of the memory cell of the address not recorded in.

According to a third aspect of the present invention, a variable in a local memory area is set before the first program segment is executed, and the value of the variable is checked when the execution of each program segment is completed. , If set, dump the local memory area to the local area expected value file,
The feature is that a stop instruction is executed if it is flushed.

[0013]

According to the invention of claim 1 of the present application having such a characteristic, the local memory areas are allocated to the respective program segments so that they do not overlap each other, and then the program segments are allocated. The local memory area is dumped, executed, and the local memory area is redumped in sequence for each of the above. Therefore, when executing each program segment, the contents of the memory area before and after the execution of each program segment are recorded and saved without overlapping memory accesses to each other's local memory areas. Before executing all the program segments, the shared memory area is first dumped, and the shared memory area is linked to a plurality of originally independent program segments and executed as one program on the actual machine. Also, a virtual multithread processor program is executed using the shared area initial value file and the local area initial value file. All programs
Since the shared memory area is dumped again when the execution of the segment is completed, the contents of the memory area at the start and end of execution of all program segments are recorded and saved. Next, the expected value file obtained on the actual machine and the execution result file obtained by the virtual multi-thread processor are compared.

According to the second aspect of the present invention, the memory reference address during execution of each program segment is traced and recorded in each trace file.
Also, trace the memory dump result in the local area.
Update the dump result by flushing the memory contents of the address not recorded in the file. This causes the contents of the memory that were not referenced during execution to be flushed, leaving only the contents of the referenced memory cells.

Further, according to the invention of claim 3 of the present application, a variable in a certain local memory area is set before the first program segment is executed, and when the execution of each program segment is completed, that variable is set. Examine the value of the variable.
Then, if it is set, the data in the local memory area is dumped to the local area expected value file, and if it is flushed, the stop instruction is executed. Therefore, when the test data is created, a dump is performed if the value of the variable is set, and at the time of verification, the stop instruction is executed if the value of the variable is flushed.

[0016]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a test data creating method for a multi-thread processor according to the present invention will be described below with reference to the drawings. Figure 2 shows the test in this example.
It is a hierarchy figure which shows a data creation environment. In FIG. 2, a workstation (WS) 21, which is hardware, is a processor that operates under an operating system (OS) 22. Test data creation tool 23, V
The erilog simulator 24, the multi-thread processor 25 described in Verilog, the test program (executable format) 26a, and the test program (the format converted for Verilog) 26b operate on the OS 22, respectively. .

In general, the WS 21 has its hardware managed by basic software called an OS 22, on which various application programs are executed. In this example, the multithread to be developed
The instruction set of the processor is assumed to be the same as that of WS21, and the multi-threaded processor is a hardware description language Verilog (US Ca
ndens Design Sstems).

The test program 26a is written in a high level language or an assembler language and is translated into an executable form by a compiler or an assembler. This is executed under the control of the test data creation tool 23. When using UNIX as the OS 22, for example,
The test program 26a of the parent process is executed as its child process, and the test data creation tool 23 is UN
Test using the IX ptrace system call
The execution of the program 26a can be controlled. With this mechanism, the execution of the test program 26a is traced and recorded in a trace file or a memory dump is performed.

On the other hand, the multi-thread processor 25 described in Verilog can virtually realize the function of the multi-thread processor by the Verilog simulator 24. The test program 26a is obtained by converting the instruction code portion of the test program 26a into a data format that can be input to the Verilog simulator 24.
6b. If the result of executing the test program 26b by the virtual multi-thread processor 25 on the Verilog simulator 24 and the execution result of the test program 26a match, the Verilog description of the multi-thread processor 25 is correct. .

FIG. 1 is a flow chart of the test data creating method in this embodiment. In FIG. 1, the processing of steps 11a, 11b, 12a, 12b, 15a, 15b is performed by the test data creation tool 23, and the other steps 13, 14, 16a,
The processes of 16b and 16c are incorporated in the test program 26a.

FIG. 3 schematically shows the flow of test program execution in this embodiment. In FIG. 3, the shared area initial value file 3 is used as the initial value file.
1, a local area initial value file 32 for thread 1 and a local area initial value file 33 for thread 2 are provided.
Shared area expected value file 3 as expected value file
4, a local area expected value file 35 for thread 1 and a local area expected value file 36 for thread 2 are provided.
Further, as execution result files, a shared area execution result file 37, a local area execution result file 38 of thread 1,
A local area execution result file 39 for thread 2 is provided. For the sake of simplicity, two threads are executed in parallel here, but it is obvious that the number of threads can be extended.

A plurality of program segments executed as threads are linked at the time of compilation, and are sequentially executed as one program 26a on the WS 21. At this time, steps 13, 16a, 16b, 16 in FIG.
The routine in charge of the processing of c is linked together as a library. First, immediately before the execution of the thread 1 is started, the data in the shared memory area of the test program 26a is dumped to the shared area initial value file 31 (processing of step 11a). Next, the local memory area used by the thread 1 is allocated (processing of step 13).

The shared data memory areas used by the threads are allocated at the time of linking, so that it is not necessary to consider it here. However, since the memory area for the local data is dynamically allocated at the time of program execution, the thread's program segment is allocated. Before executing, it is necessary to reallocate the memory area of the local data so that the threads do not overlap each other. This allocation method will be described later.

After allocating the local memory area to the thread 1, the data of the allocated local memory area is dumped to the local area initial value file 32 (processing of step 12a). Actually, as the execution environment information local to the thread 1, it is necessary to dump the contents of the register other than the local memory area, but the description is omitted here. Then, the execution of the thread 1 is started (step 14), and the program segment of the thread 1 is executed. Immediately after the execution of the thread 1, the data in the local memory area is again dumped to the local area expected value file 35 (processing of step 12b).

Next, the same process is performed on the thread 2 to obtain the local area initial value file 33 and the local area expected value file 36. Further, when the program segment of the thread 2 has been executed, the data in the shared memory area is dumped to the shared area expected value file 34 (processing of step 11b).

On the virtual multi-thread processor 25 realized by the Verilog simulator 24, the files 31, 32 generated as described above,
Create an initial image in memory from 33, and thread 1
And thread 2 run in parallel. At the end of the simulation (execution), the data in the shared memory area is executed in the shared area execution result file 37, the data in the local memory area of thread 1 is executed in the local area execution result file 38, and the data in the local memory area of thread 2 is executed in the local area. The result files 39 are dumped respectively. And expected value file 3
The Verilog description of the multi-thread processor 25 is verified by comparing 4, 35 and 36 with the execution result files 37, 38 and 39, respectively.

Next, step 13 of allocating the local memory area will be described. In most high-level languages, the data area is divided into a shared area and a local area. The shared area is allocated at compile time, while the local area is allocated at run time and is also called the stack area. The stack area is an area for storing data which is generally used only in a subroutine, and the size of the used area also changes with the passage of time of program execution.

Since the data in this area is generally addressed by the relative address from the stack pointer or the frame pointer held in the processor, the stack pointer ( Alternatively, the stack area is allocated by rewriting the value of the frame pointer). This is shown in FIG. In FIG. 4, the memory space 41a of the thread 1 has a shared memory area 41b and a local memory area 41c. Memory space 42a of thread 2
Has a shared memory area 42b and a local memory area 42c. Memory space 43 of test program 26a
a is the local memory area 41c of the thread 1 in order from the top,
Local memory area 42c of thread 2, shared memory area 42b of thread 2, shared memory area 41b of thread 1
have.

Generally, the local memory area is not initialized before program execution. Therefore, the garbage data on the memory is also dumped to the local area initial value file and the local area expected value file. Since this becomes an obstacle when comparing the local area expected value file and the local area execution result file, the address of the data accessed during the execution is traced during the execution of the thread (processing of step 14). . Based on this trace result, only the data of the address actually referred to by the data in the local area initial value file or the local area expected value file is left, and the contents of all unreferenced addresses are flushed to 0. By doing so, the obstacle at the time of comparison with the local area execution result file is removed.

As described above, according to this embodiment, prior to the execution of all the program segments, the data in the shared memory area is first dumped to the shared area initial value file, and then the program segments are respectively processed. Allocate local memory areas so that they do not overlap each other. And after this, for each of the program segments,
The data in the local memory area is dumped to the local area initial value file and the program segment is executed. Then, the data in the local memory area is again dumped to the local area expected value file, and finally, when the execution of all program segments is finished, the data in the shared memory area is dumped to the shared area expected value file. Automatically multi-threaded on a single-threaded processor execution environment
Test data can be created for processor verification.

Finally, a trick regarding thread termination will be described. First, the variable flag on the local memory area is first set to 1 (processing of step 16a). Each thread should not reference this variable. Since the value of the variable flag remains 1 when the test data is created, the control always flows to the step 12b side in the determination in step 16b. However, due to the update of the local area initial value file based on the trace result, the value of the variable flag is flushed to 0 during the Verilog simulation. Therefore, in the determination in step 16b, control always flows to the side of step 16c, and when each thread finishes executing the program segment to be executed, it executes a stop instruction and stops. The same process can be performed by having the variable flag in the shared memory area, but in this case, the register is used to refer to the variable flag, which has a slight influence on the simulation.

As described above, according to the present embodiment, variables are set in a certain local memory area before the first program segment is executed, and the variables are set when the execution of each program segment is completed. A test executed on a single-threaded processor environment by examining the value, dumping the data in the local memory area to the local area expected value file if set, and executing the stop instruction if it is flushed. While using the program at the time of data creation as it is on the function simulator (or logic simulator) of the multi-thread processor, suppress / control the memory update by the thread that has terminated early, and add extra data for verification to the Verilog description of the processor. Correct verification work can be performed without including the description. The present invention is not limited to the above-mentioned embodiment, and various modifications can be made based on the spirit of the present invention.
They are not excluded from the scope of the present invention.

[0033]

As described above, according to the first aspect of the present invention, it is possible to automatically create the test data for verifying the multi-thread processor in the execution environment of the single-thread processor. Therefore, the accuracy of the multi-thread processor verification work can be improved and the verification work time can be shortened.

According to the invention of claim 2 of the present application, in addition to the effects of the above-mentioned invention, when a program is executed in a single-thread processor environment, dust left on the local memory area Data can be removed. Therefore, the contents of the generated local area expected value file are simply compared with the functional simulation (or logic simulation) result of the multi-thread processor, and the operation of the multi-thread processor is checked only by checking whether they match. Confirmation can be done.

According to the invention of claim 3 of the present application, in addition to the effects of the invention described above, in the functional simulation (or logic simulation), when each thread finishes executing its respective program segment, a stop instruction is executed. To be done.
Therefore, even if there is a variation in the execution end time among threads, the threads that finish early do not update the memory, and by comparing the contents of the generated local area expected value file with the simulation results, Multithreaded processor verification can be performed.

[Brief description of drawings]

FIG. 1 is a flowchart of a test data creating method according to an embodiment of the present invention.

FIG. 2 is a software hierarchy diagram of a test data creation environment in the present embodiment.

FIG. 3 is a schematic diagram of test program execution in the present embodiment.

FIG. 4 is a diagram showing a memory space map of a test program in this embodiment.

[Explanation of symbols]

21 workstation 22 operating system 23 test data creation tool 24 Verilog simulator 25 Verilog description of multi-thread processor 26a, 26b test program 31 shared area initial value file 32 local area initial value file 33 thread 1 local of thread 2 Area initial value file 34 Shared area expected value file 35 Local area expected value file of thread 1 36 Local area expected value file of thread 2 37 Shared area execution result file 38 Local area execution result file of thread 1 39 Local area execution of thread 2 Result file 41a Memory space for thread 1 41b Shared memory area for thread 1 41c Local memory area for thread 1 42a Memory space for thread 2 42b Thread 2 Shared memory space of the local memory area 43a test program memory area 42c thread 2

Claims (3)

[Claims] 1. A test data creation method for a multi-thread processor for linking a plurality of originally independent program segments and executing them as one program on an actual machine to create initial value data and expected value data for testing. However, prior to executing all the program segments, the shared memory area is first dumped to the shared area initial value file, and then the local memory areas are allocated to the respective program segments so as not to overlap each other, The data of the local memory area is sequentially dumped to the local area initial value file for each of the above program segments, and a plurality of linked program segments are executed on the actual machine, and the shared area initial value file and local area initial value are Run a virtual multithreaded processor using files, After executing the program segment, the data in the local memory area is dumped to the local area expected value file again, and finally, the shared memory area is changed to the shared area expected value file when the execution of all the program segments is finished. A method for creating test data for a multi-thread processor, which comprises dumping and comparing an expected value file obtained on a real machine with an execution result file obtained by a virtual multi-thread processor. 2. A memory reference address during execution of each program segment is recorded and recorded in each trace file, and the trace is performed for a memory dump result in each local area initial value file. Update the local area initial value file by flushing the memory cell contents of addresses not recorded in the file, and write the trace file to the trace file for each memory dump result in the local area expected value file. 2. The test data creating method for a multi-thread processor according to claim 1, wherein the contents of memory cells at unrecorded addresses are flushed to update the local area expected value file. 3. A variable in a local memory area before the first execution of the program segment is set, and when the execution of each of the program segments is completed, the value of the variable is examined and set. 3. The test data creation method for a multi-thread processor according to claim 2, wherein the local memory area is dumped to a local area expected value file, and the stop instruction is executed if it is flushed.