JP2008112243A - Simulation program, and apparatus, method and program for generating the same - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the effect of synchronization functions inserted between instructions on the actual execution time of simulation on a host computer in a simulation program for causing a host CPU to simulate an instruction execution process of an actual CPU in an application program operation environment. <P>SOLUTION: A simulation program generation apparatus comprises a storage means for storing an application program operable on an actual CPU, and a processing means for scheduling instruction execution timings in consideration of instruction execution times according to internal processing instructions and external synchronization instructions of tasks included in the application program to determine free run periods between the completion of execution of one external synchronization instruction and the execution of the next external synchronization instruction, and generating a simulation program such that in each free run period the internal processing instruction and a function for computing the remaining time of the free run period are executed alternately. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a simulator (simulation program) for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program for incorporation into a device, and an apparatus, method, and program for generating such a simulation program About.

  Conventionally, when developing an application program for incorporation into a device, in a cross development environment where a target CPU (also referred to as a “real CPU”) to be developed and a host CPU that performs simulation are different types of CPUs. A method of performing a simulation for verifying the function and timing of an actual CPU is used. In such a simulation, a method is known in which an ISS (Instruction Set Simulator) that performs processing equivalent to that of a real CPU reads an application program and performs processing.

  FIG. 15 is a diagram for explaining a method of developing an application program for device incorporation using ISS. In the development of an embedded application program, an application program source code 501 is created in an embedded application development environment 500 on a general-purpose computer equipped with a host CPU, and the source code 501 is compiled using a cross compiler 502 for an actual CPU. As a result, the binary executable file 503 including the binary code of the application program executable in the real CPU is generated.

  Next, the ISS 510 causes the host CPU to simulate the operation of the real CPU, thereby verifying the operation of the real CPU. Under the control of the ISS 510, the host CPU reads the instructions included in the execution file 503 one by one and simulates the instruction code fetch 504, decode 505, and execution 506 stages in the real CPU. Run the application program.

  By the way, in the simulation using the ISS, the ISS performs a cooperative operation while establishing event synchronization with a simulation model of an external module such as other software or hardware, and proceeds the simulation stably. Here, attention is focused on event synchronization between the ISS and the external module.

FIG. 16 is a diagram illustrating event synchronization between the ISS and an external module. In FIG. 16, the ISS 600 includes a plurality of tasks 601, and each task 601 includes a plurality of instructions. The external module 610 represents a module other than the ISS. The module other than the ISS may be, for example, hardware or a simulation kernel (core part) described in the SystemC language or the like. The System C language is one of C language system level description languages, and is an extension of language usage necessary to describe hardware and systems while maintaining the grammar of the C ₊₊ language. is there.

  The ISS 600 is a cycle accurate type simulation program that executes processing for each instruction unit. As shown in FIG. 16, conventionally, in order to synchronize an event with an external module 610 between instructions in a task 601, a function (hereinafter, referred to as a task 601) that temporarily shifts a task 601 in progress of processing. , “Synchronous function”). As the synchronization function, for example, a Wait function in the SystemC language is applicable. With the function of such a synchronization function, synchronization between modules is established, cooperative operation is possible, and simulation can be performed stably.

  In this way, by inserting a synchronization function for each instruction in the task 601, when there is an unpredictable interrupt request from the external module 610, the task 601 in progress at that time is set in a standby state and the program Can be prevented.

  However, there is not always an interrupt request from the external module 610 at the timing when the synchronization function is inserted. Even if there is no interrupt request, the synchronization function is executed, but in general, the real time required for executing the synchronization function (the real time required for processing by the host CPU. Hereinafter, the time required for the host computer to execute the actual processing is In particular, the real time) is much larger than the real time required to execute the individual instructions included in the task 601, and therefore execution of unnecessary synchronization functions is a cause of increasing the processing time of the host CPU. turn into.

  In general, the ISS has a role as an emulation tool for developing a built-in application program of a CPU or DSP (Digital Signal Processor). There is a big effect in shortening. Therefore, various techniques have been developed in order to speed up the simulation of application programs by ISS.

  Patent Document 1 below discloses a simulation apparatus capable of performing performance verification with an abstraction level enabling cache analysis at high speed using a single verification platform without requiring ISS. The simulation apparatus includes a verification execution processor that executes a verification process, and includes a processor model that simulates the function of the verification target processor included in the verification target system, and functions of peripheral hardware of the verification target processor in the verification target system. The verification target system is simulated by operating a hardware model to be simulated on the verification execution processor.

  According to this simulation apparatus, it is not necessary to use the ISS by simulating the function implemented by the software in the verification target system by the software model operating on the verification execution processor, so that high-speed performance verification is possible. . However, Patent Document 1 does not particularly disclose reducing the influence of the synchronization function inserted between instructions in the simulation program on the simulation time (the real time required for processing by the host CPU).

  Patent Document 2 discloses a simulator device that can perform comprehensive logic verification of software corresponding to various parallel operation timings of system components. The simulator device includes a CPU simulation device for trying a command execution process of a real CPU on a host CPU different from the real CPU, and a system component that operates in parallel in synchronization with the command execution process, Means are provided for changing the parallel operation timing of the system components.

