JP2008276683A - Testing device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a testing device capable of acquiring an accurate profile without correcting a program. <P>SOLUTION: This testing device 1 has a command fetching unit 11 for fetching a command when executing the program, a registration memory 21 for storing an optional bit pattern, a bit comparison mechanism 23 for detecting the consistency of the fetched command with the bit pattern stored in the testing device 21, a control table 22 for registering the detection frequency of the optional bit pattern, and a registration/updating mechanism 24 for registering the execution thereof into the control table 22 or for updating an accumulated execution frequency thereof in the control table 22, when a consistency detecting part detects the consistency. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a test apparatus for performing performance analysis of a software program operating on a microcomputer.

  In the development of an embedded software program, in order to improve the execution performance of the program, first, the program is actually operated and the operation transition of the program is acquired as data (profile data). The development form of analyzing this, recognizing the bottleneck of the program, and performing program modification / performance improvement is spreading. Accordingly, there is an increasing demand for a program operation analysis tool as a tool for assisting such a development flow. Current program behavior analysis tools acquire profile data by the following two methods.

  First, a method for acquiring profile data in software will be described. FIG. 3 is a diagram showing a method of correcting profile and acquiring profile data by software. This system includes a builder / compiler 111 that compiles the embedded program (A) 112 and the profile acquisition program (B) 113, a program execution environment 114 that executes the profile acquisition program (B) 113, and controls this execution. It consists of a debugger 115. The profile data 116 is acquired by executing the program execution environment 114.

  In this method, a profile acquisition program (B) 113 in which a software profile code is inserted into a program is created and executed on a program execution environment 114 such as a target, an emulator, or a simulator, and profile data 16 is acquired.

  Next, a profile data acquisition method using this software shown in FIG. 3 will be described. In profile data acquisition by software, a profile acquisition program (B) 113 of the embedded program (A) 112 is created for the embedded program (A) 112, and this is executed on the target, emulator or simulator. The profile acquisition program (B) 113 is generally generated by specifying a profile data acquisition program generation option during compilation. When the profile data acquisition program generation option is designated, the compiler 111 inserts the profile data acquisition code at the beginning of a function, the beginning of a basic block, or the like. By executing this acquisition code, the cumulative number of executions of a certain function and a certain basic block is stored in the memory of the target or host. By referring to this later using an execution analysis tool or the like, it becomes possible to know the execution transition of the program (A) 112.

  Next, a method for acquiring profile data by hardware will be described. FIG. 4 is a diagram showing a method for obtaining profile data based on trace data obtained by using the trace function of the emulator without correcting the program. This system includes a builder / compiler 121 that compiles the embedded program (A) 122, an emulator 123 that executes the embedded program (A), and a debugger 124 that controls this execution. The trace data 125 acquired from the emulator 123 is analyzed by the analysis tool 126 and profile data 127 is extracted. In this method, the embedded program (A) 122 is executed on the emulator 123, the trace data 125 is acquired by the trace information output function of the emulator 123, and the profile data 127 is acquired based on this data.

  Next, a profile data acquisition method by hardware shown in FIG. 4 will be described. In acquiring hardware profile data, the embedded program (A) 122 itself does not need to be modified. As an environment for executing the program, an emulator 123 capable of acquiring the trace data 125 is prepared, the program is executed on the emulator 123, and the trace data 125 for all executions is acquired. In the trace data 125, a history of all execution instructions (information such as execution address, execution instruction, and access address) from the execution start point to the end point of the program is output. By reading the trace data 125 with the execution analysis tool 126 or the like, it is possible to convert the trace data 125 into the profile data 127 and know the execution transition of the program.

