JP2009217531A - Virtual software generator - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a virtual software generator for generating a virtual software which has replaced software mounted to hardware with a source code for generating loads. <P>SOLUTION: A virtual software generator for virtualizing software includes: a module tree configuration creating means for analyzing data input/output among a plurality of modules comprising the software to create a module tree structure; a load table creating means for creating a load table for showing the degree of load for every module; a replacing means for replacing respective modules of the module tree structure with a virtual software module for generating the degree of loads shown by the load table; and a virtual software generating means for generating the module on the basis of the module tree structure in which the module is replaced with the virtual software module. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a virtual software generation device that generates virtual software in which software installed in hardware is replaced with a source code that generates a load.

  In recent years, design technology by simulation at the time of development of a system LSI (Large Scale Integration) has been advanced. This is mainly called ESL (Electronic System Level) technology, and is a technology for designing a system LSI while changing details (abstraction) at each stage.

  At the design stage with a high degree of abstraction, the hardware is shown in block diagram notation, and it is used for studying the overall configuration due to its high-speed operation, or in the design of SoC (System On Chip) with built-in CPU (Central Processing Unit) It is used for the purpose of analyzing the behavior of the entire system while actually running the software on the simulator. On the other hand, in a configuration with a low level of abstraction, the processing speed is slow, but it is used at the stage of detailed hardware design close to the actual hardware logic.

  In conventional ESL tools and software development environments, hardware and software are developed in an independent environment.

  For example, when there is a predetermined architecture such as a PC (Personal Computer), the software can be constructed based on the existing hardware, but it is possible to implement various functions in one system. When developing software on a system LSI in an embedded system, the system LSI, which is the target hardware, is mounted, and then the design is specifically developed and quantitative evaluation is performed as actual software development.

  In addition, when designing a hardware architecture, the conventional ESL tool is used not for RTL (Register Transfer Level) design in which a logic circuit is designed in detail in a hardware description language, but in accordance with the degree of design detail. The simulation is performed with an abstract expression described in a language such as SystemC that expresses only the behavior of the circuit. On the other hand, for software, the developed software was installed and verified.

