Patent Application
20100186005
This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2009-009873, filed on Jan. 20, 2009, the entire contents of which are incorporated herein by reference.
Various embodiments described herein relate to a computer readable recording medium that stores a verification support program to verify a predetermined application using execution results of a simulation, an information processing apparatus, and a verification support method.
To develop an application operating on a specific OS (Operating System), it has been necessary to consider a hardware environment to cause the OS to operate. When a new hardware macro, such as a 3D accelerator, is added to an existing hardware environment, processing, such as invoking a hardware macro from an application, cannot be performed without preparing a driver corresponding to the hardware macro. Thus, when an application intended to be executed in a hardware environment like one created by adding an optional hardware macro to an existing system is developed, a driver to invoke the added hardware macro needs first to be prepared.
In recent years, an evaluation control program to bridge an application and hardware has been provided as a technology that enables an evaluation of the application on a real machine without waiting for, as described above, development of a hardware macro or a driver. By using such a program, an application can also be evaluated in an earlier stage of system development (Japanese Patent Application Laid-Open No. 2000-293403).
However, an evaluation control program to bridge an application and hardware described above implements hardware to be developed by software using a virtual API (Application Program Interface) on specific hardware that is different from hardware to be developed and caused to actually execute the application. That is, such an evaluation control program performs only a simulation of an application in an alternate hardware environment. Therefore, there remains an issue that it is impossible to obtain high-precision information as a simulation result because a hardware environment that is different from a hardware environment in which the application is actually caused to run is used.
To obtain a high-precision simulation result, as described above with reference to
Moreover, according to conventional development steps illustrated in
An information processing apparatus having a verification support function, includes an execution unit for executing a simulation of an application executed by a system using a virtual machine implementing a hardware environment of the system by software, an acquisition unit for acquiring a simulation model of hardware to be added to the hardware environment and the application having specific code inserted into a location where the hardware to be added is invoked, a detection unit for detecting the location into which the specific code is inserted from the application being executed when the application acquired by the acquisition unit is executed by the execution unit, a control unit for performing the simulation of the application by using information of the simulation model acquired by the acquisition unit in the location where insertion of the specific code is detected by the detection unit by controlling the execution unit and an output unit for outputting a simulation result of the application by the execution unit.
The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the various embodiments, as claimed.
Embodiments of the verification support program, information processing apparatus, and verification support method will be described in detail below with reference to attached drawings. In the verification support program, information processing apparatus, and verification support method, an application including specific code (for example, a predetermined mark distinguishable by a virtual machine) is prepared in a location where processing to invoke hardware (hardware macro) whose driver is not provided is described. Then, the application is simulated by causing the virtual machine to execute the application. The virtual machine performs a simulation of the application in the location where the specific code is detected by using information about a simulation model of the hardware macro. That is, the virtual machine can directly be invoked from the application without using a driver. A concrete configuration of the verification support program, information processing apparatus, and verification support method that enables such an operation will be described below.
First, an overview of verification support processing according to the present embodiment will be provided.
In the verification support processing according to the present embodiment, a virtual machine 110 implementing a hardware environment by software caused to execute the application 120 is provided in the information processing apparatus 100. A simulation of the application 120 is performed by the virtual machine 110, but a hardware environment that can be implemented by the virtual machine 110 is only developed hardware for which a corresponding driver is prepared.
Therefore, in the information processing apparatus 100, a simulation model 130 corresponding to a hardware macro is provided so as to perform a simulation of the application 120 that invokes, for example, a hardware macro for which no driver is provided. Moreover, specific code (for example, shaded portions of the application 120) is inserted into a location where processing to invoke a hardware macro is described in the application 120 simulated by the information processing apparatus 100.
When the application 120 to be verified is read, the virtual machine 110 successively performs a simulation and performs a simulation for a location where specific code is inserted by using information of the simulation model 130. Since the virtual machine 110 normally has no driver prepared for a corresponding hardware macro, it is impossible to execute the application 120 including processing to invoke the hardware macro.
In the information processing apparatus 100, however, the application can seamlessly be performed by switching a simulation by the virtual machine 110 to that using information of the simulation model 130 based on the specific code inserted into the application 120. Thus, in the verification support processing according to the present embodiment, predicted values of performance/power of the application can be obtained by referencing simulation results of the application 120 executed by the virtual machine 110.
A concrete configuration to implement verification support processing according to the present embodiment and operations thereof will successively be described below.
First, the configuration of the virtual machine 110 will be described.
Then, the information processing apparatus 100 is provided with an OS 103 to cause the above virtual machine 110 to operate, a driver 102 corresponding to the hardware environment of the hardware model 110a, and the application 101 executed on the OS 103. While the driver 102 provided here is software to invoke the hardware macro 112 constituting the hardware model 110a, there is no need, as described above, to provide a portion of the hardware macro 112 the corresponding driver 102 of which is not developed.
Next, the procedure for basic operations of the virtual machine 110 will be described. When the application 101 is read, the virtual machine 110 in the above configuration carries out a predetermined operation. A result of this execution is output as a simulation result of operation.
More specifically, the CPU 111 fetches an instruction from the application 101 (operation S311) and executes the fetched instruction (operation S312). Then, the CPU 111 updates a register/memory in accordance with the execution of the instruction (operation S313) and a bus is accessed in accordance with the update processing (operation S314). When the update is complete, the time and power consumption necessary when the same instruction is executed by a real machine are added (operations S315 and S316) before returning to operation S311 to fetch the next instruction. When the time and power consumption are added in operations S315 and S316, predicted values or measured values prepared in advance in accordance with performance of the real machine are added.
Similarly, the hardware macro 112 executes an algorithm in accordance with the description of the application 101 (operation S321) and updates a register/memory in accordance with the executed algorithm (operation S322) before the bus is accessed in accordance with the update processing (operation S323). When the update is complete, here also, the time and power consumption necessary when the same algorithm is executed by the real machine are added (operations S324 and S325) before returning to operation S321 to execute the next algorithm. When the time and power consumption are added in operations S324 and S325, here also, predicted values or measured values prepared in advance in accordance with performance of the real machine are added.
Synchronization control of operations by each of the CPU 111 and the hardware macro 112 described above is exercised by the virtual machine monitor 110b. Therefore, a simulation result through collaboration between the CPU 111 and the hardware macro 112 similar to the real machine can be obtained by acquiring an operation execution result by the virtual machine 110.
Next, the hardware configuration of the information processing apparatus 100 will be described concretely.
Here, the CPU 401 manages overall control of the information processing apparatus 100. The ROM 402 has various programs stored therein, such as a boot program and a verification support program, for implementing the verification support processing according to the present embodiment. The RAM 403 is used as a work area of the CPU 401. The magnetic disk drive 404 controls the update/reference of data on the magnetic disk 405 according to the control of the CPU 401. The magnetic disk 405 stores data written under control of the magnetic disk drive 404. While the magnetic disk 405 is used as a recording medium in the hardware configuration in
The communication I/F 406 is connected to a network (NET) 409 such as a LAN (Local Area Network), a WAN (Wide Area Network), and the Internet via a communication line and connected to other information processing apparatuses 100 and other external apparatuses via the network 409. The communication I/F 406 manages the network 409 and the interface inside and controls input/output of data from external apparatuses. For example, a modem or LAN adapter can be adopted as a configuration example of the communication I/F 406.
The input device 407 accepts input to the information processing apparatus 100 from outside. A keyboard and a mouse can be cited as a concrete example of the input device 407. The application 101 that performs a simulation using the information processing apparatus 100 as illustrated in
A keyboard, which is provided with keys for inputting characters, numbers, and various instructions, is used to input data. The keyboard may be a touch-panel input pad or ten keys. A mouse is used, for example, to move the cursor, to select the range thereof, to move a window, or to change the size thereof. The mouse may be a trackball or joystick if equipped with a similar function as a pointing device.
The output device 408 outputs data distributed in the information processing apparatus 100 or simulation execution results. A display and a printer can be cited as a concrete example of the output device 408.
A display displays data such as documents, images, and functional information including, for example, the cursor, icons, and the toolbox. Further, a CRT, TFT liquid crystal display, or plasma display can be adopted as the display. A printer prints, for example, image data and document data. Further, a laser printer or ink jet printer can be adopted as the printer.
The information processing apparatus 100 according to the present embodiment can perform a simulation of the application 101, as described above, by using the virtual machine 110 (see
First, the procedure for performing a simulation of the application 101 containing the hardware macro 112 for which the driver 102 is not prepared by the information processing apparatus 100 will be described.
As illustrated in
First, the application 501 to be verified has specific code inserted into a readout location of the hardware macro 112 for which the driver 102 is not prepared. Here, a mark using an undefined instruction or an interrupt instruction is embedded as an insertion example of the specific code. The application 501 is a group of code described in a specific programming language and therefore, processing to convert the application 501 into application binaries 511 by a compiler or assembler (operation S510) is necessary to perform a simulation by the virtual machine 110.
The hardware macro specifications 502 set operation specifications of the hardware macro 112 for which the driver 102 is not prepared. Therefore, a C model 521, which is a simulation model of the hardware macro 112, is created by using the hardware macro specifications 502 (operation S520). The created C model 521 is incorporated into the virtual machine 110.
Instructions executed when the application 501 invokes the hardware macro 112 and processing is transferred from the hardware macro 112 to other hardware, and also predicted values of the execution time and power consumption are prepared as the driver parameters 503. These driver parameters 503 are referenced as setting values when the hardware macro 112 is invoked (details will be described later).
In addition to basic operations described with reference to
The hardware macro specifications 502 used to create the C model 521 are also used to produce a real chip 540. In such a case, an RTL (Register Transfer Level) description is first created from the hardware macro specifications 502 (operation S530). Then, the real chip 540 is produced by using a created RTL description/net list (created from the RTL description) 531. Also, precision of a simulation can be checked by comparing performance/power when the produced real chip 540 is caused to execute the application 501 with performance/power predictions obtained from simulation results by the virtual machine 110.
Next, the functional configuration of the virtual machine 110 implemented by the information processing apparatus 100 will be described.
The acquisition unit 601 has a function to acquire a simulation model of hardware to be added to an existing hardware environment and the application binaries 511 to make the application 501 to be verified execute. A simulation model of hardware to be added to the hardware environment acquired by the acquisition unit 601 is, for example, the C model 521 of the added hardware macro 112. The application binaries 511 are generated, as described above, by converting the application 501 and thus, has a mark inserted into a location in which invocation processing of the hardware macro 112 is performed. The acquired application binaries 511 are temporarily stored in a storage area such as the RAM 403 or the magnetic disk 405.
The execution unit 602 has a function to perform a simulation of the application 501 to be verified by executing the application binaries 511 using the virtual machine 110. A simulation normally means performing an operation of the CPU 111 or the hardware macro 112, as described with reference to
The detection unit 603 has a function to detect a location into which specific code (for example, a mark as described above) is inserted from among the application binaries 511 being executed after execution of the application binaries 511 is started by the execution unit 602.
The control unit 604 controls execution of the application binaries 511 by the execution unit 602 in accordance with detection of a mark by the detection unit 603. More specifically, the application binaries 511 are executed using information of the C model 521 acquired by the acquisition unit 601 in a location detected as having a mark inserted thereinto. That is, the control unit 604 controls the execution unit 602 so that simulation information provided as the C model 521 is used during execution of an operation of the CPU 111 or the hardware macro 112 described with reference to
The control unit 604 can also control whether or not to use information of the C model 521 during execution of a simulation of the application 501 by the execution unit 602 or presence/absence of the start and end of execution of a simulation using information of the C model 521 in accordance with the command set in a mark detected by the detection unit 603.
The output unit 605 outputs a simulation result of the application 501 by the execution unit 602, that is, an execution result of the application binaries 511. The form of output of such a result includes, for example, the display in a display provided as the output device 408, print output to a printer, and transmission to an external apparatus by the communication I/F 406. Such a result may also be stored in a storage area, such as the RAM 403 and the magnetic disk 405.
When a simulation using information of the C model 521 is performed by the virtual machine 110, as described with reference to
Next, the procedure for performing a simulation in the virtual machine 110 having the above configuration will be described.
Therefore, in the virtual machine 110, the target whose processing is controlled is switched between the CPU (model) 111 and the hardware macro (model) 112 in accordance with a description of the application being executed. At operations S701 and S702, a normal simulation is performed and thus, processing is performed by the CPU 111. Then, processing at operations S703 to S705 after the hardware macro 112 being invoked is performed by the hardware macro 112. Operation S706 at which the normal simulation returns after the simulation by the hardware macro 112 is completed is processed by the CPU 111 again.
A sequence of processes illustrated in
The configuration 720 illustrates a configuration in which when the driver 102 or the OS 103 whose execution is assumed in the virtual machine 110 actually invokes the hardware macro 112 in the application 501, a sequence of execution instructions whose execution is assumed before or after invocation processing, the execution time/power consumption values and the like are stored as the driver parameters 503.
In the process 730, processing to perform a simulation based on code of the driver 102 and the OS 103 by referencing the driver parameters 503 provided as the configuration 720 after the control target of the virtual machine 110 being switched to the hardware macro 112 by the process 710 (operation S703), to invoke the C model 521 by the hardware macro 112 (operation S704), and to return the control target of the simulation to the CPU 111 by performing a simulation based on the code of the driver 102 and the OS 103 after the invocation of the C model 521 being completed (operation S705) are performed. The virtual machine 110 can restore the normal simulation by switching the control target of the simulation back to the CPU 111 (operation S706).
Here,
Process 710 (Mark Insertion into the Application)
Next, the process 710 will be described in detail. In the application 501 illustrated in
Processing content of the description example 900 in
After parameters are set, the control target of the virtual machine 110 is switched using a mark 2 as a trigger and then, a driver simulation by the hardware macro 112 is performed. After the driver simulation by the virtual machine 110 is completed, original parameters switched by using the mark 1 as a trigger are received and reset to the virtual machine 110. Then, performance/power observations that were performed by the CPU 111 of the virtual machine 110 are restarted by using a mark 3 as a trigger. Both the CPU 111 and the hardware macro 112 of the virtual machine 110 stop performance/power observations when parameters are set between the mark 1 and the mark 2 and when parameters are received between the end of driver simulation and the mark 3.
Insertion of each mark can be implemented by techniques described below. For #pragma inside call_hw, for example, the CPU 111 of the virtual machine 110 embeds code to be an undefined instruction and a simulation result concerning an undefined exception accompanying execution thereof can be captured by the virtual machine 110. Or, an unused software interrupt (SWI) may be embedded in call_hw so that a simulation result of an interrupt accompanying execution thereof can be captured by the virtual machine 110. Further, an instruction break held by the CPU 111 of the virtual machine 110 may be set in a specific location of call_hw so that a simulation result using the instruction break as a trigger can be captured by the virtual machine 110.
Next, the configuration 720 will be described in detail. The configuration 720 is a configuration of the driver parameters 503 and each parameter value stored in the driver parameters 503 is obtained by techniques described below. First, parameters related to execution time/power information are obtained by causing the virtual machine 110 to perform a driver similar to the driver 102 corresponding to the hardware macro 112 to use execution time/power information during execution. Instead of using a similar driver, parameters concerning execution time/power information may manually be stored based on experience of the verifier. Parameters to be set when a simulation of the hardware macro 112 is performed are stored by separately acquiring them from information of the C model 521.
In addition, the execution time and power information value assumed based on preprocessing/post-processing during execution of a simulation of the hardware macro 112 by adjusting to processing content of the assumed or targeted driver 102 may be generated and stored as parameters.
Lastly, the process 730 will be described in detail. In the process 730, a simulation by the virtual machine 110 is performed. Here,
When the processing at operation S1201 is completed, the C model 521 of the hardware macro 112 is subsequently invoked and performed (operation S1202). When the processing at operation S1202 is completed, the virtual machine 110 performs a simulation of a post-processing unit (operation S1203). In the processing at operation S1203, the execution time of the simulation and power consumption value of the post-processing unit are adjusted (added) based on performance/power information of the post-processing unit stored in the driver parameters 503.
In this manner, the virtual machine 110 can perform a simulation using the C model 521 in correct processing locations by extracting marks. Further, correct simulation results can be obtained by referencing parameter values stored in the driver parameters 503.
(Development Operations when Verification Support Processing According to the Present Embodiment is Applied)
Here,
Moreover, an application can be verified simultaneously with development of a hardware macro and a driver corresponding to the hardware macro. Therefore, feedback of verification results can be given to development of a hardware macro and a driver. Simulation results of an application can also be obtained in an earlier stage of a hardware macro development process or driver development process and therefore, feedback of performance evaluation can be given to hardware.
According to the present embodiment, as described above, the virtual machine 110 switches to execution content of any one of a normal simulation and a simulation using the C model 521 in accordance with a mark detected from the application 501. By performing a simulation using the C model 521 in this manner, invocation processing of the hardware macro 112 that can originally be performed only via the driver 102 can be made to perform as if the hardware macro 112 were invoked via the driver 102.
Thus, in the present embodiment, an application can be made to operate with a hardware macro included by using the virtual machine 110 even in an early stage of development operations in which a driver has not yet been developed. Therefore, performance/power can be measured/predicted at a system level of application without waiting for the development of a hardware macro so that a high-precision verification environment can be provided.
Verification support processing according to the present embodiment is not limited to implementation as the above information processing apparatus 100 and is applicable to, for example, hardware for specific applications or low-power tools that estimate performance/power of a multi-core system.
The verification support method described in the present embodiment can be implemented by executing a program prepared in advance on a computer such as a personal computer or workstation. The program is recorded in a computer readable recording medium such as a hard disk, flexible disk, CD-ROM, MO, and DVD and executed by being read by the computer from the recording medium. The program may also be a medium that can be delivered via a network such as the Internet.
All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiment(s) of the present inventions have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2009-009873 | Jan 2009 | JP | national |