According to this simulator device, the operation timing of system components such as peripheral I / O devices can be arbitrarily changed, so that comprehensive logic verification of software covering various parallel operation timings of system components can be performed. It can be carried out. However, in Patent Document 2, the means for changing the parallel operation timing of the system components refers to the ISS itself, and the synchronization function inserted between instructions in the ISS is the simulation time (the actual processing that the host CPU takes for processing). There is no particular disclosure regarding reducing the effect on time).
JP2004-13227 (page 1-2, FIG. 1) JP 2000-20348 (page 1-2, FIG. 1)

  Therefore, in view of the above points, the present invention provides a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program for embedding a device. The object is to reduce the influence on time (actual time taken by the host CPU for processing).

  In order to solve the above problem, a simulation program generation apparatus according to one aspect of the present invention is a simulation program generation apparatus that generates a simulation program that causes a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program. A storage means for storing an application program operable on a real CPU, an application program read from the storage means, and an internal processing instruction and an external synchronization instruction of a task included in the read application program Based on the instruction execution time, instruction execution timing is scheduled to determine a free run period from the completion of the execution of the external synchronization instruction until the next execution of the external synchronization instruction. A function for obtaining the remaining time of the internal processing instructions and the free-run period and a processing means for generating a simulation program to be executed alternately in the period.

  Here, as the above function, when the remaining time of the free run period is not a positive value, it is determined whether or not there is an interrupt, and if there is an interrupt, the host CPU is controlled to execute the interrupt process, and then the external CPU A function for controlling the host CPU to execute the synchronous command may be used.

  Further, the processing means may generate a simulation program so that the synchronization function is executed in accordance with the execution of the external synchronization instruction. As the synchronization function, the host CPU sets the task processing to a standby state. And a function for controlling the host CPU to activate task processing after a set time has elapsed or when there is a task activation request.

  A simulation program generation method according to one aspect of the present invention is a simulation program generation method for generating a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program. The instruction execution time is taken into account based on the step of reading the application program from the storage means for storing the application program operable in, and the internal processing instruction and external synchronization instruction of the task included in the read application program By executing the instruction execution timing scheduling, a free run period from the completion of the execution of the external synchronization instruction to the next execution of the external synchronization instruction is determined, and the internal processing instruction is executed during the free run period. A function for obtaining the remaining time of the free-run period and generating a simulation program to be executed alternately.

  A simulation program generation program according to one aspect of the present invention is a simulation program generation program that generates a simulation program that causes a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program. The instruction execution time is taken into account based on the procedure for reading the application program from the storage means for storing the application program that can be operated in the system, and the internal processing instruction and the external synchronization instruction of the task included in the read application program. By executing the instruction execution timing scheduling, a free run period from the completion of execution of the external synchronization instruction to the next execution of the external synchronization instruction is determined. A function for obtaining the remaining time of the physical instruction and free-run period to execute a procedure for generating a simulation program to be executed alternately CPU.

  A simulation program according to one aspect of the present invention is a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of the application program, and is included in an application program operable on the real CPU. The procedure for executing the external synchronization instruction of the task being executed and the function for calculating the remaining time of the free run period are alternately executed in the set free run period after the execution of the external synchronization instruction is completed. When the remaining time of the free-run period is not a positive value, determine whether or not there is an interrupt and if there is an interrupt, execute the interrupt processing and then execute the external synchronization instruction to the host CPU. Let it run.

  According to the present invention, by scheduling the instruction execution timing in consideration of the instruction execution time, a free run period from the completion of the execution of the external synchronization instruction to the next execution of the external synchronization instruction is determined, Since the simulation program is generated so that the internal processing instruction and the function for obtaining the remaining time of the free run period are executed alternately during the free run period, the influence of the synchronization function inserted between the instructions on the simulation time Can be reduced.

The best mode for carrying out the present invention will be described below in detail with reference to the drawings. In addition, the same reference number is attached | subjected to the same component and description is abbreviate | omitted.
FIG. 1 is a diagram showing a configuration of a simulation program generation apparatus according to an embodiment of the present invention. The simulation program generation device 1 is composed of a general-purpose computer 2 and an external input / output device 9. The computer 2 includes a CPU 3 as a host CPU, a ROM 4, a RAM 5, a hard disk 6, and an interface (I / F) 7. The CPU 3, ROM 4, etc. are connected to each other via a bus 8.

  The CPU 3 reads the application program stored in the RAM 5 or the hard disk 6 and executes predetermined processing on the read application program, thereby simulating the movement when the application program is operated on the real CPU. A simulation program is generated, and the generated simulation program is stored in the RAM 5 or the hard disk 6 again.

  The external input / output device 9 is connected to an interface (I / F) 7, and includes a keyboard as an input device that gives instructions to the computer 2, a display as a display device that displays the operation status of the computer 2, and the like. Yes. A simulation program generation program that causes the CPU 3 to generate a simulation program may be stored in the hard disk 6 or the RAM 5 in advance.

  In the simulation program generation device 1, the CPU 3 reads the simulation program generation program stored in the hard disk 6 or the ROM 4 via the bus 8 and executes the read simulation program generation program under a predetermined operating system. Generate a simulation program.