A hardware simulator that has a microcomputer simulator and a hardware simulator that perform software verification, and uses the hardware verification results verified by the hardware simulator in the microcomputer simulator in a timely manner. A technique for shortening the time until the result is obtained again is known.
JP 2000-35898 A

  In the above conventional simulation method, the microcomputer simulator for software verification and the hardware simulator for hardware verification are linked with each other by an I / F model, and the simulators for verification are different from each other. There is a problem that the system LSI cannot be verified on a hardware simulator.

  For example, the ESL tool is used for assisting the construction by the simulation environment before developing the actual system LSI, and for use in software development on the simulation without preparing the actual chip environment.

  However, even if the ESL environment is improved, if the architecture or topology of the system LSI changes, the target software does not operate normally due to the change, and the software is remodeled before the simulation model There was a work to re-port software.

  Therefore, the object of the present invention is to replace the software implemented in hardware with a module configuration that does not depend on hardware, so that the behavior of the entire system LSI can be evaluated before actual hardware and actual software are developed. To provide a virtual software generation device that generates virtual software.

  To solve the above problems, module tree structure creating means for creating a module tree structure by analyzing data input / output between a plurality of modules constituting the software, and creating a load table indicating the degree of load for each module Load table creating means, replacement means for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table, and the module in which the module is replaced with the virtual software module There is provided a virtual software generation device having virtual software generation means for generating virtual software based on a tree structure.

  As means for solving the above problems, a virtual software generation method for performing processing in the virtual software generation apparatus, or a program for causing a computer to function as each means of the virtual software generation apparatus may be used.

  The disclosed virtual software generation device performs hardware virtualization on a module that generates a degree of processing load predicted to be performed by each module constituting the software, and hardware that is abstracted on a simulation for verifying the hardware. By linking, evaluation and design can be performed as a single system.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  In the ESL tool that verifies the SoC that incorporates the electronic components for realizing various functions and the CPU that controls them, the behavior of each electronic component, CPU, and peripheral components connected to the Soc is abstracted and simulated. Each electronic component and peripheral components are verified. In this embodiment, hardware and software can be verified at the same time by performing verification using an ESL tool using virtual software that is replaced with a load amount of software close to implementation. Hereinafter, the SoC and software for operating the SoC are referred to as a system LSI.

  FIG. 1 is a diagram illustrating a functional configuration example of a simulator apparatus according to an embodiment of the present invention. In FIG. 1, the simulator device 100 mainly includes a virtualization processing unit 10 and an ESL tool 20. The virtualization processing unit 10 is a processing unit that predicts a load amount for each module constituting the software of the system LSI 7 to be evaluated (hereinafter referred to as the evaluation target software 3) and virtualizes using the predicted load amount. , A structure analysis unit 11, a scenario generator 12, a replacement unit 13, a module selection unit 14, and a virtual software generation unit 15.

  The evaluation target software 3 input to the virtualization processing unit 10 is a source code or specification of software to be installed in the system LSI 7. In the case of a specification, it is converted into data described in a specification expression language such as UML (Unified Modeling Language) or a flowchart by other tools.

  The structure analysis unit 11 configures a module for each function of the evaluation target software 3, and creates a module tree structure 11a based on information related to data input / output (I / O traffic described below) between the modules. In addition, the structure analysis unit 11 creates the story data 43 based on various data acquired in the process of creating the module tree structure 11a using the story parser 11b.

  The scenario generator 12 creates a virtual software module 12b using the fragment part 12a. The fragment part 12a is preliminarily provided with an empty scenario draft module that does not have a parameter value relating to the load amount. The fragment part 12a relates to the load amount for each module of the evaluation target software 3 from the scenario generator 12 based on the module tree structure 11a. Given the parameter value, the virtual software module 12b is generated for each module.

  The replacement unit 13 replaces each module with the virtual software module 12b in the module tree structure 11a.

  The virtual software generation unit 16 generates one virtual software 21b composed of software codes based on the replaced module tree structure 15a and outputs the generated virtual software 21b to the ESL model 21 in the ESL tool 20. The virtual software 21b is output as a compiled object code. By incorporating the virtual software 21b into the ESL tool 20, the system LSI 7 can be verified at an early stage.

  The module selection unit 14 is a processing unit that allows a user to select a module. For example, when a part or the whole of the evaluation target software 3 is completed, the user selects a module to be replaced or not replaced with the virtual software module 12b, so that the replacement unit 13 determines the virtual software according to the designated module. The module 12b can be prevented from being replaced. In this case, the source code of the module designated by the evaluation target software 3 is adopted as it is for the module that is not replaced by the virtual software module 12b. An interface may be provided so that a user can designate a module to be replaced or a module not to be replaced individually or in units of groups.

  By providing such a function, the virtual software 21b output from the virtualization processing unit 10 can mix a software entity module and a virtualized module based on the predicted load amount. Therefore, in the present embodiment, the ESL tool 20 can be operated by mixing a software entity module and a virtualized module. It becomes possible to divert and evaluate existing software with a high degree of completeness. Further, the user can designate not to replace a module for which a detailed behavior analysis is to be performed, and a detailed analysis is performed on the functional part of the module that has not been replaced when the simulation is performed on the ESL tool 20. It can be performed.

  On the other hand, the evaluation target hardware 2 is generated as an abstract hardware 21 a that is abstracted by using the ESL tool 20. The ESL model 20 includes the abstract hardware 21a and the virtual software 21b.

  When the user evaluates the ESL model 21 using the ESL tool 20, the user can evaluate the evaluation target hardware 2 and the evaluation target software 3 at the same time. In addition, the evaluation result (feedback) of the entire system LSI 7 can be obtained. Based on this, the evaluation target hardware 2 and the evaluation target software 3 can be reviewed.

  The simulator device 100 that realizes the functions as described above is a computer device and has a hardware configuration shown in FIG. FIG. 2 is a diagram illustrating a hardware configuration example of the simulator apparatus. In FIG. 2, a simulator device 100 is a terminal controlled by a computer, and includes a CPU 31, a memory unit 32, a display unit 33, an output unit 34, an input unit 35, a communication unit 36, and a storage device 37. And a driver 38, and is connected to the system bus B.

  The CPU 31 controls the simulator device 100 according to a program stored in the memory unit 32. The memory unit 32 includes a RAM (Random Access Memory), a ROM (Read-Only Memory), and the like, and is obtained by a program executed by the CPU 31, data necessary for processing by the CPU 31, and processing by the CPU 31. Stored data. Further, a partial area of the memory unit 32 is allocated as a work area used for processing in the CPU 31.

  The display unit 33 displays various information necessary under the control of the CPU 31. The output unit 34 has a printer or the like and is used for outputting various types of information in accordance with instructions from the user. The input unit 35 includes a mouse, a keyboard, and the like, and is used by a user to input various information necessary for the simulator apparatus 100 to perform processing. The communication unit 36 is a device for controlling communication with the simulator device 100 when the simulator device 100 is connected to the simulator device 100 via, for example, the Internet or a LAN (Local Area Network). The storage device 37 is composed of, for example, a hard disk unit, and stores data such as programs for executing various processes.

  A program for generating the virtual software 21b performed by the simulator apparatus 100 is provided to the simulator apparatus 100 by a storage medium 39 such as a CD-ROM (Compact Disc Read-Only Memory). That is, when the storage medium 39 storing the program is set in the driver 38, the driver 38 reads the program from the storage medium 39, and the read program is installed in the storage device 37 via the system bus B. . When the program is activated, the CPU 31 starts its processing according to the program installed in the storage device 37. The medium for storing the program is not limited to a CD-ROM, and any medium that can be read by a computer may be used. The program for realizing the processing according to the present invention may be downloaded via the network by the communication unit 36 and installed in the storage device 37.

  FIG. 3 is a flowchart for explaining processing by the virtualization processing unit. In FIG. 3, the evaluation target software 3 is input to the virtualization processing unit 10 by the user (step S1). The evaluation target software 3 to be input is source code, specifications, and the like. When the evaluation target software 3 is input, the virtualization processing unit 10 determines whether the evaluation target software 3 is a source code or a specification (step S2). The determination may be made based on the file identifier of the evaluation target software 3. If it is determined that the specification is a specification, the virtualization processing unit 10 uses a commonly used tool to convert it into data described in a specification expression language such as UML or a flowchart, and the software module configuration graph list 41 and An I / O traffic list 42 including information related to the module processing cycle is output.

  On the other hand, when determining that the source code is the source code, the structural analysis unit 11 performs preprocessing for executing preprocessing for compilation (step S3), and stacks the execution trace while reading the source code, The amount of computation at the module level such as a function after execution, information indicating what resources the function used (access source and access destination), the amount of data to be accessed, information indicating the module processing cycle, etc. Profiling for report output is performed (step S4), and data relating to the behavior of each module is collected without actually executing a plurality of modules constituting the evaluation target software 3. In the present embodiment, this preprocessing and profiling are referred to as preprofiling, and data is collected without actually executing the behavior of each module. The processing in step 4 for performing pre-profiling is called a pre-profiler.

  Since pre-profiling in this embodiment does not participate in the algorithm of the software itself, the data related to the behavior of the module is information indicating hardware resources assumed to be used by the module. Information generated by pre-profiling is accumulated as an I / O traffic list 42.

  In step S4, the structure analysis unit 11 performs module analysis on the evaluation target software 3 to specify a module using a function name, and a module tree structure associated with I / O traffic between modules. 11a is generated. The module tree structure 11a is represented by a configuration graph list 41 in which function names that specify modules are associated with information related to I / O traffic between modules.

  Further, the structure analysis unit 11 executes a story parser that creates the story data 43 from the configuration graph list 41 and the I / O traffic list 42 using the list parser function (step S5). The story data 43 includes information for identifying a module to be executed, a calculation amount of the module, an access source, an access destination, a data amount, and a module processing cycle for each processing procedure in which a plurality of modules based on the configuration graph list 41 are executed. It is the table which matched the parameter value which concerns on the load amount of each module, such as the access pattern classified based on. Such story data 43 indicates how much calculation amount each module executes, from where to where, how much data and in what access pattern.

  Next, when the story data 43 is created by the structure analysis unit 11, the scenario generator 12 refers to the story data 43 in advance as an empty scenario draft module that does not have a parameter value related to the load amount for each module. Each parameter value is set in the prepared fragment part 12a to create the virtual software module 12b (step S6).

  That is, the fragment part 12a in which the parameter value is set has no algorithmic meaning indicating the behavior of the module of the evaluation target software 3, and the virtual part having the same access pattern and load amount as when the actual entity of the module operates. It becomes the software module 12b. Each virtual software module 12b uses only the CPU calculation amount and the access pattern indicating the I / O pattern of the system LSI 7 as the entity of the behavior, so that the hardware independent software module that is not affected by a specific algorithm or device can do.

  Since the internal structure of the virtual software module 12b is not intended to perform the intended behavior, the function name, arguments, etc. of the evaluation target software 3 are assumed to take over the form of the evaluation target software 3.

  The replacement unit 13 replaces the module tree structure 11a obtained after the structural analysis of the evaluation target software 3 with the virtual software module 12b created by the scenario generator 12 (step S7). It does not actually replace the module as it is. In the source code, for example, in the case of a C language description, by replacing between “{” indicating the start of function processing and “}” indicating the end, the original evaluation target software 3 function names and arguments are maintained. For conditional branch processing based on the calculation result, a branch according to a desired branch ratio is generated and replaced using a conventional branch prediction method.

  On the other hand, the virtualization level information 18 stores information related to the user's module selection using the module selection unit 14, and if there is a module that is not to be replaced, the virtual software module 12b for that module Replacement is suppressed. The virtualization level information 18 also includes configuration information of the image processing apparatus. The configuration information indicates the number of pixels that can be captured in units of a predetermined number of frames, the amount of access data per file, the display resolution, and the like.

  After the processing by the replacement unit 13, the virtual software generation unit 15 uses the module tree structure 15a in which the module tree structure 11a is replaced with the virtual software module 12b, and the actual software that operates in the simulation environment of the evaluation target hardware 2 A code is output (step S8).

  Next, the user creates the abstract hardware 21a of the evaluation target hardware 2 using the ESL tool 20, and then the ESL composed of the abstract hardware 21a and the virtual software 21b output from the virtualization processing unit 10. The model 21 is verified by simulating on the ESL tool 20 (step S9), and it is determined whether or not the software requirement specification is satisfied (step S10). When it is determined that the user satisfies the software requirement specification, it is determined that the evaluation is completed (step S12).

  On the other hand, if it is determined that the software requirement specification is not satisfied, the user displays the story data 43 on the display unit 33 and changes and adjusts the value of the item (step S11). Alternatively, the information stored in the configuration graph list 41 and the I / O traffic list 42 is changed. The structure analysis unit 11 updates the story data 43 by executing a list parser in response to a change in the configuration graph list 41 or the I / O traffic list 42. Thereafter, it is possible to verify how the evaluation target software 3 should be improved by repeating the processing described above.

  In this manner, the user can simulate the behavior of the evaluation target hardware 2 and analyze the behavior of the evaluation target software 3 using the ESL tool 20 as a hardware simulator.

  Next, a verification example using the simulator device 100 described above will be described. For example, an example will be described in which an image processing apparatus in which the image processing unit is SoCed to capture moving images and still images as the system LSI 7 is verified. FIG. 4 is a diagram illustrating an example of the abstract hardware 21 a of the image processing apparatus created using the ESL tool 20. In FIG. 4, in the abstract hardware 21 a created using the ESL tool 20, the image processing apparatus includes a device A as a processor that is the center of this apparatus and a device B as an accelerator that assists image processing. Image processing SoC 6, device C as a memory used when the processor operates, device D as a camera 64 for capturing an image, device E as a memory card 65 for storing data, and an LCD panel 66 for display Device F and device G as a general-purpose interface used for other general purposes. In the figure, the abstract hardware 21a is represented by a block having logic for representing the functions of the devices A to G.

  The user displays the abstract hardware 21a of the image processing apparatus created using the ESL tool 20 on the display unit 33, and requests the image processing SoC 6 when requesting a large screen as an apparatus for processing moving images and still images. We will explore the specifications that can be used.

  FIG. 5 is a diagram illustrating an example of the module tree structure 11a of the evaluation target software 3 according to the image processing apparatus. In FIG. 5, the evaluation target software 3 according to the image processing apparatus 6 functions as a module 1 that functions as a camera driver, a module 2 that functions as image preprocessing, a module 3 that functions as an accelerator driver, and data post-processing. A module tree structure having a module 4, a module 5 functioning as a memory card driver, a module 6 functioning as an LCD panel driver, and a module 7 functioning as a DSP firmware, and connecting the modules to indicate I / O traffic 11a is configured.

  When the evaluation target software 3 input to the virtualization processing unit 10 is source code, the structure analysis unit 11 creates a module tree structure 11a. When a specification drawing by UML or the like is input, the analysis of the source code necessary for creating the module tree structure 11a is simplified.

  FIG. 6 is a diagram illustrating an example of a processing flow of the evaluation target software 3. In FIG. 6, the result of the processing flow analyzed by the pre-profiling of the structure analysis unit 11 is shown, and the module shown in FIG. 5 is shown correspondingly for each processing in the processing flow.

  In process P1, when the camera driver of module 1 captures continuous data from the camera of device D to the memory of device C, in process P2, an operation is executed within the processor of device A, and image preprocessing of module 2 is performed. As a result, random access to the memory of the device C occurs.

  When the preprocessing is completed, in process P3, the panel driver of the module 6 transfers data to the LCD panel of the device F to display an image. In process P4, it is determined whether or not the camera is in the shooting state. If the camera is not in the shooting state, the process returns to process P1 and the same process as described above is repeated. In the photographing state, the accelerator driver of the module 3 transfers data from the memory of the device C to the accelerator of the device B in process P5.

  In accordance with the data transfer to the accelerator of the device B, in the process P6, an operation is executed in the processor of the device A and the data post-processing of the module 4 is performed, and the random access to the memory of the device C is performed by the process. appear.

  Thereafter, in process P7, the memory card driver of the module 5 performs random access from the memory of the device C to the memory card of the device E, and stores a moving image or a still image.

  In this way, by pre-profiling, what behavior is described in the source code in each of the processes P1 to P7 is analyzed and output.

  FIG. 7 is a diagram illustrating an example of the story data 43 created based on the structural analysis result. In FIG. 7, story data 43 is a table composed of items such as a module number, a module name, a calculation amount, an access source, an access destination, a data amount, and an access pattern. The module number corresponds to the module number generated when the module tree structure 11a shown in FIG. 5 is created. The degree of load is indicated by the amount of calculation. When the module performs data transfer, the configuration graph list 41 is referred to, and the device from which the access source and the access destination to which the data is transferred can specify the device name (or device A, B, C, etc.) Identification information).

  The data amount indicates the data transfer amount from the access source to the access destination. This is determined based on the configuration information stored in the virtualization level information 18. The calculation amount and the access pattern are determined based on cycle measurement by profiling of the pre-profiler (step S4).

  The access pattern indicates whether the access destination is continuous, intermittent, or random. An access pattern classified as “continuous” indicates a pattern for accessing a continuous address space. The access pattern classified as “intermittent” indicates that the access pattern is discontinuous in the address space but is accessed while having a constant interval. The access pattern classified as “random” indicates a pattern in which an arbitrary address is accessed in a discontinuous manner that is not classified as either “continuous” or “intermittent”.

  FIG. 8 is a diagram illustrating an example of the ESL model 21 of the image processing apparatus. The ESL model 21 that abstracts the system LSI 7 shown in FIG. 8 includes the abstract hardware 21a and the virtual software 21b as described above. The entities of the modules 1 to 7 constituting the virtual software 21b are only intended to give a load depending on the calculation amount, the data amount, and the access pattern.

  Therefore, as shown in the story data 43, the module 1 is a source code that gives a load of a data amount of 257 MB / s in continuous access. Module 2 is a source code that gives a load of 10 MIPS calculation amount for every 10 MB of random access. Module 3 is a source code that gives a load of 1 MIPS calculation amount for every 10 MB of random access. Module 4 is a source code which gives a load of 10 MIPS calculation amount for every 1 MB of random access. Module 5 provides a 1MB intermittent access load. Module 6 is source code which gives a load of continuous access of 28 MB / s. Module 7 is source code that gives a load of 1 MB of random access. In this example, the case where all the modules constituting the virtual software 21b are virtualized is shown, but one or more modules may not be virtualized and the source code itself for realizing the behavior of the modules may be included.

  Next, an example in which the user performs verification while operating the ESL 20 will be described with reference to FIGS. 9 and 10. For example, a case where a product that doubles the performance by doubling the image size with respect to the product of the previous generation is planned will be described. FIG. 9A shows an abstract hardware 22a that is given an attribute having an image size that is twice that of the hardware configuration of the previous generation. When such an abstract hardware 22a is evaluated using the ESL 20, the user inputs the previous generation software as the evaluation target software 3 to the virtualization processing unit 10 to create the virtual software 21b, and the image size. In order to maintain the processing speed while doubling the number of times, a configuration setting for doubling the system clock is performed. The value is stored in the virtualization level 18. The user executes a simulation with the ESL model 21 including the abstract hardware 22a and the virtual software 21b.

  The result of the simulation by the ESL 20 is displayed on the display unit 33 as shown in FIG. 9B, for example. Although the user can verify that the target performance is achieved by verifying the simulation result, the user simulates the ESL model 21 with the minimum necessary clock, and refers to the log display of the simulation in FIG. When the simulation portion 27 related to E is analyzed, it can be predicted that the access to the memory card of the device E will block the operation of the LCD panel of the device F. In this case, a phenomenon occurs in which the image displayed on the LCD panel of the device F disappears for a moment while accessing the memory card of the device E. From this, the user intends to estimate the performance necessary to realize the camera function that satisfies the required performance, but simply doubling the system clock is not sufficient. can do.

  If the clock is further multiplied by N times to satisfy the target performance, the power consumption increases, so that the user cannot easily increase only the clock. Consider reconfiguring the abstract hardware 22a in which the data access path is rearranged by reconfiguring the configuration. From the viewpoint of reconstruction, for example, as shown in abstract hardware 22a ′ shown in FIG. 10A, the user can perform high-speed, large-scale and continuous access to device D's camera and device F's LCD panel, and small amounts of data and intermittently. The architecture is constructed by changing the combination of buses and changing the arrangement so that the data access control to the memory card of the device E accessing the device and the accelerator of the device B is divided within the image processing SoC 6. In addition, the accelerator of device B does not make a memory call, but changes are made to add the FIFO of device h so that data can be flowed in from the processor of device A in a pipelined manner. Change the form.

  Even when the simulation is performed with the abstract hardware 22a ′ reconstructed in this way, re-simulation is performed by using the already created virtual software 21b without changing the source code itself of the evaluation target software 3. It can be performed. That is, in the above-described reconstruction example, the FIFO of the device h is additionally arranged between the processor of the device A and the accelerator of the device B due to the hardware configuration, but between the processor of the device A and the accelerator of the device B. This is because the processing flow of the software and the load of each module are not changed.

  Since the virtual software 21b expresses the behavior of the software by the degree of load, it can be evaluated by the same virtual software 21b with an improved hardware architecture. Therefore, it is possible to greatly reduce the man-hours required to implement and re-verify every time the evaluation target software 3 for searching the architecture is improved.

  The log (FIG. 10B) indicating the simulation result by the above reconstruction is verified in detail, and the log indicating the access trace is confirmed in the memory access unit of the device D. The behavior of the system LSI 7 can be confirmed without porting and mounting the entity (source code or load module) of the evaluation target software 3 so that a stable system LSI 7 can be constructed while the access is dispersed and the clock is suppressed. be able to.

  As another verification, when it is predicted that the performance of the processor of the device A is not doubled by doubling the system clock, the processing speed of the processor of the device A is increased 1.5 times by increasing the memory of the device C. Even so, the possibility that the performance of the entire system LSI 7 can be doubled can be easily verified.

  In addition, when developing another product in which the existing hardware and software are rebuilt and the camera is replaced with a TV signal receiver, image processing originally performed from the camera and image processing performed by acquiring the TV signal are software. Although the logic is different in the above process, when the degree of load on the processor of the device A is the same, the virtual software 21b that does not depend on the characteristics of the connected device can be used for verification. That is, it is possible to verify at an early stage before remodeling the software installed in the apparatus that captures the moving image or still image from which the virtual software 21b is generated, and to feed back the items to be remodeled to the software developer. . At the same time, since only the camera of the device D of the abstract hardware 22a is changed to the TV signal receiver and verified, the abstract hardware 22a changed to the TV signal receiver without waiting for actual hardware implementation. Can be simulated and the results can be fed back to the hardware developer. In this case, the identification information (for example, “device D”) for specifying the device is not changed, and the characteristic of the device may be changed to the television signal receiver, or the access source or access destination value of the story data 43 is changed. This is because the I / O traffic between modules in the virtual software 21b is not changed.

  A development cycle when using the virtualization software 21b will be described with reference to FIG. FIG. 11 is a diagram showing a development cycle. In FIG. 11, the flow indicated by a solid line is a development cycle when the virtualization software 21b according to the present invention is used. In FIG. 11, a required specification for the system LSI 7 as a developed product is created (step S81), and the system configuration is designed (step S82). Hardware design is performed based on the designed system configuration (step S83).

  Based on the hardware design, actual hardware is developed and implemented (step S83-2). On the other hand, an ESL model based on the abstract hardware 21a and the virtual software 21b based on the hardware design is mounted on the simulator apparatus 100, and hardware verification is performed by the ESL tool 20 (step S84). Is verified (step S85).

  When the user determines that the hardware requirement specification is not satisfied, the process returns to step S84 to change the abstract hardware 21a, update the ESL model, and verify whether the hardware requirement specification is satisfied again in step S85. repeat. Further, the verification result is reflected in the development of the actual hardware (evaluation target hardware 2) in step S83-2. Step S83-2 and steps S84 and 85 are performed in parallel, and development of actual hardware and mounting as the system LSI 7 are performed.

  If it is determined that the hardware requirement specification is satisfied, software verification is performed using the virtual software 21b (step S86), and it is determined whether the software requirement specification is satisfied (step S87). When the user determines that the software requirement specification is not satisfied, the story data 43 is changed, the process returns to step S86, the software verification is performed again, and the process of verifying again whether the software requirement specification is satisfied is repeated in step S87. . On the other hand, we will develop software that reflects the verification results.

  When it is determined that the software requirement specification is satisfied, the actual software (the verification result of the virtual software 21b is included in the system LSI 7 on which the actual hardware (the evaluation target hardware 2 reflecting the verification result of the abstract hardware 21a) is mounted. The reflected evaluation target software 3) is ported (step S88), and the system LSI 7 is verified on the actual machine (step S89). It is determined whether or not the required specifications for the system LSI 7 are satisfied (step S90). If it is determined that the required specifications are satisfied, the development of the system LSI 7 is completed (step S91). On the other hand, when it is determined that the required specifications as the system LSI 7 are not satisfied, the process returns to step S82, the design of the system configuration of the system LSI 7 is reviewed, and the same processing as described above is repeated.

  In FIG. 11, in the conventional development cycle, in order to perform the software verification (step S86), the evaluation target software 3 is transplanted (step S85-2 indicated by a dotted line) when the hardware requirement specification is satisfied (step S85). There was a need. If it is determined that the software requirement specification is not satisfied after the software verification, the evaluation target software 3 is remodeled based on the verification result, and the porting operation is performed again (step S85-2), the software verification (step S87) and the software It was necessary to repeat the determination of whether or not the required specifications are satisfied (step S87).

  As described above, in the conventional development cycle, if there is a problem in the evaluation target software 3, the software verification cannot proceed unless the problem is solved. On the other hand, when the simulator device 100 according to the present invention is used, the verification target software 3 can be continuously verified on the ESL tool 20 for verifying hardware, so that more verifications can be performed once with less modification and transplantation. Can be performed.

  Next, a tendency when performance evaluation is performed with a benchmark for each virtualization level will be described with reference to FIGS. 12 and 13. FIG. 12 is a diagram illustrating an example of the virtualization level. In FIG. 12, for example, a virtualization level in the case where the evaluation target software 3 is configured by a GUI (Graphical User Interface) 3A, a processing engine 3B, and a device driver 3C is illustrated. The evaluation target software 3 is operated on an OS (Operating System) 4 and performance is evaluated with a benchmark application via an API (Application Program Interface).

  FIG. 12A shows a level in which the GUI 3A, the processing engine 3B, and the device driver 3C of the evaluation target software 3 are replaced with the virtual software module 7a, the edited virtual software module 7b, and the virtual software module 7c, and all are virtualized. . Here, the edited virtual software module 7b indicates that the story data 43 is replaced after editing in order to satisfy the software requirement specification. FIG. 12B shows a virtualization level of approximately 50% when the device driver 3C is not replaced with a virtual software module. FIG. 12C shows the actual software (0% virtualization level) that is not replaced with the virtual software module, all of which remain as the evaluation target software 3 (source code).

  FIG. 13 is a graph showing a tendency of evaluation based on a benchmark for each virtualization level. In FIG. 13, the vertical axis of the graph indicates the score indicating the high performance by the benchmark evaluation, and the horizontal axis of the graph indicates the benchmark test number, from low to high performance required for convenience. Are shown side by side. In FIG. 13, the broken line 9a corresponds to the level of all virtualization in FIG. 12A, the broken line 9b corresponds to the 50% virtualization level in FIG. 12B, and the broken line 9c corresponds to the level of FIG. It corresponds to the actual software level and shows the actual measurement value.

  As can be seen from the graph of FIG. 13, the total virtualization line 9a is a lower evaluation score than the actual software line 9c and the 50% virtualization line 9b in the entire test, but is almost the same as the actual software line 9c. Show the trend. Therefore, it is sufficient to grasp the characteristic tendency after completion of the evaluation target software 3 in the initial stage of software development.

  As described above, when the device driver is changed in accordance with the replacement of the parts or the configuration change in the hardware design, the source code of the device driver can be changed only by changing the story data 43 related to the degree of the load of the device driver. The software requirement specification can be verified at the initial stage of software development without performing the porting operation of the entire evaluation target software 3 due to the change. In addition, when the software design is replaced with an unimplemented processing engine or GUI with a different processing algorithm, it is a virtual software module corresponding to the degree of load of the existing module corresponding to these, and software at the initial stage of software development The required specifications can be verified. Further, even when the software is in the design stage and cannot be implemented, the virtual software 21b is used in which the evaluation of the overall throughput, behavior, etc. of the hardware is replaced by using the existing software as the evaluation target software 3. It can be carried out.