Patent Document 1 discloses a method and an apparatus for characterizing a bottleneck while passively monitoring a processor state in an arbitrary customer workload. In this Patent Document 1, 10 PIPE signals are provided for integer and floating point data paths in the CPU so that the execution state of instructions in the CPU can be observed by a logic analyzer connected to an external pin. Yes. The PIPE signal is a signal such as PIPE9: asserted when any valid data memory reference instruction appears, PIPE8: asserted when any valid control transfer instruction appears, and these signals are observed. Thus, the total number of instructions can be counted, and an analysis by instruction group histogram can be performed.
JP-A-6-89205

  Problems related to the existing profile data acquisition mechanism will be described below. First, in the acquisition method using software shown in FIG. 3, re-compilation must be performed to obtain the profile data acquisition program (B) 113. This is different from the built-in program (A) 112 that is finally built into the product as a program. The profile code used in the profile data acquisition mechanism by software performs processing such as accumulating the number of executions for the identification number table allocated to identify each function and basic block. . Therefore, the built-in program (A) 112 and the profile data acquisition program (B) 113 have the same function calling relationship, but differ in code size and execution speed.

  Since the difference in execution speed affects the execution timing of the program part to which control is transferred asynchronously such as an interrupt, the execution transition itself can be different. Also, when searching for the bottleneck of a program by profile, it is important to know the frequency of instruction execution (instruction level profile), which is a weak point in the architecture of the microcomputer. The granularity of profile data (profile data indicates the size of a section when a section is executed) is below the basic block (a group of instructions executed in a batch without inflow or branch) or the function level There is a problem that it is difficult to reduce the size, and it is therefore difficult to obtain a profile of an instruction level (assembler instruction level).

  Also, with the hardware acquisition method shown in FIG. 4, profile data is basically acquired based on trace data, so it is assumed that the trace data can be acquired completely. Therefore, it cannot be applied to a microcomputer that does not have a mechanism for acquiring trace data. In addition, many of the recent embedded microcomputers operate at a high speed of 100 MHz or more. In such microcomputers, it is a hardware restriction that the trace data corresponding to the execution of the program is sent to the emulator without omission. It is getting difficult. Furthermore, even if there is no omission in the trace data, the amount of trace data that can be saved on the emulator is limited by the size of the trace memory on the emulator, so all trace data from the start to the end of program execution can be saved Such cases are rare. If there is a leak in the trace data, correct profile data cannot be obtained. Even if all trace data can be saved, the total amount of trace data becomes enormous in such a case, so that it takes a very long time to convert to profile information and extract necessary information.

  Further, the technique described in Patent Document 1 has a problem that it is difficult to observe at the detailed assembler 1 instruction level because only analysis at the instruction group (memory reference instruction, control transfer instruction) level can be performed.

  A test apparatus according to the present invention includes an instruction fetch unit that fetches an instruction when a program is executed, a registration memory that stores an arbitrary bit pattern, and a match between the fetched instruction and the bit pattern stored in the registration memory. A coincidence detection unit to be detected, a management table for registering the number of detections of the arbitrary bit pattern, and when the coincidence detection unit detects a coincidence, register the detection in the management table or the cumulative detection number of the management table It has a registration / update part to update.

  In the present invention, it is possible to detect a match or mismatch between an arbitrary bit pattern stored in the registration memory and the fetched instruction, and when it matches, update the cumulative detection number to obtain detailed profile data. Can be done without program modification. Since the program is not modified, the actual program can be made completely equivalent in terms of program execution speed and timing. Here, the test apparatus of the present invention includes a microcomputer alone, a microcomputer and an emulator, or a microcomputer, an emulator and a debugger.

  According to the present invention, it is possible to provide a test apparatus that can acquire accurate profile data without correcting a program.

  Hereinafter, specific embodiments to which the present invention is applied will be described in detail with reference to the drawings. In the present embodiment, an area for storing an arbitrary bit pattern in the microcomputer, a coincidence detection mechanism between the fetched instruction and the stored bit pattern, and an execution address and an execution address of the coincidence are detected. By providing a mechanism to store the cumulative number of executions, it is possible to know the cumulative number of executions of arbitrary code inside the microcomputer, and to obtain profile data accurately with less resources compared to existing mechanisms. is there.

  FIG. 1 is a diagram showing a test system according to the present embodiment. The test system 1 according to the present embodiment includes a CPU 10, an emulator 30, and a host computer 40. The CPU 10 has a profile unit 14. The CPU 10 includes a cache 12, a memory 13, an instruction fetch unit 11 that holds instructions fetched from the memory 13 and the cache 12, and a profile unit 14. This CPU is connected to the emulator 30, and the emulator 30 is controlled by a debugger 41 of the host computer 40. Here, the CPU 10 and the emulator 30 may constitute an ICE (in-circuit emulator) (registered trademark), and the CPU 10 is an actual CPU, and on-chip debugging in which the emulator 30 is built on the actual CPU chip is realized. Also good.

  The profile unit 14 of the CPU 10 has a specific bit pattern registration memory 21 that can hold an arbitrary bit pattern to be profiled. One or a plurality of arbitrary bit patterns can be registered in the specific bit pattern registration memory 21. The profile unit 14 further includes a bit comparison mechanism 23, a profile data registration / update mechanism 24, and a management table 22 for storing profile data.

  In FIG. 1, the management table 22 and the registration / update mechanism 24 are described as being built in the profile unit 14, but some or all of the functions of the profile unit 14 are realized on the emulator 30 or the debugger 41 side. May be.

  Next, the operation according to the present embodiment will be described. FIG. 2 is a flowchart showing the operation according to the present embodiment. The specific bit pattern registration memory 21 included in the profile unit 14 can hold an arbitrary bit pattern to be profiled. Here, the user can set an arbitrary bit pattern via the emulator 30 from the debugger 41 operating on the host computer 40.

  The bit comparison mechanism 23 held by the profile unit 14 is configured such that when the CPU 10 executes a program, the instruction fetch unit 11 fetches from the memory 13 or the cache 12 and the bit pattern held in the specific bit pattern registration memory 21. A match determination is performed (step S1). If they match, the registration / update mechanism 24 registers / updates profile data in the management table 22. The management table 22 holds the “address” of the instruction that matches the bit pattern registered in the specific bit pattern registration memory 21 and the “(cumulative execution) number” of the address. That is, when the fetched instruction code is recognized as a match by the bit comparison mechanism 23, if the “address” held in the program counter (PC) is not registered in the management table 22, the “address” is stored in the management table. “Address” and “Number of times (1 time)” are stored (step S3: No, S4). If the “address” has already been registered in the management table 22, the “number of times” of the corresponding “address” is incremented by 1 (step S3: Yes, S5). In this way, profile data is stored on the management table 22. This profile data is taken into the debugger 41 operating on the host computer 40 from the CPU 10 via the emulator 30. Finally, the debugger 41 holds the specific bit pattern set by itself, the execution location (address) of the specific bit pattern, and the cumulative number of executions of each execution address.

  In the present embodiment, the execution frequency is recorded by comparison with the registered bit pattern when fetching individual instructions in the CPU 10. This eliminates the need for preparations such as the software profile acquisition method, hardware installation such as the hardware profile acquisition method, acquisition of enormous traces, and profile extraction from them, saving resources and shortening. Profile data can be acquired over time.

  For example, if an instruction code always placed at the beginning of a function is specified as a specific bit pattern, the call frequency of each function of the embedded program (A) can be known without reworking the program, and without requiring a large amount of trace memory and analysis time. Is possible. Alternatively, if an instruction whose execution is slow on the architecture of the CPU 10 is specified as the specific bit pattern, the execution address and execution frequency of the instruction can be known on the debugger 41, and a bottleneck analysis in program processing becomes possible.

  In the present embodiment, profile data can be acquired without program modification, and the profile data that can be acquired is completely equivalent in terms of program execution speed / timing when profile acquisition is not performed. be able to. Furthermore, profile data can be acquired in a resource-saving manner and in an extremely short time compared to a profile acquisition method based on an emulator and trace data.

  It should be noted that the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the present invention. For example, as described above, the registration / update function 24 and the management table 22 are described as being built in the profile unit 14 in the CPU 10, but the emulator 30 or the debugger 41 may have these functions. Similarly, the emulator 30 or the debugger 41 may have the function of the profile unit 14.

  Further, in the present embodiment, the specific bit pattern registration memory 21 has been described as registering one bit pattern, but it goes without saying that two or more bit patterns may be registered as necessary. . In that case, the management table 22 may manage each bit pattern and its execution address.