FIG. 2 is a diagram showing a program development procedure in one embodiment of the present invention.
As shown in FIG. 2, this program development procedure is executed in an embedded application program development environment 10, a simulation program generation environment 11, and a simulation environment 12 using the SystemC language. In the embedded application program development environment 10, the source code 13 written in the ANSI-C language is compiled by the cross compiler 14, thereby generating an application program execution file 15 that can be executed by the real CPU incorporated in the device. In the present embodiment, a compiler for C33PE, which is a general-purpose CPU, is used as the compiler 14, for example. The ANSI-C language is a C language conforming to ANSI (American Standards Association) standard.

  Based on the application program execution file 15 generated in the embedded application program development environment 10, a simulation program code 16 written in the ANSI-C language is generated in the simulation program generation environment 11. The simulation program code 16 is compiled by the host CPU compiler 17 in the simulation environment 12 to generate a simulation program execution file 18 for simulating the operation of the real CPU on the host CPU.

  FIG. 3 is a flowchart showing the operation of the simulation program generation apparatus according to the embodiment of the present invention. The application program execution file generated in the embedded application program development environment is stored in a storage unit such as a RAM or a hard disk of the simulation program generation device. In step S10, the simulation program generation apparatus reads the application program execution file from the storage unit, analyzes the binary code of the application program execution file in step S11, adds a desired function, and in step S12, reads the ANSI-C language. The simulation program code described in the above is generated.

  Step S11 includes, for example, analyzing the instruction of the application program execution file read in step S10 and reconstructing the instruction code. In step S11, a simplified simulation program code can be generated by reconfiguring the instruction code such as omitting redundant instructions.

  FIG. 4 is a diagram showing a simulation environment in the present embodiment. In the present embodiment, the generated simulation program code is executed in a System C language environment. As shown in FIG. 4, in this simulation environment, there are a simulation program 30, hardware 31, and a simulation kernel 32 as modules. In the present embodiment, the hardware 31 and the simulation kernel 32 are described in the SystemC language.

  Although a plurality of threads (software execution units) exist in the simulation program 30, since thread control is performed in units of tasks, the threads are hereinafter referred to as tasks. Arrows between modules or tasks represent transmission / reception of events. For example, the interrupt interface task 37 of the simulation program 30 controls other tasks in the simulation program 30.

  It is assumed that there are three types of tasks, an execution state, a standby state, and an interrupt state, and all tasks are initially in a standby state. In FIG. 4, when the task 33 is executed, the interrupt interface task 37 transmits an event to the task 33 and activates the task 33. When the task 33 receives the event, the task 33 shifts from the standby state to the execution state. When the task 33 finishes executing, the task 33 sends an event to the interrupt interface task 37 to notify the end of the task 33. At this time, the task 33 shifts from the execution state to the standby state.

  The interrupt interface task 37 that has received the end notification from the task 33 activates the task 34 having the next highest priority after the task 33. The task 34 is activated by transmitting an event to the task 34 as in the case of the task 33.

  The interrupt interface task 37 performs task management by sequentially starting each task based on the priority order of the tasks. Even when an interrupt request is received from the simulation kernel 32 to the simulation program 30, the interrupt interface task 37 receives an interrupt request event and, for example, transmits the event to the interrupt processing task 35 in a standby state and starts it. When receiving the event, the interrupt processing task 35 shifts from the standby state to the execution state and performs interrupt processing.

  In general, since an interrupt processing task has a higher priority than a normal task, the interrupt processing task is executed while processing of the normal task is in progress. When the interrupt processing task is executed while the normal task is in progress, the normal task temporarily shifts from the execution state to the interrupt state. The interrupt processing task shifts from the standby state to the execution state, and interrupt processing is performed. When the interrupt process ends, the normal task shifts from the interrupt state to the execution state and resumes the process.

  Referring to FIG. 2 again, the simulation program code 16 generated in the simulation program generation environment 11 is composed of an instruction group (instruction set) that can be used in the host CPU. In the conventional ISS, in order to establish synchronization with an external module, a Wait function of the System C language is inserted between instructions.

  The Wait function of the SystemC language has a function of synchronizing the entire system, and is a function that puts the corresponding task in a standby state until an input necessary for progressing the process is obtained. Since the Wait function is inserted between the instructions, when an interrupt request event from another module is received, the corresponding task executes the Wait function so that the ISS can execute the external module (software And other modules such as hardware etc.), the simulation can be executed stably.

  However, since there is not always an unpredictable request (such as an interrupt) from the external module at the timing of the Wait function inserted between the instructions of each task, the Wait function does not respond to a request from the external module. It is not always used. However, even in that case, the Wait function is executed, and the task shifts to a standby state. In general, the Wait function used in the SystemC language reaches about 100 times the execution time of an instruction written in the ANSI-C language. Therefore, the time for executing the Wait function wastefully increases the simulation time significantly. Cause.

  Therefore, in the present embodiment, a test_sync function is newly defined using ANSI-C language. As a result, it is possible to remove the Wait function that has been conventionally inserted between the internal processing instructions of each task in the ISS and generate an ANSI-C code in which the test_sync function is inserted as a new simulation program code.

  The instructions used in the simulation program can be roughly divided into internal processing instructions and external synchronization instructions based on the presence or absence of communication with the external module. The internal processing instruction is an instruction that is processed inside the module of the simulation program and does not require synchronous communication with an external module, such as an Add instruction. In other words, an operation between registers such as a CPU corresponds to an internal processing instruction. On the other hand, the external synchronization command corresponds to an input / output command, a memory access command, or the like for transmitting / receiving data to / from an external module. In other words, the external synchronization command is a command for performing synchronous communication. When the external synchronization command is executed, it is necessary to synchronize between the simulation program and the external module.

  Therefore, when the simulation program executes the external synchronization instruction, the Wait function is executed together with it to set the corresponding task in process to the standby state and wait for an event return from the external module. Examples of the external synchronization command include a Write command, an Int command, a Halt command, a Reti command, and the like.

  FIG. 5 is a diagram showing an instruction configuration of tasks scheduled in the present embodiment. Since the internal processing instruction can be scheduled inside the simulation program according to the present embodiment, the timing for transmitting the external synchronization instruction from the simulation program to the external module can be predicted based on the scheduling.

  For example, in FIG. 5, the processing time from point A to point B can be predicted. Therefore, in the period from point A to point B, when there is no interrupt, the external synchronization instruction is not executed, so it can be determined that there is no need to insert a Wait function between the task instructions. That is, the Wait function that has been inserted between instructions in the past can be removed. Here, a period in which no Wait function is inserted between task instructions is defined as a “free-run period”. In the present embodiment, the test_sync function is inserted as a set after the internal processing instruction during the free-run period.

  FIG. 6 is a diagram illustrating an instruction configuration of a task in which the test_sync function is inserted. According to this embodiment, based on the scheduling of the internal processing instructions in the simulation program, the processing time of each internal processing instruction, and the timing of the external synchronization instruction that performs event communication with the external module, the free run period in the task is determined. Can be predicted. Furthermore, a free run period from a specific internal processing instruction to an external synchronization instruction can also be predicted.

  For example, as illustrated in FIG. 6, a case where the simulation program generation device predicts that the free run period from the start of execution of the internal processing instruction A to the end of execution of the test_sync function D is “10” (arbitrary unit) will be described. To do. Here, for the scheduled internal processing instructions A to D, the processing time of the internal processing instruction A (virtual time in simulation) is “1”, and the processing time of the internal processing instruction B (virtual time in simulation) is “ 2 ”, the processing time of the internal processing instruction C (virtual time in simulation) is predicted to be“ 3 ”, and the processing time of the internal processing instruction D (virtual time in simulation) is predicted to be“ 4 ”. Note that the time required to execute the test_sync function is the actual time on the computer. Therefore, the time required for executing the test_sync function is different from the virtual time on the simulation and is distinguished.

  In this case, in the test_sync function A, the free run period A after the completion of the execution of the internal processing instruction A is “9”, which is obtained by subtracting the processing time “1” of the internal processing instruction A from the free run period “10” ( In the present application, this subtraction is referred to as “time-up time update”). In the test_sync function B, the free run period B after the completion of the execution of the internal processing instruction B is “7” obtained by subtracting the processing time “2” of the internal processing instruction B from “9” of the free run period A. Similarly, in the test_sync function C, the free run period C is “4” obtained by subtracting “3” from “7”.

  In the test_sync function D, according to the same calculation, the free run period D becomes “0” obtained by subtracting the processing time “4” of the internal processing instruction D from “4” of the free run period C. This means the end of the free run period. In the test_Sync function D, the free run period is determined to be “time up”.

  Thus, in the test_sync function, when the result of updating the time-up time is “0” (generally, “0” or less), it is determined that the free-run period has timed up. . When the free run period is not “0” (generally, a positive value), it is determined that the free run period is in progress.

  The present invention realizes free-run execution of an instruction by removing an unnecessary Wait function and inserting a test_sync function. Here, the free run execution of the instruction is realized by the test_sync function inserted after the internal processing instruction calculating the remaining time of the free run period.

  FIG. 7 is a flowchart showing a processing flow of the test_sync function. When the test_sync function is executed after the execution of the internal processing instruction, in step S20, the time-up time of the free run period is updated by the test_sync function.

  Next, in step S21, based on the updated time-up time, it is determined whether the process is in the free-run period or whether the free-run period is up. Here, if it is determined that it is during the free run period, the execution of the test_sync function ends, and the process proceeds to the next internal processing instruction.

  If it is determined in step S21 that the free run period has expired (that is, the free run period has ended), the process proceeds to step S22. In step S22, it is determined whether or not there is an interrupt from the external module. If it is determined that there is no interrupt from the external module, the process proceeds to step S23, the host CPU executes the external synchronization instruction and the Wait function, and ends the test_sync function.

  If it is determined in step S22 that there is an interrupt from the external module, an interrupt process is performed in step S24. When the interrupt process ends, the process proceeds to step S23, the host CPU executes the external synchronization instruction and the Wait function, and ends the test_sync function.

  As shown in FIG. 8, when it is determined in step S22 that there is an interrupt from an external module, the priority order of the interrupt may be determined in step S30. In step S30, the priority of the interrupt is determined. If the interrupt priority is lower than that of the task, the process proceeds to step S23 without performing the interrupt process, the external synchronization instruction and the Wait function are executed, and test_sync is executed. Exit the function. On the other hand, if the priority of the interrupt is higher than that of the task, the process proceeds to step S24. After the interrupt process, the external synchronization instruction and the Wait function are executed in step S23, and the test_sync function is terminated.

  When the external module receives an event from the simulation program, it performs a certain process corresponding to the received event, and then returns the event to the simulation program. The host CPU that operates based on the simulation program can predict the time required for the certain processing in advance, and incorporate the predicted time into the Wait function. The Wait function puts the task itself in a standby state for the estimated time specified by the timer. When the estimated time designated by the timer has elapsed, the task starts from the standby state and shifts to the execution state.

  When the task is activated, the internal processing instructions are free-run, with the period required for executing the scheduled internal processing instructions as a free-run period. However, when an interrupt request is received from an external module during the free run period, an interrupt process must be executed in the simulation program for the received interrupt request. Therefore, in this embodiment, in the setting of the Wait function, in addition to specifying the estimated time (set time) as a timer, the task is always activated and placed in the execution state when a task activation request is made. It is possible to specify migration.

  FIG. 9 is a diagram illustrating a program example of the test_sync function. In the program shown in FIG. 9, the test_sync function is defined as test_sync (). In the fifth line of the program, the time run up of the free run period is updated.

  The if statement in the eighth line determines whether or not the free run period has expired. The condition of the if statement on the eighth line is whether the remaining time of the free run period is a positive value based on the result of subtracting the processing time of the internal processing instruction from the free run period. It is determined whether the time is up. That is, the determination in step S21 in FIG. 7 is made. In the if statement on the eighth line, when the remaining time of the free run period is a positive value, the host CPU determines that the process is in the free run period, and ends the test_sync function.

  On the other hand, if the remaining time of the free run period is not a positive value in the if statement in the eighth line, that is, if the free run period has timed up, the host CPU executes the else sentence in the ninth line. In the while statement from the 14th line to the 22nd line, if the priority of the interrupt is low, the host CPU ends the while statement, executes the Wait function on the 28th line, and ends the test_sync function. On the other hand, if the interrupt priority is high, the host CPU executes the interrupt process (V_vec_06 function on the 19th line), then executes the Wait function on the 28th line, and ends the test_sync function.

  10A to 10C are diagrams illustrating an example of a part of a simulation program in which a test_sync function is inserted between internal processing instructions. Of lines 133 to 192 shown in FIGS. 10A to 10C, lines 137, 145, 151, 159, 167, 173, 179, and 179, and In line 187, a test_sync function is inserted.

  Lines 138 to 144, lines 146 to 150, lines 152 to 158, lines 160 to 166, lines 168 to 172, lines 174 to 178, Lines 180 to 186 represent internal processing instructions.

  Here, lines 168 to 172 are examples of internal processing instructions, but “ld.w% r3, 0x16” described in the assembler language in the comment field on line 170 represents the contents of the instruction. Yes. In other words, the internal processing instructions on lines 168 to 172 represent a load instruction “load 0x16 to r3”.

  As a result of the simulation program generation apparatus interpreting such an assembler code, ANSI-C code is generated as reg [3] = 0x96 in the 171st line. It is generally known to speed up a simulation by statically analyzing an assembler instruction and apparently executing the assembler code as ANSI-C code.

  The test_sync function has arguments for a free run period and an instruction processing time. For example, in test_sync (15, 4) on line 167, the argument “15” represents the free run period until the external synchronization instruction, and the argument “4” represents the simulation time required for the processing of the internal processing instruction itself. ing.

  Here, the flow of processing from the 167th line to the 187th line will be described. First, in line 167, test_sync (15, 4) is present, which means that the free-run period until the next external synchronization instruction is “15”. That is, the simulation program generation device predicts the timing at which the simulation program issues an external synchronization command to the external module by scheduling the internal processing command, and sets the free-run period to “15”.

  The argument “4” of test_sync (15, 4) in the 167th line means the processing time of the internal processing instructions from the 160th line to the 166th line. In this test_sync function, it is determined whether or not the process is in a free-run period. Since the free run period is “15” and the processing time of the internal processing instruction (lines 160 to 166) is “4”, the remaining time of the free run period is the difference between “15” and “4”. “11”. That is, it is determined that the current process is in the free-run period, and the next internal processing instruction (lines 168 to 172) is executed.

  In addition, the processing time of the internal processing instructions in the 168th to 172nd lines is “3”. Therefore, in the test_sync function in the 173rd line, the arguments of the free run period are the previous remaining time “11” and the internal processing instruction period “3”. In the test_sync function on line 173, it is determined that the current process is in the free-run period based on “8” which is the difference between “11” and “3”, and the next internal processing instruction (line 174) To line 178) are executed.

  Further, the processing time of the internal processing instructions in the lines 174 to 178 is “3”. Therefore, in the test_sync function in the 179th line, the arguments of the free run period are the previous remaining time “8” and the internal processing instruction period “3”. In the test_sync function on line 179, it is determined that the current process is in the free-run period based on “5” which is the difference between “8” and “3”, and the next internal processing instruction (line 180) To line 186) are executed.

  In addition, the processing time of the internal processing instructions in the 180th to 186th lines is “5”. Therefore, in the test_sync function in the 187th line, the arguments for the free run period are the previous remaining time “5” and the internal processing instruction period “5”. In the test_sync function in the 187th line, it is determined that the free run period has ended based on “0” which is the difference between “5” and “5”.

  Here, according to the processing flow of FIG. 7, it is determined whether or not there is an interrupt from the external module. If there is no interrupt, the host CPU executes the external synchronization instruction and the Wait function after the predicted free-run period has elapsed and ends the test_sync function. If there is an interrupt, the host CPU performs the interrupt process and then the free-run period has elapsed. The later external synchronization instruction and the Wait function are executed to finish the test_sync function.

  Conventionally, the Wait function is executed every time the ISS internal processing instruction is executed. In other words, in the example of the program shown in FIGS. 10A to 10C, the Wait function is executed instead of the test_sync function, thereby responding to the interrupt request from the external module. The actual processing time on the computer of the internal processing instruction described in ANSI-C language is about 20 nanoseconds to 80 nanoseconds, while the actual processing time on the computer of the Wait function of the SystemC language is about 1000 nanoseconds. It is. Therefore, as in the conventional ISS, the insertion of the Wait function after all the internal processing instructions generates the actual execution time on the computer of the useless Wait function, and the actual execution time on the simulation computer. Cause a significant increase.

  In this embodiment, the simulation speed is increased by giving the concept of a free run period to the instruction set of the simulation program. In addition, when the host CPU executes an external synchronization instruction to the external module in the corresponding task of the simulation program, the host CPU executes the Wait function of the SystemC language, puts the corresponding task into a standby state, and does not execute the subsequent processing.

  FIG. 11 is a diagram for explaining a free-run period in the execution of the simulation program. In FIG. 11, the upper part shows the free run period of the task when the external module does not make an interrupt request to the simulation program, and the lower part shows the case when the external module makes an interrupt request to the simulation program. Represents the free run period of the task.

  Point A represents a point where the task executes the Wait function. At point A, the task executes an external synchronization instruction to the external module, and at the same time, puts the task itself in a standby state and stops the subsequent processing. The task starts the task from the standby state and shifts to the execution state after the predicted time (time) has elapsed or when there is a task start request (event). In FIG. 11, a dotted line arrow represents a task standby state, and an arrow represents a task execution state. The Wait function is expressed as Wait (time, event), and the arguments time and event in the Wait function are when either the predicted time (time) has elapsed or a task activation request (event) is specified. The content indicates that the task is activated from a standby state.

  The upper part of FIG. 11 will be described. When the Wait function is executed at the point A, the task is in a standby state until the predicted time (time) elapses as indicated by the dotted arrow. When the predicted time (time) elapses, the task starts at point B, and as shown by the arrow, internal processing is performed until the point of synchronous communication (point C) after the elapse of the scheduled period (free run period). Execute the instruction. At point C, the task executes an external synchronization instruction. Here, a processing unit of an internal processing instruction sequence in which a task starts and free-runs after a predicted time (time) has elapsed is referred to as an “execution unit until synchronization”.

  The lower part of FIG. 11 will be described. The task executes the Wait function at point A. As in the upper stage, the task executes an external synchronization instruction to the external module at point A, and sets the process of the task itself to a standby state and does not proceed with the subsequent processes. The external module receives an event from the simulation program and starts a predetermined process, but transmits an interrupt request to the simulation program at a certain point (interrupt arrival point D). The simulation program that has received the interrupt request starts a task that is in a standby state.

  That is, in the case of the lower stage, it can be said that the free run can be executed after the task starts at the point E corresponding to the processing up to the point D of the interrupt arrival point. The period from the start of the task to the interrupt arrival point D is defined as “execution unit until interrupt”. When the task receives a task activation request (event) after executing the Wait function, the task shortens the free-run period from the “execution unit until synchronization” period to the “execution unit until interrupt” period. In the simulation program, the shortened “execution unit until interrupt” is free-run by the corresponding task, and after processing up to the interrupt arrival point F, interrupt processing requested by an external module is performed.

  As described above, by setting the task start condition in the Wait function of the SystemC language as an OR condition between the time specification and the event specification, it is possible to respond to an interrupt request from an external module while maintaining a free-run execution operation. Can do.

  The execution unit up to the synchronization and the execution unit up to the interrupt are determined by statically scheduling internal processing instructions before execution. However, for example, a case where scheduling cannot be performed statically, such as when a stall due to bus arbitration occurs, that is, a case where dynamic scheduling is necessary is conceivable. In such a case, the simulation program obtains event reception information from the external module by executing the communication protocol macro file with the external module before executing the execution unit until the synchronization or the execution unit until the interrupt. Alternatively, scheduling may be performed dynamically.

  Here, the simulation program is software that processes an instruction set in a cycle-accurate manner, while the SystemC language is software that performs simulation while synchronizing with the outside in response to the occurrence of an event. In this embodiment, rendezvous synchronization known as CSP theory is adopted as a synchronous communication method between modules having such different properties.

  The present invention makes it possible to remove an unnecessary wait function by setting a free-run period. However, even in an environment where softwares of different processing systems are mixed, a simulation program can be obtained by incorporating a rendezvous synchronization method. The simulation speed can be increased while maintaining the cycle accurate processing method.

  FIG. 12 is a diagram for explaining the operation of the simulation program according to the present embodiment. The first column in FIG. 12 represents the module type. In the present embodiment, existing modules are roughly classified into two types: external modules and simulation program modules.

  The second column in FIG. 12 represents the task type. Since the description of the operation does not depend on the task type of the external module, the external module will be described assuming that the module name and the task name are the same name. The simulation program module includes an interrupt interface task, an interrupt task, a first task, and a second task as tasks.

  The third column in FIG. 12 represents the progress of processing in each task. The progress of the process proceeds from left to right, and the hatched portion indicates that the task is in an execution state. The arrows between the tasks represent the transmission / reception of events between tasks, and the direction of the arrows represents the direction of transmission / reception.

  Here, a single circle mark shown in the task progress diagram represents a Wait function that is an instruction of the System C language, and a double circle mark represents a test_sync function for executing a free run.

  In FIG. 12, the operation of the simulation program according to the present embodiment will be described according to the numbers given to the arrows. First, the interrupt interface task transmits an activation request event E1 to the first task, and activates the first task. After starting, the first task executes an external synchronization command, transmits an event E2 to the external module, and executes a Wait function. The first task shifts to a standby state by executing the Wait function.

  The external module executes a predetermined process (execution unit until interruption) in response to the event E2 received from the simulation program (first task). Here, a case where the external module makes an interrupt request to the simulation program will be described. The external module transmits an interrupt request event E3 to the simulation program when the execution unit up to the interrupt is executed.

  The simulation program receives the interrupt request event E3 in the interrupt interface task. After receiving the interrupt request from the external module, the interrupt interface task transmits an activation request event E4 to the first task and activates the first task.

  The first task shifts to the execution state, reschedules the free run period, and executes the execution unit up to the interrupt in the rescheduled free run period (E5). By clearly defining the “execution unit until interrupt” executed in the external module and the “execution unit until interrupt” executed in the first task, the process proceeds between the simulation program and the external module. Can be synchronized.

  The first task free-runs the execution unit up to the interrupt while determining whether the free-run period is up based on test_syncA and test_syncB. When test_syncB recognizes that the free run period has expired, it sends an event E6 to the interrupt interface task. The first task shifts from the execution state to the interrupt state.

  The interrupt interface task activates the interrupt task in order to perform interrupt processing in response to an interrupt request from the external module (E7). The interrupt interface task transmits an activation request event E8 to the interrupt task to activate the interrupt task.

  The interrupt task shifts to the execution state, executes the external synchronization instruction, transmits the event E9 to the external module, and executes the Wait function. The interrupt task shifts to a standby state by executing the Wait function.

  The external module performs predetermined processing (execution unit until synchronization) in the external module for the event E9 received from the simulation program (interrupt task). The external module returns an event E10 to the simulation program (interrupt task) after executing the execution unit until the synchronization.

  On the other hand, the interrupt task in the standby state is activated by the timer included in the interrupt task itself and shifts to the execution state. This timer measures the time when the execution unit until synchronization is predicted. The interrupt task executes the execution unit until the synchronization in the scheduled free run period (E11).

  The interrupt task free-runs the execution unit until the synchronization while determining whether the free-run period is up or not based on test_syncC and test_syncD. When test_syncD recognizes that the free-run period has expired, it sends an event E12 to the interrupt interface task.

  The interrupt interface task returns the process to the first task because the interrupt process for the interrupt request from the external module is completed (E13). The interrupt interface task transmits a start request event E14 to the first task to restart the first task.

  After starting, the first task executes a Wait function to execute an external synchronization instruction, transmits an event E15 to the external module, and then shifts to a standby state. The external module performs a predetermined process (execution unit until synchronization) according to the event E15 received from the simulation program (first task). The external module returns an event E16 to the simulation program (first task) after executing the predetermined process.

  On the other hand, the first task in the standby state is activated by the timer included in the first task itself, and shifts to the execution state. This timer measures the time when the execution unit until the synchronization in the external module is predicted. The first task executes the scheduled free-run period (execution unit until synchronization) (E17).

  The first task free-runs the execution unit until the synchronization while determining whether the free-run period has timed out based on test_syncE and test_syncF. When test_syncF recognizes that the free run period has expired, it sends a task end notification event E18 to the interrupt interface task.

  The interrupt interface task detects the time-up of the first task, and transfers the execution to the second task having the second highest priority after the first task (E19). The interrupt interface task transmits an activation request event E20 to the second task to activate the second task.

  After starting, the second task executes an external synchronization instruction to transmit an event to the external module and executes a Wait function. The second task enters a standby state. The external module performs a predetermined process (execution unit until synchronization) according to the event received from the simulation program (second task). The external module returns an event E22 to the simulation program (second task) after executing the execution unit until the synchronization.

  On the other hand, the second task in the standby state is activated by the timer of the second task itself, and shifts to the execution state. This timer measures the time when the execution unit until synchronization is predicted. The second task executes the scheduled free-run period (execution unit until synchronization) (E23).

  The second task performs free-run execution on the execution unit until the synchronization while determining whether the free-run period has expired based on test_syncG and test_syncH. When test_syncH recognizes that the free run period has expired, it sends a task end notification event E24 to the interrupt interface task.

  The simulation program is generated by the simulation program generation apparatus shown in FIG. 1, but as a necessary element for generating the simulation program in the simulation program generation environment, a command creation file (header file) and an actual CPU device An environment file (cpp file, header file) exists.

  Here, when a simulation program generation instruction is executed by a command operation, the simulation program generation apparatus reads an application program execution file (sa file) generated in the embedded application development environment and generates a simulation program code, thereby performing a simulation. A program source file (cpp file, header file) is generated.

  In the simulation environment, the simulation program source file is merged with the file describing the peripheral circuit of the SystemC language, and the execution environment of the simulation program on the SystemC language is constructed and compiled. Generated. Generation of the simulation program execution file and execution of the simulation program are performed by command operations by the user.

  FIG. 13 is a diagram illustrating a model of a simulation environment in which a simulation program can be executed. In the System C language, TB_source 410 and Ssis_iss 420 are defined as modules in the main function sc_main 400 of the highest hierarchy. The Ssiss_iss 420 includes SC_METHOD 421 and SC_THREAD 422 as processes. SC_METHOD 421 and SC_THREAD 422 are generally known as processes included in the SystemC language.

  TB_source 410 corresponds to the external module in the present embodiment. Ssis_iss 420 corresponds to the simulation program in this embodiment. In this embodiment, a recv_int function is defined in SC_METHOD 421 as a thread for receiving an interrupt to the simulation program. In addition, a function V_vec_01 is defined in SC_THREAD 422 as a thread for executing an interrupt.