Regarding the above description, the following items are further disclosed.
(Appendix 1)
A module tree structure creating means for creating a module tree structure by analyzing data input / output between a plurality of modules constituting the software;
Load table creating means for creating a load table indicating the degree of load for each module;
Replacement means for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table;
Virtual software generation means for generating virtual software based on the module tree structure in which the module is replaced with the virtual software module;
A virtual software generation apparatus.
(Appendix 2)
When creating the load table, the load table creation means uses items of calculation amount, data amount, data input / output destination, and traffic list generated by analyzing data input / output and data amount for each module. The virtual software generation device according to appendix 1, wherein the degree of the load is indicated by an access pattern item relating to the data input / output classified into continuous, intermittent, and random.
(Appendix 3)
Additional notes further comprising virtual software module generation means for generating the virtual software module by giving the load level of the module as a parameter value to a fragment part having the load level as a parameter using the load table 3. The virtual software generation device according to 1 or 2.
(Appendix 4)
Module selection means for allowing a user to select whether or not to replace the virtual software module with respect to a plurality of modules constituting the software;
The virtual software generation device according to any one of appendices 1 and 3, wherein the replacement unit uses a source code of a module that is not replaced.
(Appendix 5)
The virtual software generation device according to any one of Supplementary Note 1 to Supplementary Note 4, wherein the virtual software generation unit generates and outputs the virtual software operable in a hardware simulation environment.
(Appendix 6)
The load table created by the load table creating means can be changed by the user,
The virtual software generation device according to any one of supplementary notes 1 to 5, wherein the replacement unit and the virtual software generation unit are re-executed in accordance with the change of the load table.
(Appendix 7)
A simulator device for simulating hardware,
Abstraction means for creating abstract hardware expressing the hardware as an abstraction;
Virtual software generation means for generating and outputting virtual software virtualized according to the degree of load when the software is executed;
Simulating means for simulating a simulation model composed of the virtual software and the abstract hardware output from the virtual software generating means;
A simulator device.
(Appendix 8)
The virtual software generation means further includes:
A module tree structure creating means for creating a module tree structure by analyzing data input / output between a plurality of modules constituting the software;
Load table creating means for creating a load table indicating the degree of load for each module;
Replacement means for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table;
Virtual software generation means for generating virtual software based on the module tree structure in which the module is replaced with the virtual software module;
The simulator device according to appendix 7, wherein:
(Appendix 9)
A module tree structure creation procedure for creating a module tree structure by analyzing data input / output between a plurality of modules constituting the software;
A load table creation procedure for creating a load table indicating the degree of load for each module;
A replacement procedure for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table;
A virtual software generation procedure for generating virtual software based on the module tree structure in which the module is replaced with the virtual software module;
A virtual software generation method in which a computer executes.
(Appendix 10)
A module tree structure creating means for analyzing data input / output between a plurality of modules constituting the software and creating a module tree structure;
Load table creating means for creating a load table indicating the degree of load for each module;
Replacement means for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table;
A program for causing a computer to function as virtual software generation means for generating virtual software based on the module tree structure in which the module is replaced with the virtual software module.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