It is a figure which shows the semiconductor device concerning embodiment of this invention. It is a flowchart which shows the operation | movement concerning embodiment of this invention. It is a figure which shows the method of correcting a program and acquiring profile data like software. It is a figure which shows the method of acquiring profile data based on the trace data acquired using the trace function of the emulator, without correcting a program.

Explanation of symbols

11 Instruction fetch unit 12 Cache 13 Memory 14 Profile unit 16 Profile data 21 Specific bit pattern registration memory 22 Management table 23 Bit comparison mechanism 24 Registration / update mechanism 30 Emulator 40 Host computer 41, 115 Debugger 111, 121, 124 Builder / compiler 112 122 Embedded program (A)
113 Profile acquisition program (B)
114 Program execution environment 116, 127 Profile data 123 Emulator 125 Trace data 126 Analysis tool 126 Execution analysis tool

Claims (7)

An instruction fetch unit that fetches instructions during program execution;
A registration memory that stores arbitrary bit patterns;
A match detection unit for detecting a match between the fetched instruction and the bit pattern stored in the registration memory;
A management table for registering the number of detections of the arbitrary bit pattern;
A test apparatus comprising: a registration / updating unit that registers detection in the management table or updates the cumulative number of detections in the management table when the match detection unit detects a match. The management table registers the number of detections of the arbitrary bit pattern and its execution address,
The test apparatus according to claim 1, wherein, when the coincidence is detected, the registration / update unit registers or updates a cumulative execution count and an execution address thereof in the management table. The test apparatus according to claim 1, wherein the arbitrary bit pattern is an instruction code placed at a head of a function. The program has a high speed instruction and a low speed instruction,
The test apparatus according to claim 1, wherein the arbitrary bit pattern is an instruction code indicating the low-speed instruction.   The test apparatus according to claim 1, wherein the test apparatus is a microcomputer. A microcomputer and an emulator connected to the microcomputer;
The microcomputer includes the instruction fetch unit, the registration memory, and the coincidence detection unit, and performs coincidence detection between the fetched instruction and the bit pattern registered in the registration memory,
5. The test apparatus according to claim 1, wherein the emulator includes the management table and the registration / update unit, and updates the management table based on a result of the coincidence detection. . A microcomputer, an emulator connected to the microcomputer, and a debugger for controlling the emulator;
The microcomputer includes the instruction fetch unit, the registration memory, and the coincidence detection unit, and performs coincidence detection between the fetched instruction and the bit pattern registered in the registration memory,
5. The test apparatus according to claim 1, wherein the debugger includes the management table and the registration / update unit, and updates the management table based on a result of the coincidence detection. .

Images