When the tb_reset function or the tb_int0 function of the TB_source 410 is executed, synchronization is established by the recv_int function of the Ssiss_iss420 and the event. When receiving the interrupt request or the like, the recv_int function executes the V_vec_01 function or the like as necessary.
In FIG. 13, test_sync (), V_vec_01 () to V_vec_nn (), V_00C00200 (), and V_00C0077E () represent functions linked by execution of the V_vec_01 function.

  In addition to these processes, threads, and linked functions, a simulation program execution environment on the SystemC language is configured by including a general initialization function having an initialization function in process execution.

  FIG. 14 is a diagram illustrating an effect in the execution of the simulation program according to the present embodiment. In FIG. 14, the horizontal axis indicates the execution test pattern of the simulation program, and the vertical axis indicates the execution speed in each execution test. In addition, each test pattern was tested in the following four modes depending on the type of external synchronization with the external module.

The free run mode is a test mode in which no Wait function is executed in the simulation program.
The block unit mode is a test mode in which a Wait function is executed at a branch point where a process branches, a merge point where a branched process joins, and a call point that calls a function in the program processing flow of the simulation program.

The write mode is a test mode in which the Wait function is executed at the timing of executing the Write instruction to the external module in addition to the block unit mode.
The write / read mode is a test mode in which the Wait function is executed at the timing of the Read instruction to the external module in addition to the write mode.
Among the above four types of test modes, the write / read pattern has the largest number of times to execute the Wait function, and is a form close to a simulation program that is actually used.

  As the number of Wait functions inserted into the simulation program increases from the free run mode to the block unit mode, the write mode, and the write / read mode, the execution speed of the simulation program decreases. In the execution test pattern, the number of internal processing instructions such as memory access is changed to form a plurality of execution test patterns.

  As shown in FIG. 14, in each test pattern, in the free-run state, 8 MIPS (Million Instruction Per Second), and the write / read mode with the slowest execution speed, about 0.5 MIPS to 2 MIPS Realized. Since the conventional ISS is about 0.1 MIPS to about 0.5 MIPS in the actual use state and about 1 MIPS even in the state close to the free run, the effect of the present invention becomes clear from FIG.

  In general, a simulation program has a role of emulation software such as an embedded application program and a role of a hardware reference model at the stage of developing a CPU or a DSP. The present invention has the role of the former emulation software. Emulation software is often used repeatedly from the viewpoint of debugging application programs. The present invention achieves the effect of shortening the period of application program development by realizing high-speed simulation programs.

  In the present embodiment, C33PE is used as a real CPU, but other CPUs may be used. For example, other versions of the C33 series, ARM7-TDMI, or the like can be used.