It is a figure which shows the function structural example of the simulator apparatus which concerns on one Example of this invention. It is a figure which shows the hardware structural example of a simulator apparatus. It is a flowchart for demonstrating the process by a virtualization process part. It is a figure which shows the example of the abstract hardware of the image processing apparatus produced using the ESL tool. It is a figure which shows the example of the module tree structure of the evaluation object software which concerns on an image processing apparatus. It is a figure which shows the example of the processing flow of evaluation object software. It is a figure which shows the example of the story data produced based on a structural analysis result. It is a figure which shows the example of the ESL model of an image processing apparatus. It is a figure which shows the example verified while a user operates ESL. It is a figure which shows the example verified while a user operates ESL. It is a figure which shows a development cycle. It is a figure which shows the example of a virtualization level. It is a graph which shows the tendency of evaluation by the benchmark for every virtualization level.

Explanation of symbols

2 Evaluation target hardware 3 Evaluation target software 6 Image processing SoC
7 System LSI
DESCRIPTION OF SYMBOLS 10 Virtualization processing part 11 Structure analysis part 11a Module tree structure 11b Story parser 12 Scenario generator 12a Fragment part 12b Virtual software module 13 Replacement part 14 Module selection part 15 Virtual software generation part 15a Module tree structure 18 Virtualization level 20 ESL tool 21a Abstract hardware 21b Virtual software 31 CPU
32 memory unit 33 display unit 34 output unit 35 input unit 36 communication unit 37 storage device 38 driver 39 storage medium 41 configuration graph list 42 I / O traffic list 43 story data 100 simulator device