The figure which shows the simulation program production | generation apparatus which concerns on one Embodiment of this invention. The figure which shows the program development procedure in one Embodiment of this invention. The figure which shows operation | movement of the simulation program production | generation apparatus in this embodiment. The figure which shows the simulation environment in this embodiment. The figure which shows the command structure of the task scheduled in this embodiment. The figure which shows the command structure of the task in which the test_sync function was inserted. The figure which shows the processing flow of a test_sync function. The figure which shows the processing flow of the test_sync function including the priority determination of interruption. The figure which shows the example of a program of a test_sync function. The figure which shows the example of a part of simulation program. The figure which shows the example of a part of simulation program. The figure which shows the example of a part of simulation program. The figure for demonstrating a free run period. The figure for demonstrating operation | movement of the simulation program which concerns on this embodiment. The figure which shows the simulation environment which can execute a simulation program. The figure which shows the effect in the simulation program execution which concerns on this embodiment. The figure for demonstrating the method of developing an apparatus built-in program using ISS. The figure which shows the event synchronization of ISS and an external module.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 Simulation program production | generation apparatus, 2 General-purpose computer, 3 CPU, 4 ROM, 5 RAM, 6 Hard disk, 7 Interface, 8 Bus, 9 External input / output device, 10 Embedded application program development environment, 11 Simulation program production environment, 12 Simulation Environment, 13 source code, 14 cross compiler, 15 application program execution file, 16 simulation program code, 17 compiler, 18 simulation program execution file, 30 simulation program, 31 hardware, 32 simulation kernel, 33, 34 threads (task), 35, 36 Interrupt processing task, 37 threads (interrupt Interface task), 400 sc_main, 410 TB_source, 411, 412, 422 SC_THREAD, 421 SC_METHOD

Claims (6)

A simulation program generation device for generating a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program,
Storage means for storing an application program operable on the real CPU;
By reading the application program from the storage means and scheduling the instruction execution timing in consideration of the instruction execution time based on the internal processing instruction and the external synchronization instruction of the task included in the read application program The free run period from the completion of the execution of the external synchronization instruction to the next execution of the external synchronization instruction is determined, and the internal processing instruction and the function for calculating the remaining time of the free run period are alternately executed in the free run period Processing means for generating a simulation program as
A simulation program generating apparatus comprising:   When the remaining time of the free run period is not a positive value, the function determines whether or not there is an interrupt, and if there is an interrupt, the function controls the host CPU to execute the interrupt process. The simulation program generation device according to claim 1, which is a function for controlling the host CPU to execute an external synchronization command.   The processing means generates a simulation program so that a synchronization function is executed in accordance with the execution of an external synchronization instruction, and the synchronization function controls the host CPU so that the task processing is in a standby state. The simulation program generation device according to claim 1, wherein the simulation program generation device is a function that controls the host CPU to start processing of the task after elapse of a set time or when there is a task start request. A simulation program generation method for generating a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program,
Reading an application program from storage means for storing an application program operable on the real CPU;
Execution of the external synchronous instruction is completed by scheduling the instruction execution timing in consideration of the instruction execution time based on the internal processing instruction and external synchronous instruction of the task included in the read application program. A free run period from the start to the next execution of the external synchronization instruction is determined, and a simulation program is generated so that the internal processing instruction and the function for obtaining the remaining time of the free run period are alternately executed in the free run period Steps,
A simulation program generation method comprising: A simulation program generation program for generating a simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program,
A procedure for reading an application program from a storage means for storing an application program operable on the real CPU;
Execution of the external synchronous instruction is completed by scheduling the instruction execution timing in consideration of the instruction execution time based on the internal processing instruction and external synchronous instruction of the task included in the read application program. A free run period from the start to the next execution of the external synchronization instruction is determined, and a simulation program is generated so that the internal processing instruction and the function for obtaining the remaining time of the free run period are alternately executed in the free run period Steps
A simulation program generation program to be executed by the CPU. A simulation program for causing a host CPU to perform a simulation of an instruction execution process of a real CPU in an operating environment of an application program,
A procedure for executing an external synchronization instruction of a task included in an application program operable on the real CPU;
A procedure for alternately executing an internal processing instruction and a function for obtaining a remaining time of a free run period in a set free run period after the execution of the external synchronization instruction is completed;
When the remaining time of the free-run period is not a positive value, determine whether or not there is an interrupt, and if there is an interrupt, execute the interrupt process and then execute the external synchronization instruction.
A simulation program to be executed by the host CPU.