Claims (5)

A module tree structure creating means for creating a module tree structure by analyzing data input / output between a plurality of modules constituting the software;
Load table creating means for creating a load table indicating the degree of load for each module;
Replacement means for replacing each module of the module tree structure with a virtual software module that generates the degree of load indicated by the load table;
Virtual software generation means for generating virtual software based on the module tree structure in which the module is replaced with the virtual software module;
A virtual software generation apparatus.   When creating the load table, the load table creation means uses items of calculation amount, data amount, data input / output destination, and traffic list generated by analyzing data input / output and data amount for each module. The virtual software generation device according to claim 1, wherein the degree of the load is indicated by an access pattern item related to the data input / output classified as continuous, intermittent, or random.   Claims further comprising virtual software module generation means for generating the virtual software module by giving the load level of the module as a parameter value to a fragment part having the load level as a parameter using the load table. Item 3. The virtual software generation device according to Item 1 or 2. Module selection means for allowing a user to select whether or not to replace the virtual software module with the virtual software module for a plurality of modules constituting the software,
The virtual software generation device according to any one of claims 1 to 3, wherein the replacement means uses a source code of a module that is not replaced.   5. The virtual software generation device according to claim 1, wherein the virtual software generation unit generates and outputs the virtual software operable in a hardware simulation environment. 6.